Writing concurrent and parallel programs is trivial in Erlang. Just spawn more processes and the erlang scheduler rips through all your CPU cores without explicit programming. You don't need to change your code if you're running on a single core or 100 cores.
I've only ever written small synchronous C programs so I have no idea how C code does two things at once. Is it just as easy to write a C program for a quad core computer as it is to write one for a 100 core one?
Other urls found in this thread:
github.com
hpl.hp.com
twitter.com
C multiprogramming is a nightmare spaghetti, which is why so many tools exist to try smoothing it over.
Related question, what is the best/safest way to communicate between threads? Are pub/sub message queues still the best practice?
I don't know shit about programming but if that's parallel programming then why don't they make a coffee machine for each stickman instead of creating a line?
now you're thinking the Erlang way
If you had X tasks you could make X worker processes to handle 1 task each.
In that image, the coffee machine just means cpu cores.
because that would be very expensive douglas
Try programming with Parasail. You just write ordinary looking procedural code and the language applies implicit parallelism to absolutely everything.
Because making coffee machines takes time, which is exactly the problem with parallel programming. It's fine to spawn more threads when you can justify splitting the work but if the split is so inefficient that the overhead of making the new coffee machine is greater then there's no point. Not to mention now you have to wrangle several queues of retards headed to different locations that all want to meet up later
I see you have a future at AMD
Before I didn't know anything about programming I thought it shouldn't be that hard to make something multi threaded. Oh boy, was I wrong. Especially in C with pthreads and mutexes