3 ms·

>CPU speed isn't relevant anymore Only because most software is conceptually stuck in the 50s and Intel fell asleep at the wheel. Having extra cores can allow

>CPU speed isn't relevant anymore Only because most software is conceptually stuck in the 50s and Intel fell asleep at the wheel. Having extra cores can allow you to move away from cludgy and insanely complicated solutions to much simpler code. In turn, this enables faster development and experimentation.

imtringued 7y ago
Generally code becomes more complicated when you have to run it on multiple cores. I personally am working on a toy actor library to test if easy but still reasonably efficient parallelization is possible even with heavy communication needs. I see a 2.3x slowdown when I run it on a single core vs the baseline that uses locks but it reaches parity at higher levels of parallelism and congestion when you have 10 million actors each 32 bytes in size running on 4 threads. As soon as you need to acquire two locks that are only known at runtime it starts to become increasingly difficult to find a solution. It will usually be highly specific to the problem at hand and not generalize at all when the problem changes slightly. If you limit yourself to only acquiring one lock at a time then generalizing becomes simpler but you now have to implement something very similar to transaction rollback. It isn't the end of the world and it is definitively possible but compared to not worrying about it at all in single threaded code it's a massive headache.
- romaniv 7y ago
  Some of the most drastic simplifications I've made to real-life code in the recent years were achieved by splitting a "classic" program into multiple independent agents. Making things "parallel" wasn't even the goal. The goal was to clean up some messes. >As soon as you need to acquire two locks that are only known at runtime Why would you need to acquire two locks that are only known at runtime when using the actor model?

imtringued 7y ago

Generally code becomes more complicated when you have to run it on multiple cores. I personally am working on a toy actor library to test if easy but still reasonably efficient parallelization is possible even with heavy communication needs. I see a 2.3x slowdown when I run it on a single core vs the baseline that uses locks but it reaches parity at higher levels of parallelism and congestion when you have 10 million actors each 32 bytes in size running on 4 threads. As soon as you need to acquire two locks that are only known at runtime it starts to become increasingly difficult to find a solution. It will usually be highly specific to the problem at hand and not generalize at all when the problem changes slightly. If you limit yourself to only acquiring one lock at a time then generalizing becomes simpler but you now have to implement something very similar to transaction rollback. It isn't the end of the world and it is definitively possible but compared to not worrying about it at all in single threaded code it's a massive headache.

romaniv 7y ago
Some of the most drastic simplifications I've made to real-life code in the recent years were achieved by splitting a "classic" program into multiple independent agents. Making things "parallel" wasn't even the goal. The goal was to clean up some messes. >As soon as you need to acquire two locks that are only known at runtime Why would you need to acquire two locks that are only known at runtime when using the actor model?