4 ms·

I'm not quite sure I see the point. Programmers don't need to care about multi-core, because things like your web server and database will take care of it for y

by phaylon 16y ago

I'm not quite sure I see the point. Programmers don't need to care about multi-core, because things like your web server and database will take care of it for you? Then what about the people developing those software products?

scott_s 16y ago
The set of programmers who write systems-level code is significantly smaller than the set of all programmers.
- srean 16y ago
  But arguably this smaller set of programmers have high impact. So it would be a little presumptuous to dismiss the need to understand parallelism. Notions, as those held by the author of the blog post, can have a few undesirable effects. One, it discourages new hackers from messing around with parallelism, which may deny him/her of an opportunity to have a high impact. Two, though it is true that it is not necessary to know the inner workings of a car to drive, sometimes it helps. But may be hackers weren't the target audience in the first place.
  - scott_s 16y ago
    This is already the case with systems programming in general. The set of people who can program competently in VM-based languages is much larger than the set of people who can program competently in C.
    - srean 16y ago
      I agree with you. But wouldnt it be good if high level languages supported concurrency. This would make it easier to program certain tasks. A popular opinion I encounter often and also reflected to an extent in the article is that such a route has no merit. There is no reason to believe that HLLs have to be particularly inefficient (for example the scheme compiler stalin can hold its own and often run faster than an equivalent number crunching code written in c). I am not arguing that Python should be that high level language, but that the current state of "divide" (c for programming servers python for apps) is a little artificial and is a result of a lack of options. Not grappling with parallelism only makes the scene a little more entrenched. I find X10, Fortress and Chapel quite exciting as they are trying to straddle this gap.
      - scott_s 16y ago
        I'm all for models of parallelisms in high level languages. I was pointing out that writing parallel programs without high level models - such as using Pthreads or MPI directly - will probably remain at the systems programming level. I think we'll need to add models of parallelism to high level languages, and most programmers will have to deal with it. But, that's not a given. This author is on the other side: maybe the majority of programs will be able to remain sequential, and we can allow the exploitation of multiple cores to happen mostly at the OS level through the scheduler.
- phaylon 16y ago
  And so is "web front-end developer."
danieldk 16y ago
Then what about the people developing those software products? The article is very clear about this: "I claim that essentially nothing will change for the average programmer with the advent of multicore machines." He does not deny that people writing web and database servers do need to care about multicore CPUs. And I guess it is mostly true, so many daily tasks are I/O bound that the only concurrency most programmers will see are separate GUI/worker threads. Of the tasks where parallelism does help a lot, a substantial subset is embarrassingly parallel. E.g. we parse a lot of large corpora (Wikipedia-size and larger). Parallelization is simply obtained by chunking a corpus, and giving every CPU in the cluster a chunk. Then there are number crunching applications with data dependencies where just a few OpenMP pragmas can easily parallelize programs. Of course, there are remaining hard tasks which require more hand waving.
- phaylon 16y ago
  I don't think equaling "database using web applications" with "average programming" is being clear about the matter. Simply because that segment might not be immediately influenced doesn't mean the new technology won't be picked up. And even as a web developer, I often write more than just something I throw at the web server. Many web applications require cleanup scripts, batch processing of messages or static content, or perform some kind of statistical analysis on their data models. Given enough data, these are all areas where multiple cores can be relevant.
wmf 16y ago
Those people won't use Python; they'll have to use a truly general-purpose language.

by phaylon 16y ago

scott_s 16y ago

The set of programmers who write systems-level code is significantly smaller than the set of all programmers.

srean 16y ago
But arguably this smaller set of programmers have high impact. So it would be a little presumptuous to dismiss the need to understand parallelism. Notions, as those held by the author of the blog post, can have a few undesirable effects. One, it discourages new hackers from messing around with parallelism, which may deny him/her of an opportunity to have a high impact. Two, though it is true that it is not necessary to know the inner workings of a car to drive, sometimes it helps. But may be hackers weren't the target audience in the first place.
- scott_s 16y ago
  This is already the case with systems programming in general. The set of people who can program competently in VM-based languages is much larger than the set of people who can program competently in C.
  - srean 16y ago
    I agree with you. But wouldnt it be good if high level languages supported concurrency. This would make it easier to program certain tasks. A popular opinion I encounter often and also reflected to an extent in the article is that such a route has no merit. There is no reason to believe that HLLs have to be particularly inefficient (for example the scheme compiler stalin can hold its own and often run faster than an equivalent number crunching code written in c). I am not arguing that Python should be that high level language, but that the current state of "divide" (c for programming servers python for apps) is a little artificial and is a result of a lack of options. Not grappling with parallelism only makes the scene a little more entrenched. I find X10, Fortress and Chapel quite exciting as they are trying to straddle this gap.
    - scott_s 16y ago
      I'm all for models of parallelisms in high level languages. I was pointing out that writing parallel programs without high level models - such as using Pthreads or MPI directly - will probably remain at the systems programming level. I think we'll need to add models of parallelism to high level languages, and most programmers will have to deal with it. But, that's not a given. This author is on the other side: maybe the majority of programs will be able to remain sequential, and we can allow the exploitation of multiple cores to happen mostly at the OS level through the scheduler.
phaylon 16y ago
And so is "web front-end developer."

danieldk 16y ago

Then what about the people developing those software products? The article is very clear about this: "I claim that essentially nothing will change for the average programmer with the advent of multicore machines." He does not deny that people writing web and database servers do need to care about multicore CPUs. And I guess it is mostly true, so many daily tasks are I/O bound that the only concurrency most programmers will see are separate GUI/worker threads. Of the tasks where parallelism does help a lot, a substantial subset is embarrassingly parallel. E.g. we parse a lot of large corpora (Wikipedia-size and larger). Parallelization is simply obtained by chunking a corpus, and giving every CPU in the cluster a chunk. Then there are number crunching applications with data dependencies where just a few OpenMP pragmas can easily parallelize programs. Of course, there are remaining hard tasks which require more hand waving.

phaylon 16y ago
I don't think equaling "database using web applications" with "average programming" is being clear about the matter. Simply because that segment might not be immediately influenced doesn't mean the new technology won't be picked up. And even as a web developer, I often write more than just something I throw at the web server. Many web applications require cleanup scripts, batch processing of messages or static content, or perform some kind of statistical analysis on their data models. Given enough data, these are all areas where multiple cores can be relevant.

wmf 16y ago

Those people won't use Python; they'll have to use a truly general-purpose language.