On 07 Jan 2005 13:48:41 -0800, Paul Rubin wrote:
aurora [EMAIL PROTECTED] writes:
Just gone though an article via Slashdot titled The Free Lunch Is
Over: A Fundamental Turn Toward Concurrency in Software
[http://www.gotw.ca/publications/concurrency-ddj.htm]. It argues that
the continous
snip So I've always had it in
the back of my mind that languages that can easily support massive
(especially automatic) parallelization will have their day in the
sun,
at least someday.
and the language of the future will be called ... FORTRAN!
:-)
(joking, but it is the only language I
Steve Horsley wrote:
But my understanding is that the current Python VM is single-threaded
internally,
so even if the program creates multiple threads, just one core will be
dividing
its time between those threads.
Not really.
The CPython interpreter does have a thing called the 'Global
[http://www.gotw.ca/publications/concurrency-ddj.htm]. It argues that the
continous CPU performance gain we've seen is finally over. And that future
gain would primary be in the area of software concurrency taking advantage
hyperthreading and multicore architectures.
Well, yes. However,
On Sat, 08 Jan 2005 14:22:30 GMT, Lee Harr [EMAIL PROTECTED] wrote:
[http://www.gotw.ca/publications/concurrency-ddj.htm]. It argues that the
continous CPU performance gain we've seen is finally over. And that future
gain would primary be in the area of software concurrency taking advantage
Jp How often do you run 4 processes that are all bottlenecked on CPU?
In scientific computing I suspect this happens rather frequently.
More is never enough. -- Bob Saltzman
Skip
--
http://mail.python.org/mailman/listinfo/python-list
I remember a _few_ year ago when all specialists (Intel's) included
agreed that the 100MHZ barrier would never be passed - so, at least, we
did get free lunch for a couple of years :-)
I also must add that in my 17 years of realtime/embedded programming,
the problem usually was not the CPU speed
In article [EMAIL PROTECTED],
[EMAIL PROTECTED] wrote:
Michele deleted an attribution:
snip So I've always had it in
the back of my mind that languages that can easily support massive
(especially automatic) parallelization will have their day in the sun,
at least someday.
and the language
Quoth Skip Montanaro [EMAIL PROTECTED]:
|
| Jp How often do you run 4 processes that are all bottlenecked on CPU?
|
| In scientific computing I suspect this happens rather frequently.
I think he was trying to say more or less the same thing - responding
to (IBM mainframes) ... All those
Donn Cave [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Quoth Skip Montanaro [EMAIL PROTECTED]:
|
| Jp How often do you run 4 processes that are all bottlenecked on
CPU?
|
| In scientific computing I suspect this happens rather frequently.
I think he was trying to say more or
John Roth wrote:
I have yet to write a multi-thread program for performance reasons.
If we include in the set of things covered by the term
performance not only throughput, but also latency, then
I suspect you actually have written some multithreaded programs
for performance reasons.
*I* certainly
to matter much today. But in 10 years we might be really glad that we have
tried.
aurora [EMAIL PROTECTED] writes:
Just gone though an article via Slashdot titled The Free Lunch Is
Over: A Fundamental Turn Toward Concurrency in Software
[http://www.gotw.ca/publications/concurrency-ddj.htm
Peter Hansen [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
John Roth wrote:
I have yet to write a multi-thread program for performance reasons.
If we include in the set of things covered by the term
performance not only throughput, but also latency, then
I suspect you actually have
On Sat, 08 Jan 2005 11:52:03 -0800, aurora [EMAIL PROTECTED] wrote:
One of the author's idea is many of today's main stream technology (like
OO) did not come about suddenly but has cumulated years of research before
becoming widely used. A lot of these ideas may not work or does not seems
to
Hello!
Just gone though an article via Slashdot titled The Free Lunch Is Over: A
Fundamental Turn Toward Concurrency in Software
[http://www.gotw.ca/publications/concurrency-ddj.htm]. It argues that the
continous CPU performance gain we've seen is finally over. And that future
gain would
aurora [EMAIL PROTECTED] writes:
Just gone though an article via Slashdot titled The Free Lunch Is
Over: A Fundamental Turn Toward Concurrency in Software
[http://www.gotw.ca/publications/concurrency-ddj.htm]. It argues that
the continous CPU performance gain we've seen is finally over
On Fri, Jan 07, 2005 at 01:35:46PM -0800, aurora wrote:
Hello!
Just gone though an article via Slashdot titled The Free Lunch Is Over: A
Fundamental Turn Toward Concurrency in Software
[http://www.gotw.ca/publications/concurrency-ddj.htm]. It argues that the
continous CPU performance
Jack Diederich wrote:
On Fri, Jan 07, 2005 at 01:35:46PM -0800, aurora wrote:
Hello!
Just gone though an article via Slashdot titled The Free Lunch Is Over: A
Fundamental Turn Toward Concurrency in Software
[http://www.gotw.ca/publications/concurrency-ddj.htm]. It argues that the
continous
aurora [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Hello!
Just gone though an article via Slashdot titled The Free Lunch Is Over: A
Fundamental Turn Toward Concurrency in Software
[http://www.gotw.ca/publications/concurrency-ddj.htm]. It argues that the
continous CPU performance
aurora wrote:
Just gone though an article via Slashdot titled The Free Lunch Is Over: A
Fundamental Turn Toward Concurrency in Software
[http://www.gotw.ca/publications/concurrency-ddj.htm]. It argues that the
continous CPU performance gain we've seen is finally over. And that future
gain
20 matches
Mail list logo
