From: user5857@newsgrouper.org.invalid   
      
   anton@mips.complang.tuwien.ac.at (Anton Ertl) posted:   
      
   > MitchAlsup  writes:   
   > >   
   > >anton@mips.complang.tuwien.ac.at (Anton Ertl) posted:   
   > >   
   > >> ERROR "unexpected byte sequence starting at index 356: '\xC3'" while   
   decoding:   
   > >>   
   > >> scott@slp53.sl.home (Scott Lurndal) writes:   
   > >> >In general,   
   > >> >any programmer should have a solid understanding of the   
   > >> >underlying hardware - generically, and specifically   
   > >> >for the hardware being programmed.   
   > >>   
   > >> Certainly.  But do they need to know between a a Wallace multiplier   
   > >> and a Dadda multiplier?   
   > >   
   > >You do realize that all Wallace multipliers are Dadda multipliers ??   
   > >But there are Dadda Multipliers that are not Wallace multipliers ?!?!?!   
   >   
   > Good to know, but does not answer the question.   
      
   {Without contradicting that Wallace got on the correct track first}   
   Wallace gets the credit that should rightly go to Dadda.   
      
   > >>                          If not, what is it about pipelined processors   
   > >> that would require CS graduates to know about them?   
   > >   
   > >How execution order disturbs things like program order and memory order.   
   > >That is how and when they need to insert Fences in their multi-threaded   
   > >code.   
   >   
   > And the relevance of pipelined processors for that issue is what?   
   >   
   > Memory-ordering shenanigans come from the unholy alliance of   
   > cache-coherent multiprocessing and the supercomputer attitude.   
      
   And without the SuperComputer attitude, you sell 0 parts.   
   {Remember how we talk about performance all the time here ?}   
      
   >                                                                If you   
   > implement per-CPU caches and multiple memory controllers as shoddily   
   > as possible while providing features for programs to slow themselves   
   > down heavily in order to get memory-ordering guarantess, then you get   
   > a weak memory model; slightly less shoddy, and you get a "strong" memory   
   > model.  Processor pipelines have no relevance here.   
      
   It is the pipelines themselves (along with the SuperComputer attitude)   
   that gives rise to the weak memory models.   
      
   > And, as Niklas Holsti observed, dealing with memory-ordering   
   > shenanigans is something that a few specialists do; no need for others   
   > to know about the memory model, except that common CPUs unfortunately   
   > do not implement sequential consistency.   
      
   Because of the SuperComputer attitude ! {Performance first}   
      
   And only after several languages built their own ATOMIC primitives, so   
   the programmers could remain ignorant. But this also ties the hands of   
   the designers in such a way that performance grows ever more slowly   
   with more threads.   
      
   > - anton   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)