Don wrote:
Bill Baxter wrote:
On Fri, May 1, 2009 at 5:36 PM, bearophile <bearophileh...@lycos.com>
wrote:
Bill Baxter:
Much more often the discussion on the numpy list takes the form of
"how do I make this loop faster" becuase loops are slow in Python so
you have to come up with clever transformations to turn your loop into
array ops. This is thankfully a problem that D array libs do not
have. If you think of it as a loop, go ahead and implement it as a
loop.
Sigh! Already today, and even more tomorrow, this is often false for
D too. In my computer I have a cheap GPU that is sleeping while my D
code runs. Even my other core sleeps. And I am using one core at 32
bits only.
You will need ways to data-parallelize and other forms of parallel
processing. So maybe nornmal loops will not cuti it.
Yeh. If you want to use multiple cores you've got a whole 'nother can
o worms. But at least I find that today most apps seem get by just
fine using a single core. Strange though, aren't you the guy always
telling us how being able to express your algorithm clearly is often
more important than raw performance?
--bb
I confess to being mighty skeptical about the whole multi-threaded,
multi-core thing. I think we're going to find that there's only two
practical uses of multi-core:
(1) embarressingly-parallel operations; and
(2) process-level concurrency.
I just don't believe that apps have as much opportunity for parallelism
as people seem to think. There's just too many dependencies.
Sure, you can (say) with a game, split your AI into a seperate core from
your graphics stuff, but that's only applicable for 2-4 cores. It
doesn't work for 100+ cores.
I had this bad dream where there's a language where it's trivial to use
multiple CPUs. And I could see every Joe and John executing their
trivial apps, each of which used all available CPUs. They had their
programs and programlets run twice or four times as fast, but most of
them ran in less than a couple of seconds anyway, and the longer ones
spent most of their time waiting for external resources.
All it ended up with was a lot of work for the OS, the total throughput
of the computer decreasing because now every CPU had to deal with every
process, not to mention the increase in electricity consumption and heat
because none of the CPUs could rest. And still nobody was using the GPU,
MMX, SSE, etc.
Most of these programs consisted of sequences, with the odd selection or
short iteration spread far and apart. And none of them used
parallellizable data.
(Which is why I think that broadening the opportunity for case (1) is
the most promising avenue for actually using a host of cores).
The more I think about it, the more I'm starting to believe that the
average desktop or laptop won't see two dozen cores in the immediate
future. And definitely, by the time there are more cores than processes
on the average Windows PC, we're talking about gross wasteage.
OTOH, Serious Computing is different, of course. Corporate machine rooms
would benefit from many cores. Virtual host servers, heavy-duty web
servers, and of course scientific and statistical computing come to mind.
It's interesting to note that in the old days, machine room computers
were totally different from PCs. Then they sort-of got together, as in
machine rooms all of a sudden filled with regular PCs running Linux. And
now, I see the trend again separating the PC from the machine room
computers. Software for the latter might be the target for language
features that utilize multiple CPUs.
