Why I don't want lightweight threads in my programming language(pwpwp.blogspot.com)
pwpwp.blogspot.com
Why I don't want lightweight threads in my programming language
http://pwpwp.blogspot.com/2009/09/why-i-dont-want-lightweight-threads-in.html
3 comments
RAM/SSD storage means that we'll probably be CPU-bound in the future.
Isn't this obviously wrong, barring some breakthrough in memory latency?
Isn't this obviously wrong, barring some breakthrough in memory latency?
Yes. In fact, CPU's are still increasing in performance exponentially faster than RAM or disk (hard or solid-state) storage.
Fetching something from RAM still takes hundreds of CPU cycles. Even SSD's, which are much faster than hard disks in most metrics, are orders of magnitude slower than RAM.
So yeah, this isn't happening anytime soon.
Fetching something from RAM still takes hundreds of CPU cycles. Even SSD's, which are much faster than hard disks in most metrics, are orders of magnitude slower than RAM.
So yeah, this isn't happening anytime soon.
MRAM(1) will bring memory latency down a good bit, if it catches on and advancements keep getting made. Its still going to lag behind the speed of processors though and the system bus will still be a general I/O bottleneck (especially if the MRAM is not on chip).
SSD and MRAM may cut down the I/O latencies, but they will never eliminate them, so asynchronous/concurrent operations through lightweight threads will still be important.
He also forgets things where independent processing is desirable because it eases modeling the system which you're modeling, eg a friend used Stackless Python to code that zombie outbreak simulation and each zombie got its own green thread because it simplified the simulation.
Of course, he has a point in that the language should allow green threads to be added as a library, rather than being built in, but most languages would actually allow this. Also, Erlang may have lightweight threads, but its still SMP-aware.
1. http://en.wikipedia.org/wiki/Magnetoresistive_Random_Access_...
He also forgets things where independent processing is desirable because it eases modeling the system which you're modeling, eg a friend used Stackless Python to code that zombie outbreak simulation and each zombie got its own green thread because it simplified the simulation.
Of course, he has a point in that the language should allow green threads to be added as a library, rather than being built in, but most languages would actually allow this. Also, Erlang may have lightweight threads, but its still SMP-aware.
1. http://en.wikipedia.org/wiki/Magnetoresistive_Random_Access_...
> Real programming languages let you implement your own concurrency models.
Yeah! You can write one of those suckers in an all-nighter! It's not like they're tricky or hard to debug or anything. Bring on the Java MonsterTM! Real languages let you use several concurrency models concurrently!
Yeah! You can write one of those suckers in an all-nighter! It's not like they're tricky or hard to debug or anything. Bring on the Java MonsterTM! Real languages let you use several concurrency models concurrently!
Reading these comments all together is making me wonder if the OP was subtle sarcasm and each of us missed it.
If so, it was quite subtle. I'd think sarcastic comments would be fleshed out a bit further. shrug
You almost certainly know more about how you want your threads scheduled for your specific workload than the OS does.
Or you could go down the Solaris route with 170 different priority levels http://www.princeton.edu/~unix/Solaris/troubleshoot/schedule...