Re: multi-core software

Matthias Blume wrote: > "Jeff M." 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 making a fu

Re: multi-core software

Jeff M. wrote: On Jun 9, 9:08 pm, Arved Sandstrom 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. IMO, that re

Re: multi-core software

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 peers.

Re: multi-core software

Jeff M. wrote: On Jun 9, 9:08 pm, Arved Sandstrom 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. IMO, that re

Re: multi-core software

On Jun 10, 12:49 pm, Seamus MacRae wrote: > Jeff M. wrote: > > On Jun 9, 9:08 pm, Arved Sandstrom 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 o

Re: multi-core software

Jeff M. wrote: On Jun 9, 9:08 pm, Arved Sandstrom 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. IMO, that res

Re: multi-core software

Jon Harrop 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 overarching concern

Re: multi-core software

"Jeff M." writes: > On Jun 9, 9:08 pm, Arved Sandstrom 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

Re: multi-core software

On Jun 9, 9:08 pm, Arved Sandstrom 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. >

Re: multi-core software

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 peer

Re: multi-core software

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 dif

Re: multi-core software

On 6/9/2009 11:59 AM Jon Harrop said... toby wrote: On Jun 7, 2:41 pm, Jon Harrop wrote: 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 attention to performance.

Re: multi-core software

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

Re: multi-core software

On Tue, 9 Jun 2009 10:47:11 -0700 (PDT), toby wrote: >On Jun 7, 2:41 pm, Jon Harrop 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 state behind the scenes ... the pro

Re: multi-core software

toby wrote: > On Jun 7, 2:41 pm, 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 > > Frequently when they shouldn't.

Re: multi-core software

On Jun 7, 2:41 pm, 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 Frequently when they shouldn't. > and performance means

Re: multi-core software

> Seamus MacRae (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: >>> >>> http://queue.acm.org/listing.cfm?item_topic=Concurrency

Re: multi-core software

On Jun 8, 6:28 am, "Ken T." 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 it got t

Re: multi-core software

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: http://queue.acm.org/listing.cfm?item_topic=Concurrency&qc_type=theme_list&filter=Concurrency&page_title=Concurr

Re: multi-core software

rossb...@mpi-sws.org wrote: On Jun 8, 6:28 am, "Ken T." 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 interru

Re: multi-core software

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=Concurrency&qc_type=theme_list&filter=Concurrency&page_title=Concurrency Here is one introduc

Re: multi-core software

Roedy Green writes: > On Fri, 5 Jun 2009 18:15:00 + (UTC), Kaz Kylheku > 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. O

Re: multi-core software

On Fri, 5 Jun 2009 18:15:00 + (UTC), Kaz Kylheku 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 appear to have low

Re: multi-core software

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, bu

Re: multi-core software

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

Re: multi-core software

Paul Rubin wrote: > "Jeff M." 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 virtua

Re: multi-core software

"Jeff M." 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 for

Re: multi-core software

George Neuner 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. -- http://mail.python.org/

Re: multi-core software

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 abso

Re: multi-core software

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 diffe

Re: multi-core software

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 programming

Re: multi-core software

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

Re: multi-core software

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, bu

Re: multi-core software

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 programmin

Re: multi-core software

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

Re: multi-core software

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 s

Re: multi-core software

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, I

Re: multi-core software

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 re

Re: multi-core software

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 is

Re: multi-core software

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

Re: multi-core software

Jeff M. wrote: > On Jun 7, 3:19 pm, 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

Re: multi-core software

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, on

Re: multi-core software

On Jun 7, 3:19 pm, 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 > > m

Re: multi-core software

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

Re: multi-core software

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. > > Q

Re: multi-core software

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 think

Re: multi-core software

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 performance and mutable state, I be

Re: multi-core software

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 --

Re: multi-core software

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. http://www.ffconsu

Re: multi-core software

Jon Harrop wrote: Roedy Green wrote: On Fri, 5 Jun 2009 18:15:00 + (UTC), Kaz Kylheku 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 pla

Re: multi-core software

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 th

Re: multi-core software

George Neuner wrote: > On Fri, 05 Jun 2009 16:26:37 -0700, Roedy Green > wrote: >>On Fri, 5 Jun 2009 18:15:00 + (UTC), Kaz Kylheku >> wrote, quoted or indirectly quoted someone who >>said : >>>Even for problems where it appears trivial, there can be hidden >>>issues, like false cache coherency

Re: multi-core software

Roedy Green wrote: > On Fri, 5 Jun 2009 18:15:00 + (UTC), Kaz Kylheku > 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 loc

Re: multi-core software

On Jun 7, 1:56 am, Paul Rubin wrote: > "Jeff M." 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 ju

Re: multi-core software

Paul Rubin wrote: "Jeff M." 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 for

Re: multi-core software

On Jun 6, 9:58 pm, Paul Rubin wrote: > George Neuner 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

Re: multi-core software

På Sat, 06 Jun 2009 21:46:51 +0200, skrev George Neuner : 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 _can_ be done - and yo

Re: multi-core software

On Fri, 05 Jun 2009 16:26:37 -0700, Roedy Green wrote: >On Fri, 5 Jun 2009 18:15:00 + (UTC), Kaz Kylheku > 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 act

Re: multi-core software

On Jun 6, 1:26 am, Roedy Green wrote: > On Fri, 5 Jun 2009 18:15:00 + (UTC), Kaz Kylheku > 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 > >sharin

Re: multi-core software

On Jun 4, 9:46 am, Xah Lee 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 Rewritt

Re: multi-core software

On 2009-06-05, Vend wrote: > On Jun 4, 8:35 pm, Roedy Green > wrote: >> On Thu, 4 Jun 2009 09:46:44 -0700 (PDT), Xah Lee >> 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.  

Re: multi-core software

On Jun 4, 8:35 pm, Roedy Green wrote: > On Thu, 4 Jun 2009 09:46:44 -0700 (PDT), Xah Lee > 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,

Re: multi-core software

Single - thread programming is great! clean, safe!!! I'm trying schedual task to several work process (not thread). On Fri, Jun 5, 2009 at 4:49 AM, MRAB wrote: > Kaz Kylheku wrote: > >> ["Followup-To:" header set to comp.lang.lisp.] >> On 2009-06-04, Roedy Green wrote: >> >>> On Thu, 4 Jun 2009

Re: multi-core software

On Thu, 4 Jun 2009 09:46:44 -0700 (PDT), Xah Lee 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 processor, they can im

Re: multi-core software

Kaz Kylheku wrote: ["Followup-To:" header set to comp.lang.lisp.] On 2009-06-04, Roedy Green wrote: On Thu, 4 Jun 2009 09:46:44 -0700 (PDT), Xah Lee wrote, quoted or indirectly quoted someone who said : • Why Must Software Be Rewritten For Multi-Core Processors? Threads have been part of Ja

Re: multi-core software

["Followup-To:" header set to comp.lang.lisp.] On 2009-06-04, Roedy Green wrote: > On Thu, 4 Jun 2009 09:46:44 -0700 (PDT), Xah Lee > 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

multi-core software

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 Rewritten For Multi-Core Processors? Xah Lee, 2009-06-0