41–47 of 47 posts
Earlier quoted context omitted.
you may have been downvoted for making an unsubstantiated claim that most people don't know when their CPU is running at 100%
...and that is true. When was the last time you monitored what parts of your system were truly I/O bound and not just blocked on another task?
Earlier quoted context omitted.
Even if a Turing machine were a physical object (I had thought you would be aware that it's not), either one of those moves completes before the other, or both complete simultaneously.
if a Turing machine were a physical object ... either one of those moves completes before the other, or both complete simultaneously. ...depending on how fast you're moving relative to the machine heads and in what direction. Simultaneity does not exist in the real world.
I think the first thing people should be taught about concurrency... is when not to use it. Concurrency can result in increased maintenance costs and complexity. Concurrency is also not more efficient on a single core. Concurrency can help with latency and response time. In embedded systems in particular, there is an over-use of concurrency which often results in bloated, complex code.
But in fact concurrency is inevitable in absence of OS threads that can be blocked (another potential clusterfuck) or of some form of continuations support, because it is a direct consequence of asynchrony.
And asynchrony isn't avoidable, all you can do is to find abstractions that make it more deterministic.
Earlier quoted context omitted.
you may have been downvoted for making an unsubstantiated claim that most people don't know when their CPU is running at 100%
...and that is true. When was the last time you monitored what parts of your system were truly I/O bound and not just blocked on another task?
Of course it helps when the platform has the proper tools for it. I end up using JMH and YourKit Profiler weekly, because a memory or CPU leak can crash our process and we have pretty strict reliability requirements with a single server processing about 5000 events per second - not extremely demanding, but when it crashes, we can lose money, with the redundancy infrastructure being pretty new.
Earlier quoted context omitted.
> one of those is what actually happens No it’s not. If the heads aren’t moving in lockstep, what actually happens is you’ll extremely rarely have a moment of time when both locations are whole numbers. At one moment you have { head1loc=0, head2loc=4.17 }, head #1 reached the cell position on the tape, head #2 is still moving. After a while, you’ll have { head1loc=0.872, head2loc=5}, head #1 is on its way, head #2 re…
Pick a reference frame. Sample the state of each CPU on its clock edge. Now you have a sequence of transitions. The sequence is heavily non-deterministic, but that's life in a concurrent universe.
The thing is called “partially ordered set”: https://en.wikipedia.org/wiki/Partially_ordered_set
Earlier quoted context omitted.
you may have been downvoted for making an unsubstantiated claim that most people don't know when their CPU is running at 100%
...and that is true. When was the last time you monitored what parts of your system were truly I/O bound and not just blocked on another task?
Earlier quoted context omitted.
> I think the first thing people should be taught about concurrency... is when not to use it. Concurrency is usually not a feature of the algorithm but a feature of the problem domain. If you have many requests coming in at the same time, all competing for a limited amount of computational resources -- you have concurrency. How you handle it is a different matter. You can decide to handle the requests one by one, but…
No. If the problem is computational resources, performance can't be increased by mere concurrency (while even completely deterministic STM-style parallelism would help). Concurrency improves performance when a process accesses both the same computational resource and some other high-latency sharable resource.