Parallel programming

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?

Attached: con_and_par.jpg (600x451, 39K)

Other urls found in this thread:

github.com/vurtun/mmx/blob/master/sched.h
hpl.hp.com/techreports/2004/HPL-2004-209.pdf
twitter.com/SFWRedditImages

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

Attached: 1525684591467.png (1014x720, 1.04M)

If you use a language from the 21st like go instead of a boomer language from when they had no multicore processors then it's not as hard.

Erlang is great and severely underrated programming language. Elixir is nice too

>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?
Yes, unless you spawn POSIX threads like a retard. The usual way is you write a work queue that wraps the POSIX shite and then the user (aka you, outside the work queue) doesn't need to worry about anything, except if you're a retard or scared you also need to lock appropriately.

>just write your own work queue lmao
Show us this simple code then

Can you learn Elixir (Erlang) if you're a brainlet with no prior programming experience?

github.com/vurtun/mmx/blob/master/sched.h

Yes that's literally the point of elixir. The problem is you will need to know *some* erlang and understand the concepts of OTP

Bump for the Chad erlang/elixir

Just use Ada instead. It nicely wraps POSIX with rendevous abstractions.

> except if you're a retard or scared you also need to lock appropriately
k rtrd
hpl.hp.com/techreports/2004/HPL-2004-209.pdf

ayo hol up, so whatchu be sayin is i should learn Erlang and Elixir will come naturally?

Let the OS spawn processes.
Write one C program per task and just launch them independently from the command line.
Simple and 100% safe and free from race conditions.

>AMD
top kek

Because utilization of the machines would be low. I consider in real world queues would be stochastic

What's your experience with ParaSail? Ready for real-world applications? I found it sad that development seemed to stop two years ago.