Matthias Blume wrote:
Jeff M. mass...@gmail.com writes:
But, assuming that your program works and does what it's supposed to,
I agree with Jon that performance needs to be right near the top of
the list of concerns. Why? Performance isn't about looking good as a
programmer, or having fun
Arved Sandstrom wrote:
Jon Harrop wrote:
Arved Sandstrom wrote:
Jon Harrop wrote:
No. Concurrent programming is about interleaving computations in order
to reduce latency. Nothing to do with parallelism.
Jon, I do concurrent programming all the time, as do most of my peers.
Way down on the
On Jun 9, 9:08 pm, Arved Sandstrom dces...@hotmail.com wrote:
Jon Harrop wrote:
Arved Sandstrom wrote:
Jon, I do concurrent programming all the time, as do most of my peers.
Way down on the list of why we do it is the reduction of latency.
What is higher on the list?
Correctness.
Jeff M. mass...@gmail.com writes:
On Jun 9, 9:08 pm, Arved Sandstrom dces...@hotmail.com wrote:
Jon Harrop wrote:
Arved Sandstrom wrote:
Jon, I do concurrent programming all the time, as do most of my peers.
Way down on the list of why we do it is the reduction of latency.
What is
Jon Harrop j...@ffconsultancy.com writes:
I'm not being facetious. I write applications that run on application
servers, and from time to time I have had to write various special
purpose servers. This kind of programming is all about managing
concurrent execution of computations. The
On Jun 10, 12:49 pm, Seamus MacRae smacrae...@live.ca.invalid wrote:
Jeff M. wrote:
On Jun 9, 9:08 pm, Arved Sandstrom dces...@hotmail.com wrote:
Jon Harrop wrote:
Arved Sandstrom wrote:
Jon, I do concurrent programming all the time, as do most of my peers.
Way down on the list of why
Jeff M. wrote:
On Jun 9, 9:08 pm, Arved Sandstrom dces...@hotmail.com wrote:
Jon Harrop wrote:
Arved Sandstrom wrote:
Jon, I do concurrent programming all the time, as do most of my peers.
Way down on the list of why we do it is the reduction of latency.
What is higher on the list?
Jeff M. wrote:
On Jun 9, 9:08 pm, Arved Sandstrom dces...@hotmail.com wrote:
Jon Harrop wrote:
Arved Sandstrom wrote:
Jon, I do concurrent programming all the time, as do most of my peers.
Way down on the list of why we do it is the reduction of latency.
What is higher on the list?
Jon Harrop wrote:
Arved Sandstrom wrote:
Jon Harrop wrote:
Arved Sandstrom wrote:
Jon Harrop wrote:
No. Concurrent programming is about interleaving computations in order
to reduce latency. Nothing to do with parallelism.
Jon, I do concurrent programming all the time, as do most of my
Jeff M. wrote:
On Jun 9, 9:08 pm, Arved Sandstrom dces...@hotmail.com wrote:
Jon Harrop wrote:
Arved Sandstrom wrote:
Jon, I do concurrent programming all the time, as do most of my peers.
Way down on the list of why we do it is the reduction of latency.
What is higher on the list?
Seamus MacRae smacrae...@live.ca.invalid (SM) wrote:
SM Piet van Oostrum wrote:
By the way, there is a series of articles about concurrency on ACM Queue
which may be interesting for those participating in or just following
this discussion:
On Jun 7, 2:41 pm, Jon Harrop j...@ffconsultancy.com wrote:
Arved Sandstrom wrote:
Jon Harrop wrote:
I see no problem with mutable shared state.
In which case, Jon, you're in a small minority.
No. Most programmers still care about performance
Frequently when they shouldn't.
and
toby wrote:
On Jun 7, 2:41 pm, Jon Harrop j...@ffconsultancy.com wrote:
Arved Sandstrom wrote:
Jon Harrop wrote:
I see no problem with mutable shared state.
In which case, Jon, you're in a small minority.
No. Most programmers still care about performance
Frequently when they
On Tue, 9 Jun 2009 10:47:11 -0700 (PDT), toby
t...@telegraphics.com.au wrote:
On Jun 7, 2:41 pm, Jon Harrop j...@ffconsultancy.com wrote:
Arved Sandstrom wrote:
Jon Harrop wrote:
performance means mutable state.
Hm, not sure Erlangers would wholly agree.
Erlang uses quite a bit of mutable
Erlang uses quite a bit of mutable state behind the scenes ... the
programmers just don't see it.
George
Heh... The CPUs use quite a bit of mutable state behind the scenes ...
the programmers just don't see it.
Actually with CPU they see it more, than... say Erlang (that's why you
need to
On 6/9/2009 11:59 AM Jon Harrop said...
toby wrote:
On Jun 7, 2:41 pm, Jon Harrop j...@ffconsultancy.com wrote:
snip
No. Most programmers still care about performance
Frequently when they shouldn't.
I disagree. A lot of software is still far too slow because the programmers
failed to pay
Jon Harrop wrote:
Arved Sandstrom wrote:
Jon Harrop wrote:
Arved Sandstrom wrote:
Lew wrote:
Interesting distinction. Would it be fair to compare concurrent
programming to the bricks used to build the parallel program's edifice?
Way too much of a fine distinction. While they are in fact
By the way, there is a series of articles about concurrency on ACM Queue
which may be interesting for those participating in or just following
this discussion:
http://queue.acm.org/listing.cfm?item_topic=Concurrencyqc_type=theme_listfilter=Concurrencypage_title=Concurrency
Here is one
rossb...@mpi-sws.org wrote:
On Jun 8, 6:28 am, Ken T. nowh...@home.com wrote:
Let's not forget Elite for the 6502 exploiting predictable performance
in order to switch graphics modes partway down the vsync!
That actually didn't require predictable timing. You could tell the
video chip to send
Piet van Oostrum wrote:
By the way, there is a series of articles about concurrency on ACM Queue
which may be interesting for those participating in or just following
this discussion:
On Jun 8, 6:28 am, Ken T. nowh...@home.com wrote:
Let's not forget Elite for the 6502 exploiting predictable performance
in order to switch graphics modes partway down the vsync!
That actually didn't require predictable timing. You could tell the
video chip to send you an interrupt when
On Jun 7, 1:56 am, Paul Rubin http://phr...@nospam.invalid wrote:
Jeff M. mass...@gmail.com writes:
Even the lightest weight
user space (green) threads need a few hundred instructions, minimum,
to amortize the cost of context switching
There's always a context switch. It's just
Roedy Green wrote:
On Fri, 5 Jun 2009 18:15:00 + (UTC), Kaz Kylheku
kkylh...@gmail.com wrote, quoted or indirectly quoted someone who
said :
Even for problems where it appears trivial, there can be hidden
issues, like false cache coherency communication where no actual
sharing is taking
George Neuner wrote:
On Fri, 05 Jun 2009 16:26:37 -0700, Roedy Green
see_webs...@mindprod.com.invalid wrote:
On Fri, 5 Jun 2009 18:15:00 + (UTC), Kaz Kylheku
kkylh...@gmail.com wrote, quoted or indirectly quoted someone who
said :
Even for problems where it appears trivial, there can be
Scott David Daniels wrote:
the nub of the problem is not on the benchmarks. There is something
to be said for the good old daays when you looked up the instruction
timings that you used in a little document for your machine, and could
know the cost of any loop. We are faster now, but part of
Jon Harrop wrote:
Roedy Green wrote:
On Fri, 5 Jun 2009 18:15:00 + (UTC), Kaz Kylheku
kkylh...@gmail.com wrote, quoted or indirectly quoted someone who
said :
Even for problems where it appears trivial, there can be hidden
issues, like false cache coherency communication where no actual
Arved Sandstrom wrote:
Jon Harrop wrote:
I see no problem with mutable shared state.
In which case, Jon, you're in a small minority.
No. Most programmers still care about performance and performance means
mutable state.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
Jon Harrop wrote:
No. Most programmers still care about performance and performance means
mutable state.
[ Citation needed ].
Most programmers I've met could care less about performance.
--
Beware of bugs in the above code; I have only proved it correct, not
tried it. -- Donald E. Knuth
--
Jon Harrop wrote:
Arved Sandstrom wrote:
Jon Harrop wrote:
I see no problem with mutable shared state.
In which case, Jon, you're in a small minority.
No. Most programmers still care about performance and performance means
mutable state.
I don't see why that would affect whether one
Arved Sandstrom wrote:
Jon Harrop wrote:
Arved Sandstrom wrote:
Jon Harrop wrote:
I see no problem with mutable shared state.
In which case, Jon, you're in a small minority.
No. Most programmers still care about performance and performance means
mutable state.
Quite apart from
Joshua Cranmer wrote:
Jon Harrop wrote:
No. Most programmers still care about performance and performance means
mutable state.
[ Citation needed ].
Most programmers I've met could care less about performance.
Then they have no need for parallelism in the first place.
--
Dr Jon D
On Jun 7, 3:19 pm, Arved Sandstrom dces...@hotmail.com wrote:
Jon Harrop wrote:
Arved Sandstrom wrote:
Jon Harrop wrote:
I see no problem with mutable shared state.
In which case, Jon, you're in a small minority.
No. Most programmers still care about performance and performance means
Jon Harrop wrote:
I see no problem with mutable shared state.
In which case, Jon, you're in a small minority.
Patricia Shanahan wrote:
In my opinion, shared mutable state has a lot of problems. It is also
sometimes the best design for performance reasons.
As Dr. Jon pointed out upthread,
Jeff M. wrote:
On Jun 7, 3:19 pm, Arved Sandstrom dces...@hotmail.com wrote:
Jon Harrop wrote:
Arved Sandstrom wrote:
Jon Harrop wrote:
I see no problem with mutable shared state.
In which case, Jon, you're in a small minority.
No. Most programmers still care about performance and
Lew wrote:
As Dr. Jon pointed out upthread, one can write decent code with mutable
shared
state. It is also true that mutable state presents a lot of problems -
potential problems, ones that can be solved, but not ones that can be
solved
thoughtlessly. On the flip side, one can write a
Jon Harrop wrote:
I agree entirely but my statements were about parallelism and not
concurrency. Parallel and concurrent programming have wildly different
characteristics and solutions. I don't believe shared mutable state is
overly problematic in the context of parallelism. Indeed, I think it
On Sun, 07 Jun 2009 11:16:46 -0400, Lew wrote:
So the good old days are a matter of degree and self-deception - it was
easier to fool ourselves then that we could at least guess timings
proportionately if not absolutely, but things definitely get more
unpredictable over evolution.
As I
Lew wrote:
Jon Harrop wrote:
I agree entirely but my statements were about parallelism and not
concurrency. Parallel and concurrent programming have wildly different
characteristics and solutions. I don't believe shared mutable state is
overly problematic in the context of parallelism. Indeed,
Arved Sandstrom wrote:
Lew wrote:
Interesting distinction. Would it be fair to compare concurrent
programming to the bricks used to build the parallel program's edifice?
Way too much of a fine distinction. While they are in fact different,
the point of concurrent programming is to
Lew wrote:
Jon Harrop wrote:
I agree entirely but my statements were about parallelism and not
concurrency. Parallel and concurrent programming have wildly different
characteristics and solutions. I don't believe shared mutable state is
overly problematic in the context of parallelism.
Jon Harrop wrote:
...
Historically, concurrency has been of general interest on single core
machines in the context of operating systems and IO and has become more
important recently due to the ubiquity of web programming. Parallelism was
once only important to computational scientists
Lew wrote:
div class=moz-text-flowed style=font-family: -moz-fixedScott
David Daniels wrote:
the nub of the problem is not on the benchmarks. There is something
to be said for the good old daays when you looked up the instruction
timings that you used in a little document for your machine, and
Ken T. wrote:
On Sun, 07 Jun 2009 11:16:46 -0400, Lew wrote:
So the good old days are a matter of degree and self-deception - it was
easier to fool ourselves then that we could at least guess timings
proportionately if not absolutely, but things definitely get more
unpredictable over
Jon Harrop wrote:
Arved Sandstrom wrote:
Lew wrote:
Interesting distinction. Would it be fair to compare concurrent
programming to the bricks used to build the parallel program's edifice?
Way too much of a fine distinction. While they are in fact different,
the point of concurrent
Arved Sandstrom wrote:
Jon Harrop wrote:
Arved Sandstrom wrote:
Lew wrote:
Interesting distinction. Would it be fair to compare concurrent
programming to the bricks used to build the parallel program's edifice?
Way too much of a fine distinction. While they are in fact different,
the point
On Mon, 08 Jun 2009 02:39:40 +0100, Jon Harrop wrote:
Ken T. wrote:
On Sun, 07 Jun 2009 11:16:46 -0400, Lew wrote:
So the good old days are a matter of degree and self-deception - it
was easier to fool ourselves then that we could at least guess timings
proportionately if not absolutely, but
George Neuner gneun...@comcast.net writes:
Even the lightest weight
user space (green) threads need a few hundred instructions, minimum,
to amortize the cost of context switching.
I thought the definition of green threads was that multiplexing them
doesn't require context switches.
--
Jeff M. mass...@gmail.com writes:
Even the lightest weight
user space (green) threads need a few hundred instructions, minimum,
to amortize the cost of context switching
There's always a context switch. It's just whether or not you are
switching in/out a virtual stack and registers
Paul Rubin wrote:
Jeff M. mass...@gmail.com writes:
Even the lightest weight
user space (green) threads need a few hundred instructions,
minimum, to amortize the cost of context switching
There's always a context switch. It's just whether or not you are
switching in/out a virtual
Scott David Daniels wrote:
Lew wrote:
Scott David Daniels wrote:
the nub of the problem is not on the benchmarks. There is something
to be said for the good old daays when you looked up the instruction
timings that you used in a little document for your machine, and could
know the cost of
Lew wrote:
Scott David Daniels wrote:
the nub of the problem is not on the benchmarks. There is something
to be said for the good old daays when you looked up the instruction
timings that you used in a little document for your machine, and could
know the cost of any loop. We are faster now,
On Fri, 5 Jun 2009 18:15:00 + (UTC), Kaz Kylheku
kkylh...@gmail.com wrote, quoted or indirectly quoted someone who
said :
Even for problems where it appears trivial, there can be hidden
issues, like false cache coherency communication where no actual
sharing is taking place. Or locks that
Roedy Green see_webs...@mindprod.com.invalid writes:
On Fri, 5 Jun 2009 18:15:00 + (UTC), Kaz Kylheku
kkylh...@gmail.com wrote, quoted or indirectly quoted someone who
said :
Even for problems where it appears trivial, there can be hidden
issues, like false cache coherency communication
On Fri, 05 Jun 2009 16:26:37 -0700, Roedy Green
see_webs...@mindprod.com.invalid wrote:
On Fri, 5 Jun 2009 18:15:00 + (UTC), Kaz Kylheku
kkylh...@gmail.com wrote, quoted or indirectly quoted someone who
said :
Even for problems where it appears trivial, there can be hidden
issues, like false
På Sat, 06 Jun 2009 21:46:51 +0200, skrev George Neuner
gneun...@comcast.net:
On Fri, 05 Jun 2009 16:26:37 -0700, Roedy Green
Add to that the fact that programmers have shown themselves, on
average, to be remarkably bad at figuring out what _should_ be done in
parallel - as opposed to what
On Jun 6, 9:58 pm, Paul Rubin http://phr...@nospam.invalid wrote:
George Neuner gneun...@comcast.net writes:
Even the lightest weight
user space (green) threads need a few hundred instructions, minimum,
to amortize the cost of context switching.
I thought the definition of green threads
On Thu, 4 Jun 2009 09:46:44 -0700 (PDT), Xah Lee xah...@gmail.com
wrote, quoted or indirectly quoted someone who said :
Why Must Software Be Rewritten For Multi-Core Processors?
Threads have been part of Java since Day 1. Using threads complicates
your code, but even with a single core
On 2009-06-05, Vend ven...@virgilio.it wrote:
On Jun 4, 8:35 pm, Roedy Green see_webs...@mindprod.com.invalid
wrote:
On Thu, 4 Jun 2009 09:46:44 -0700 (PDT), Xah Lee xah...@gmail.com
wrote, quoted or indirectly quoted someone who said :
• Why Must Software Be Rewritten For Multi-Core
On Jun 4, 9:46 am, Xah Lee xah...@gmail.com wrote:
Of interest:
• Why Must Software Be Rewritten For Multi-Core Processors?
http://xahlee.org/UnixResource_dir/writ/multi-core_software.html
plain text version follows.
--
Why Must Software Be
On Jun 6, 1:26 am, Roedy Green see_webs...@mindprod.com.invalid
wrote:
On Fri, 5 Jun 2009 18:15:00 + (UTC), Kaz Kylheku
kkylh...@gmail.com wrote, quoted or indirectly quoted someone who
said :
Even for problems where it appears trivial, there can be hidden
issues, like false cache
[Followup-To: header set to comp.lang.lisp.]
On 2009-06-04, Roedy Green see_webs...@mindprod.com.invalid wrote:
On Thu, 4 Jun 2009 09:46:44 -0700 (PDT), Xah Lee xah...@gmail.com
wrote, quoted or indirectly quoted someone who said :
Why Must Software Be Rewritten For Multi-Core Processors?
Kaz Kylheku wrote:
[Followup-To: header set to comp.lang.lisp.]
On 2009-06-04, Roedy Green see_webs...@mindprod.com.invalid wrote:
On Thu, 4 Jun 2009 09:46:44 -0700 (PDT), Xah Lee xah...@gmail.com
wrote, quoted or indirectly quoted someone who said :
Why Must Software Be Rewritten For
62 matches
Mail list logo
