Пришло по Хаскель-кафе.

[thesz]

Guy Steele did the keynote on parallelism [1] at the Strange Loop [2]
conference in which he said that he could do it over Fortress [3]
would have been modeled on Haskell rather than Fortran. The relevant
portions are between 49:36 - 49:50. Thought it might interest readers
of this list.

-deech[1] Read more... )

Comments

[anonym_mouse]

Has not Erlang done it over a decade ago? Finalizing the answer to the question once and for all?
Who needs "parallelism" when instruments like Erlang exist, open-sourced, so the tools are yours
just for the asking (or even without - stretch your arm and take it).

The ideas in Erlang are absolutely first-rate, and other languages can only reimplement the same,
with a better or worse degree of success.

SO, again: who needs your pitifull attempts at solving parallelism after Erlang solved it years ago?!

[antilamer]

Erlang is about concurrency, not parallelism.

[anonym_mouse]

aha. Your answer is a bit too anti-lamer for me.
Can you define "concurrency" versus "parallelism",
and maybe enlighten me as to their interrelation.

Which would be a subset of which? What would be
the purpose of a 'concurrent' program vs a 'parallel'
one?

And what is a buzzword and where the engineering
substance lies in this case?

[thesz]

Пишите, пожалуйста, по-русски.

Мне неинтересно читать плохо составленные предложения, которые скрывают за корявым английским языком обычное незнание или провокацию.

[anonym_mouse]

Придется вас удивить: это "натуральный", родной, правильный английский (который я приобрел после более чем дюжины лет жизни в англоязычной стране и т.д.)

[thesz]

Это вы так считаете.

Переведите на русский все ваши комментарии, пожалуйста.

[lay_back_man]

Which would be a subset of which?

Это натуральный, родной и правильный английский?

[ext_55374]

И «anti-lamer» вдогонку.

[anonym_mouse]

no shit

[anonym_mouse]

Absolutely.

[antilamer]

OK. Message-passing is not the only thing present in the world of concurrent/parallel programming. What do you think of these other approaches (I'm only listing the ones present in Haskell for a quick example) - are they superfluous when you already have Erlang, or does Erlang make it so trivial to implement (or even invent) them that there's no need to talk about them?
- Software transactional memory
- Vector parallelism
- Implicit parallelism and parallel strategies

[thesz]

STM в Эрланге называется Mnesia. ;)

Vector parallelism (nested data parallelism) в Эрланге отсутствует, как класс.

Implicit parallelism отсутствует, всё надо контролировать руками.

Parallel strategies присутствуют, но не в общем виде, а несколько частных случаев.

[antilamer]

Ага, я-то знаю, хотелось бы комментарий anonym_mouse услышать.

[antilamer]

OK, I haven't answered your question completely.
IMO, concurrency is the problem of controlling a number of concurrent processes :)
Parallelism is the problem of exploiting available resources of concurrent execution (CPUs) to speed up computations.

A problem that would rather fall into "concurrency": an IDE - you have to control how the rehighliting, recompilation, file system changes etc. happen concurrently but don't corrupt each other's state.

A problem that would rather fall into "parallelism": compute the convex hull of a set of points, given a GPU.

I mean, you can't just come to a programmer who's writing a convex hull or who's enumerating a complicated game graph, and say, "Dude, what the fuck, just use Erlang / message passing!" - that doesn't help him understand how the problem is to be partitioned for parallel execution. That's what "vector parallelism" is about, for example.

Application OS, not a programming language. Therefore..

[anonym_mouse]

IMO, concurrency is.. - well, in some other people's opinion "concurrency" is just a wider term than "parallelism".

Erlang and its message-passing are just high-level abstractions presented to a scripter (or a programmer, if you wish) in that high-level scripting language called Erlang.
This is a bit misleading, because Erlang is not a programming language per se.
It is a scripting language for the erlang machine, and some people like Joe Armstrong also called it "an application OS".

What this means is that the E. VM can take advantage of multiprocessor systems (since release 11, if I remember correctly) and parallelize the execution of its message-passing lightweight "processes" (I am not even speaking about tasks distributed between hosts and obviously running in parallel, too). If you check a running Erlang VM compiled with smp support, you'll see 4 OS threads per CPU/Core. That is how parallelization occurs in Erlang: implicit parallelism is simply built into the system, capabilities of which you use (or ignore) in your programs

Re: Application OS, not a programming language. Therefore..

[thesz]

Ещё один комментарий на плохом английском и я вас забаню.

Тем более, что вы глупости неинтересные пишете.