Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #15583

Re: The container abstraction and parallel programming

Show all headers | View raw

On 08/01/12 11:29, jacob navia wrote:
> Le 08/01/12 12:05, ec429 a écrit :
>> Actually, those programs aren't "exactly the same", due to the lack of
>> the aforementioned "restrict" keyword. For instance:
>> double array[3]={0,1,2};
>> doADD(array+1, array+1, array, 2);
>
> Adding the "restrict" keyword doesn't change anything.
This is patently false.  Adding the "restrict" keyword certainly changes 
the program (from the perspective of the C standard) since it promises 
to the compiler that the pointers will not be aliased, thereby making 
optimisations (such as SIMD) legal (they otherwise would not be).
> Well, thanks a lot. It is EXACTLY what I proposed in the message that
> started this discussion. We should have a way to tell the compiler
> to use SIMD operations in a special object that we declare as SIMD.
No, you have missed the point.  You don't tell the compiler to "use SIMD 
instructions"; you tell the compiler that it /may/ operate on these data 
in any order since the operators are commutative, nothing is aliased, 
&c.; if the target platform has SIMD instructions the compiler may 
choose to use them.  I cannot stress enough that this is the compiler's job.
Mixing container abstractions with compiler internals, as your OP seems 
to propose, is a pathway to infinite pain; instead, your containers 
library (if such a thing be even necessary) should be written in a 
manner susceptible to optimisation by SIMD-aware compilers - namely, it 
should make full use of the restrict keyword, and handle arrays simply 
where possible; also, data dependencies should be carefully controlled. 
  (Data dependencies limit all reordering)
If, after doing this, you find that the compiler does not use SIMD 
instructions, you patch the compiler (in as general a way as possible). 
  You do _not_ patch the language.
> 1) Using threads to make SIMD is not possible. The overhead of thread
> creation and maintenance is impossible high.
I wasn't suggesting using threads for SIMD; I was merely discussing 
parallelisation in general terms.
> 2) Your remarks about "The compiler knows better" have no connection
> with reality. Gcc, that is a highly advanced compiler, is unable
> to do SIMD reliably, as I proved. It suffices a small change and
> the whole thing COLLAPSES.
Ok, I'll clarify.  The compiler *in principle* knows better, and if it 
gets it wrong, you patch the compiler; you don't patch the language.
> 3) Your remarks about avoiding performance hacks are welcome since it is
> exactly what I was saying: we need a portable way of using SIMD that
> is supported by the language.
"Using SIMD" in your code is a performance hack.  /Making the use of 
SIMD by the compiler possible/ in your code is portable, and avoids 
performance hacks.
> Well, I am using C, and I do not see how LISP would be useful in this
> context since it would need the same extensions that you would need in
> C. Lisp is NOT SIMD per se.
Lisp is inherently parallel; one entirely valid model of execution is to 
consider every cons as being executed in parallel, blocking on its data 
dependencies from its car and cdr.  This is why functional languages 
often incorporate monads, because I/O happens to need to be serial.
A sufficiently intelligent LISP compiler could compile (reduce), 
(expand), (select), and (extend) to appropriate SIMD instructions if the 
target platform has them.  But this is c.l.c, not c.l.lisp.
> I have never denied that gcc generates better code than lcc.
> In my posting I spoke of two mainstream compilers like gcc and MSVC
> That is all. And what I said was right: they aren't able to use SIMD
> programming in a useful way.
I suspect your definition of "useful" is isomorphic to "anything 
mainstream compilers don't do".  As other posters have explained, gcc 
can indeed use SIMD in a useful way, but only where sufficient promises 
have been made to it (like "restrict") for such use not to be a 
violation of the C standard.  Since it's good practice to make those 
promises wherever you can (even if you don't foresee an immediate 
benefit - just the documentation effect of const and restrict justifies 
their use), I don't see what you're complaining about.
> But you do not like what I say (and you do not want to admit it
> to yourself) because I am NOT using gcc and even have the audacity of
> trying to build a different compiler!
I laud your efforts to build a compiler; I'm impressed that you are able 
to do so.  But that doesn't necessarily mean that ideas you have for the 
extension of the language are good ones.
> If you get to personal attacks or suppositions we just can't discuss.
> Everything becomes a stupid war of "gcc is the best and you are wrong
> because you use another compiler"
I'm not a High Priest of the One True Way (tm) of gcc. rather my gold 
standard is The Standard.  Its extension or emendation is justified only 
when it can be shown to have failed.  On SIMD it has not done so.
gcc may currently use less SIMD than it could.  That is a problem to be 
solved by work on gcc, or by creating a better compiler that matches 
gcc's good qualities while avoiding its bad habits.  It is not a problem 
to be solved by adding non-portable incompatible extensions to the 
language, particularly when the language already provides sufficient 
recourse.
-e
-- 
'sane', adj.: see 'unimaginative'
   on the web - http://jttlov.no-ip.org

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

The container abstraction and parallel programming jacob navia <jacob@spamsink.net> - 2012-01-07 00:02 +0100
  Re: The container abstraction and parallel programming blp@cs.stanford.edu (Ben Pfaff) - 2012-01-06 15:08 -0800
    Re: The container abstraction and parallel programming jacob navia <jacob@spamsink.net> - 2012-01-07 00:27 +0100
      Re: The container abstraction and parallel programming blp@cs.stanford.edu (Ben Pfaff) - 2012-01-06 15:30 -0800
        Re: The container abstraction and parallel programming jacob navia <jacob@spamsink.net> - 2012-01-07 00:41 +0100
  Re: The container abstraction and parallel programming Kaz Kylheku <kaz@kylheku.com> - 2012-01-07 00:04 +0000
    Re: The container abstraction and parallel programming jacob navia <jacob@spamsink.net> - 2012-01-07 09:06 +0100
    Re: The container abstraction and parallel programming Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-01-08 03:42 -0800
  Re: The container abstraction and parallel programming Ian Collins <ian-news@hotmail.com> - 2012-01-07 13:50 +1300
    Re: The container abstraction and parallel programming jacob navia <jacob@spamsink.net> - 2012-01-07 09:31 +0100
      Re: The container abstraction and parallel programming Ian Collins <ian-news@hotmail.com> - 2012-01-07 22:03 +1300
      Re: The container abstraction and parallel programming Stephen Sprunk <stephen@sprunk.org> - 2012-01-07 07:39 -0600
        Re: The container abstraction and parallel programming Gene <gene.ressler@gmail.com> - 2012-01-07 09:27 -0800
          Re: The container abstraction and parallel programming Stephen Sprunk <stephen@sprunk.org> - 2012-01-08 11:37 -0600
            Re: The container abstraction and parallel programming jacob navia <jacob@spamsink.net> - 2012-01-08 18:42 +0100
        Re: The container abstraction and parallel programming jacob navia <jacob@spamsink.net> - 2012-01-08 11:48 +0100
          Re: The container abstraction and parallel programming ec429 <ec429@cam.ac.uk> - 2012-01-08 11:16 +0000
          Re: The container abstraction and parallel programming Stephen Sprunk <stephen@sprunk.org> - 2012-01-08 11:52 -0600
            Re: The container abstraction and parallel programming Keith Thompson <kst-u@mib.org> - 2012-01-08 14:17 -0800
              Re: The container abstraction and parallel programming pete <pfiland@mindspring.com> - 2012-01-08 22:08 -0500
              Re: The container abstraction and parallel programming Stephen Sprunk <stephen@sprunk.org> - 2012-01-09 11:07 -0600
                Re: The container abstraction and parallel programming Keith Thompson <kst-u@mib.org> - 2012-01-09 14:55 -0800
            Re: The container abstraction and parallel programming jacob navia <jacob@spamsink.net> - 2012-01-09 00:22 +0100
          Re: The container abstraction and parallel programming Nobody <nobody@nowhere.com> - 2012-01-09 14:19 +0000
            Re: The container abstraction and parallel programming Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-01-09 16:40 +0000
            Re: The container abstraction and parallel programming Kaz Kylheku <kaz@kylheku.com> - 2012-01-09 17:53 +0000
            Re: The container abstraction and parallel programming Gene <gene.ressler@gmail.com> - 2012-01-10 16:58 -0800
  Re: The container abstraction and parallel programming Robert Wessel <robertwessel2@yahoo.com> - 2012-01-07 01:28 -0600
  Re: The container abstraction and parallel programming Jens Gustedt <jens.gustedt@loria.fr> - 2012-01-07 09:39 +0100
    Re: The container abstraction and parallel programming jacob navia <jacob@spamsink.net> - 2012-01-07 09:54 +0100
      Re: The container abstraction and parallel programming Jens Gustedt <jens.gustedt@loria.fr> - 2012-01-07 11:36 +0100
  Re: The container abstraction and parallel programming Gareth Owen <gwowen@gmail.com> - 2012-01-08 08:08 +0000
    Re: The container abstraction and parallel programming jacob navia <jacob@spamsink.net> - 2012-01-08 11:41 +0100
      Re: The container abstraction and parallel programming jacob navia <jacob@spamsink.net> - 2012-01-08 11:53 +0100
      Re: The container abstraction and parallel programming jacob navia <jacob@spamsink.net> - 2012-01-08 11:59 +0100
      Re: The container abstraction and parallel programming ec429 <ec429@cam.ac.uk> - 2012-01-08 11:05 +0000
        Re: The container abstraction and parallel programming jacob navia <jacob@spamsink.net> - 2012-01-08 12:29 +0100
          Re: The container abstraction and parallel programming ec429 <ec429@cam.ac.uk> - 2012-01-08 13:35 +0000
      Re: The container abstraction and parallel programming gwowen <gwowen@gmail.com> - 2012-01-09 01:09 -0800
      Re: The container abstraction and parallel programming Tim Rentsch <txr@alumni.caltech.edu> - 2012-01-26 09:23 -0800
        Re: The container abstraction and parallel programming jacob navia <jacob@spamsink.net> - 2012-01-26 23:41 +0100
          Re: The container abstraction and parallel programming Tim Rentsch <txr@alumni.caltech.edu> - 2012-03-07 16:18 -0800

csiph-web