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

Groups > comp.lang.c > #106011 > unrolled thread

C Compilers QoI

Back to article view | Back to comp.lang.c

Contents

  C Compilers QoI BartC <bc@freeuk.com> - 2017-03-14 13:01 +0000
    Re: C Compilers QoI mark.bluemel@gmail.com - 2017-03-14 06:16 -0700
    Re: C Compilers QoI already5chosen@yahoo.com - 2017-03-14 06:42 -0700
    Re: C Compilers QoI "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-03-14 06:56 -0700
      Re: C Compilers QoI BartC <bc@freeuk.com> - 2017-03-14 15:58 +0000
        Re: C Compilers QoI "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-03-14 09:22 -0700
        Re: C Compilers QoI scott@slp53.sl.home (Scott Lurndal) - 2017-03-14 16:54 +0000
          Re: C Compilers QoI supercat@casperkitty.com - 2017-03-14 10:24 -0700
            Re: C Compilers QoI scott@slp53.sl.home (Scott Lurndal) - 2017-03-14 17:58 +0000
              Re: C Compilers QoI supercat@casperkitty.com - 2017-03-14 14:12 -0700
                Re: C Compilers QoI Robert Wessel <robertwessel2@yahoo.com> - 2017-03-14 16:34 -0500
                Re: C Compilers QoI Robert Wessel <robertwessel2@yahoo.com> - 2017-03-14 17:36 -0500
                  Re: C Compilers QoI BartC <bc@freeuk.com> - 2017-03-14 23:06 +0000
                  Re: C Compilers QoI supercat@casperkitty.com - 2017-03-14 16:20 -0700
                Re: C Compilers QoI antispam@math.uni.wroc.pl - 2017-03-15 02:32 +0000
                  Re: C Compilers QoI BartC <bc@freeuk.com> - 2017-03-15 12:49 +0000
                  Re: C Compilers QoI supercat@casperkitty.com - 2017-03-15 11:56 -0700
                    Re: C Compilers QoI BartC <bc@freeuk.com> - 2017-03-15 23:09 +0000
                      Re: C Compilers QoI scott@slp53.sl.home (Scott Lurndal) - 2017-03-16 18:17 +0000
                        Re: C Compilers QoI supercat@casperkitty.com - 2017-03-16 11:47 -0700
                          Re: C Compilers QoI Ian Collins <ian-news@hotmail.com> - 2017-03-17 07:50 +1300
                            Re: C Compilers QoI supercat@casperkitty.com - 2017-03-16 12:59 -0700
                              Re: C Compilers QoI David Brown <david.brown@hesbynett.no> - 2017-03-16 21:24 +0100
                                Re: C Compilers QoI supercat@casperkitty.com - 2017-03-16 14:23 -0700
                                  Re: C Compilers QoI Ian Collins <ian-news@hotmail.com> - 2017-03-17 11:30 +1300
                                    Re: C Compilers QoI Ian Collins <ian-news@hotmail.com> - 2017-03-17 11:38 +1300
                                      Re: C Compilers QoI Gareth Owen <gwowen@gmail.com> - 2017-03-17 05:07 +0000
                                        Re: C Compilers QoI Ian Collins <ian-news@hotmail.com> - 2017-03-17 20:26 +1300
                                          Re: C Compilers QoI Gareth Owen <gwowen@gmail.com> - 2017-03-17 07:59 +0000
                                    Re: C Compilers QoI supercat@casperkitty.com - 2017-03-16 16:14 -0700
                                      Re: C Compilers QoI Robert Wessel <robertwessel2@yahoo.com> - 2017-03-16 22:54 -0500
                                        Re: C Compilers QoI supercat@casperkitty.com - 2017-03-17 09:01 -0700
                                      Re: C Compilers QoI Ian Collins <ian-news@hotmail.com> - 2017-03-26 14:16 +1300
                                        Re: C Compilers QoI supercat@casperkitty.com - 2017-03-26 14:19 -0700
                                          Re: C Compilers QoI BartC <bc@freeuk.com> - 2017-03-26 22:43 +0100
                                            Re: C Compilers QoI GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-03-27 01:28 +0200
                                            Re: C Compilers QoI supercat@casperkitty.com - 2017-03-26 22:07 -0700
                                              Re: C Compilers QoI BartC <bc@freeuk.com> - 2017-03-27 11:28 +0100
                                                Re: C Compilers QoI supercat@casperkitty.com - 2017-03-27 07:38 -0700
                                                  Re: C Compilers QoI BartC <bc@freeuk.com> - 2017-03-27 16:23 +0100
                                                    Re: C Compilers QoI supercat@casperkitty.com - 2017-03-27 08:55 -0700
                                                      Re: C Compilers QoI BartC <bc@freeuk.com> - 2017-03-27 17:01 +0100
                                                        Re: C Compilers QoI supercat@casperkitty.com - 2017-03-27 10:03 -0700
                                                    Re: C Compilers QoI GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-03-27 17:58 +0200
                                          Re: C Compilers QoI already5chosen@yahoo.com - 2017-03-27 03:54 -0700
                                            Re: C Compilers QoI supercat@casperkitty.com - 2017-03-27 08:46 -0700
                                              Re: C Compilers QoI scott@slp53.sl.home (Scott Lurndal) - 2017-03-27 17:47 +0000
                                                Re: C Compilers QoI supercat@casperkitty.com - 2017-03-27 11:48 -0700
                                                  Re: C Compilers QoI Robert Wessel <robertwessel2@yahoo.com> - 2017-03-27 15:37 -0500
                                                    Re: C Compilers QoI supercat@casperkitty.com - 2017-03-27 14:46 -0700
                                                      Re: C Compilers QoI Robert Wessel <robertwessel2@yahoo.com> - 2017-03-27 20:28 -0500
                                                        Re: C Compilers QoI supercat@casperkitty.com - 2017-03-28 01:18 -0700
                                                          Re: C Compilers QoI Robert Wessel <robertwessel2@yahoo.com> - 2017-03-28 18:24 -0500
                                                            Re: C Compilers QoI supercat@casperkitty.com - 2017-03-29 07:40 -0700
                                                              Re: C Compilers QoI David Brown <david.brown@hesbynett.no> - 2017-03-29 17:05 +0200
                                                                Re: C Compilers QoI supercat@casperkitty.com - 2017-03-29 11:07 -0700
                                                              Re: C Compilers QoI antispam@math.uni.wroc.pl - 2017-03-31 04:04 +0000
                                                                Re: C Compilers QoI bartc <bc@freeuk.com> - 2017-03-31 10:53 +0100
                                                                  Re: C Compilers QoI Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-03-31 07:35 -0700
                                                                    Re: C Compilers QoI supercat@casperkitty.com - 2017-03-31 08:07 -0700
                                                                  Re: C Compilers QoI supercat@casperkitty.com - 2017-03-31 07:54 -0700
                                                                Re: C Compilers QoI supercat@casperkitty.com - 2017-03-31 07:43 -0700
                              Re: C Compilers QoI Ian Collins <ian-news@hotmail.com> - 2017-03-17 11:21 +1300
                                Re: C Compilers QoI Ian Collins <ian-news@hotmail.com> - 2017-03-17 11:24 +1300
                        Re: C Compilers QoI BartC <bc@freeuk.com> - 2017-03-16 22:15 +0000
                          Re: C Compilers QoI scott@slp53.sl.home (Scott Lurndal) - 2017-03-17 12:31 +0000
                        Re: C Compilers QoI already5chosen@yahoo.com - 2017-03-16 15:24 -0700
                          Re: C Compilers QoI supercat@casperkitty.com - 2017-03-16 16:03 -0700
                          Re: C Compilers QoI scott@slp53.sl.home (Scott Lurndal) - 2017-03-17 12:39 +0000
                            Re: C Compilers QoI already5chosen@yahoo.com - 2017-03-17 08:27 -0700
                    Re: C Compilers QoI antispam@math.uni.wroc.pl - 2017-03-16 01:35 +0000
                      Re: C Compilers QoI BartC <bc@freeuk.com> - 2017-03-16 02:18 +0000
                        Re: C Compilers QoI antispam@math.uni.wroc.pl - 2017-03-18 00:45 +0000
                          Re: C Compilers QoI BartC <bc@freeuk.com> - 2017-03-18 13:12 +0000
                            Re: C Compilers QoI antispam@math.uni.wroc.pl - 2017-03-18 20:31 +0000
                              Re: C Compilers QoI supercat@casperkitty.com - 2017-03-18 17:31 -0700
                      Re: C Compilers QoI supercat@casperkitty.com - 2017-03-16 09:22 -0700
            Re: C Compilers QoI Nick Bowler <nbowler@draconx.ca> - 2017-03-24 16:13 +0000
              Re: C Compilers QoI supercat@casperkitty.com - 2017-03-24 12:32 -0700
                Re: C Compilers QoI Robert Wessel <robertwessel2@yahoo.com> - 2017-03-24 22:13 -0500
                  Re: C Compilers QoI supercat@casperkitty.com - 2017-03-25 13:05 -0700
                    Re: C Compilers QoI Robert Wessel <robertwessel2@yahoo.com> - 2017-03-27 15:44 -0500
                      Re: C Compilers QoI supercat@casperkitty.com - 2017-03-27 14:51 -0700
                        Re: C Compilers QoI Robert Wessel <robertwessel2@yahoo.com> - 2017-03-27 20:31 -0500
          Re: C Compilers QoI BartC <bc@freeuk.com> - 2017-03-14 17:26 +0000
            Re: C Compilers QoI Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-03-15 12:02 -0500
    Re: C Compilers QoI David Brown <david.brown@hesbynett.no> - 2017-03-14 15:00 +0100
      Re: C Compilers QoI already5chosen@yahoo.com - 2017-03-14 07:36 -0700
        Re: C Compilers QoI David Brown <david.brown@hesbynett.no> - 2017-03-14 15:57 +0100
        Re: C Compilers QoI Andrey Tarasevich <andreytarasevich@hotmail.com> - 2017-03-14 08:11 -0700
          Re: C Compilers QoI BGB <cr88192@hotmail.com> - 2017-03-29 23:51 -0500
      Re: C Compilers QoI BartC <bc@freeuk.com> - 2017-03-14 15:28 +0000
        Re: C Compilers QoI David Brown <david.brown@hesbynett.no> - 2017-03-14 21:41 +0100
    Re: C Compilers QoI Keith Thompson <kst-u@mib.org> - 2017-03-14 09:26 -0700
      Re: C Compilers QoI BartC <bc@freeuk.com> - 2017-03-14 18:23 +0000
        Re: C Compilers QoI Keith Thompson <kst-u@mib.org> - 2017-03-14 12:05 -0700
    Re: C Compilers QoI already5chosen@yahoo.com - 2017-03-14 09:35 -0700
      Re: C Compilers QoI BartC <bc@freeuk.com> - 2017-03-14 17:08 +0000
        Re: C Compilers QoI already5chosen@yahoo.com - 2017-03-14 10:24 -0700
          Re: C Compilers QoI BartC <bc@freeuk.com> - 2017-03-14 17:34 +0000
          Re: C Compilers QoI already5chosen@yahoo.com - 2017-03-14 11:55 -0700
            Re: C Compilers QoI BartC <bc@freeuk.com> - 2017-03-14 19:03 +0000
              Re: C Compilers QoI BartC <bc@freeuk.com> - 2017-03-14 19:06 +0000
              Re: C Compilers QoI already5chosen@yahoo.com - 2017-03-14 12:10 -0700
                Re: C Compilers QoI BartC <bc@freeuk.com> - 2017-03-14 21:14 +0000
                  Re: C Compilers QoI already5chosen@yahoo.com - 2017-03-14 14:42 -0700
                  Re: C Compilers QoI supercat@casperkitty.com - 2017-03-14 14:53 -0700
                    Re: C Compilers QoI BartC <bc@freeuk.com> - 2017-03-14 23:20 +0000
                      Re: C Compilers QoI antispam@math.uni.wroc.pl - 2017-03-15 02:43 +0000
    Re: C Compilers QoI jacobnavia <jacob@jacob.remcomp.fr> - 2017-03-14 19:39 +0100
      Re: C Compilers QoI BartC <bc@freeuk.com> - 2017-03-14 19:10 +0000
    Re: C Compilers QoI antispam@math.uni.wroc.pl - 2017-03-14 19:29 +0000
    Re: C Compilers QoI Noob <root@127.0.0.1> - 2017-03-15 09:27 +0100
    Re: C Compilers QoI ed_davis2@yahoo.com - 2017-03-16 15:10 -0700
      Re: C Compilers QoI BartC <bc@freeuk.com> - 2017-03-16 23:19 +0000

Page 2 of 6 — ← Prev page 1 [2] 3 4 5 6  Next page →

#106263

On 03/17/17 07:47 AM, supercat@casperkitty.com wrote:
> On Thursday, March 16, 2017 at 1:18:08 PM UTC-5, Scott Lurndal wrote:
>> If you are writing a compiler, and you're not familiar with the
>> Intel Software/Architecture Optimization Guides, which tell you _exactly_
>> how fast each instruction is, then you're not doing it right
>> (hint:  The add instruction above, assuming a hit in L1, is a
>> single cycle instruction (with, perhaps a load-to-use penalty
>> of three or four cycles depending on where in the pipeline you
>> are)).
>
> That's only really relevant if the person who is using the compiler knows
> what kind of hardware will be used to run the generated code.  Otherwise
> code orderings which improve performance on one processor may make it worse
> on another.

Which is why compilers have extensive architecture related options...

-- 
Ian

[toc] | [prev] | [next] | [standalone]

#106278

On Thursday, March 16, 2017 at 1:50:51 PM UTC-5, Ian Collins wrote:
> On 03/17/17 07:47 AM, supercat wrote:
> > That's only really relevant if the person who is using the compiler knows
> > what kind of hardware will be used to run the generated code.  Otherwise
> > code orderings which improve performance on one processor may make it worse
> > on another.
> 
> Which is why compilers have extensive architecture related options...

...which are useful **in the case where the user of the compiler knows what
kind of hardware will be used to run the generated code.**

If an executable is being built for the purpose of publication, the person
who built it may have no way of knowing everyone who might want to use it or
what kind of hardware they may have.  As such, it may not make sense to
worry about the intricacies of particular processors' instruction scheduling
except possibly to avoid performance disasters.

[toc] | [prev] | [next] | [standalone]

#106283

On 16/03/17 20:59, supercat@casperkitty.com wrote:
> On Thursday, March 16, 2017 at 1:50:51 PM UTC-5, Ian Collins wrote:
>> On 03/17/17 07:47 AM, supercat wrote:
>>> That's only really relevant if the person who is using the compiler knows
>>> what kind of hardware will be used to run the generated code.  Otherwise
>>> code orderings which improve performance on one processor may make it worse
>>> on another.
>>
>> Which is why compilers have extensive architecture related options...
>
> ...which are useful **in the case where the user of the compiler knows what
> kind of hardware will be used to run the generated code.**
>

That sort of thing is useful to get the very fastest code from a 
compiler.  But you can get good code by taking into account common 
tricks - many or even most of the suggestions in the Intel books are 
valid across a range of Intel cpus, and also across most AMD cpus 
(partly because the same things such as false dependencies  apply in AMD 
cpus, and partly because AMD have read those books - and they know 
compiler writers have read the books.  Even /I/ have read bits from 
those books, and I don't do x86 assembly).

> If an executable is being built for the purpose of publication, the person
> who built it may have no way of knowing everyone who might want to use it or
> what kind of hardware they may have.  As such, it may not make sense to
> worry about the intricacies of particular processors' instruction scheduling
> except possibly to avoid performance disasters.
>

Yes, it makes a lot of sense to be concerned about things like 
scheduling (for time-sensitive code).  Typically, you can make certain 
assumptions about minimum hardware.  If your target is Win7 and above, 
that requires a newer processor than an XP user might have.  Then you 
can decide the range of processors for which your code must work, and 
the target for optimisation - which is not necessarily the same thing. 
By optimising for Core 2 while limiting instructions to those from a 
Pentium 3, your code will be as fast as it can be on modern chips while 
still running on the old ones.  If you decide that all users will have 
at least a Core 2 generation, you can take advantage of instructions 
from there.

And if you have really time-critical parts, you can generate multiple 
versions of the functions in question and have the compiler generate 
code that will select the fastest version once it figures out what 
processor you are running on.

[toc] | [prev] | [next] | [standalone]

#106285

On Thursday, March 16, 2017 at 3:25:01 PM UTC-5, David Brown wrote:
> On 16/03/17 20:59, supercat wrote:
> > On Thursday, March 16, 2017 at 1:50:51 PM UTC-5, Ian Collins wrote:
> >> Which is why compilers have extensive architecture related options...
> >
> > ...which are useful **in the case where the user of the compiler knows what
> > kind of hardware will be used to run the generated code.**
> >
> 
> That sort of thing is useful to get the very fastest code from a 
> compiler.  But you can get good code by taking into account common 
> tricks - many or even most of the suggestions in the Intel books are 
> valid across a range of Intel cpus, and also across most AMD cpus 
> (partly because the same things such as false dependencies  apply in AMD 
> cpus, and partly because AMD have read those books - and they know 
> compiler writers have read the books.  Even /I/ have read bits from 
> those books, and I don't do x86 assembly).

Of course, in many cases all that is necessary to get within a few percent
of optimal overall application performance is to avoid generating really
bad code.  If an application would spend the vast majority of its time doing
things that are outside the compiler's control (running external library
code or waiting for a user to do something) there would be a limit to how
much a compiler could improve performance, no matter how much it spent on
optimizations.

If an extra five minutes spent compiling a program would reduce its run time
from five hours to four hours, that would be five minutes well spent.  If
it reduces the total time spent running the application by 0.4 seconds, the
five extra minutes spent on compilation will be a waste.

> > If an executable is being built for the purpose of publication, the person
> > who built it may have no way of knowing everyone who might want to use it or
> > what kind of hardware they may have.  As such, it may not make sense to
> > worry about the intricacies of particular processors' instruction scheduling
> > except possibly to avoid performance disasters.
> 
> Yes, it makes a lot of sense to be concerned about things like 
> scheduling (for time-sensitive code).  Typically, you can make certain 
> assumptions about minimum hardware.  If your target is Win7 and above, 
> that requires a newer processor than an XP user might have.  Then you 
> can decide the range of processors for which your code must work, and 
> the target for optimisation - which is not necessarily the same thing. 
> By optimising for Core 2 while limiting instructions to those from a 
> Pentium 3, your code will be as fast as it can be on modern chips while 
> still running on the old ones.  If you decide that all users will have 
> at least a Core 2 generation, you can take advantage of instructions 
> from there.

General scheduling principles are fine, but worrying about the particulars
of specific processors is probably not particularly useful.  Further, it
doesn't make sense to worry about execution efficiency at all in parts of
the code which won't meaningfully affect performance.

> And if you have really time-critical parts, you can generate multiple 
> versions of the functions in question and have the compiler generate 
> code that will select the fastest version once it figures out what 
> processor you are running on.

Naturally, for the very small portion of the time where that would matter.
And even there I would expect that in many cases optimal performance would
require using different algorithms on different platforms.  For example, an
an algorithm which requires N steps, each of which depends upon a result
from the two previous steps, might run faster or slower than one which
requires 2N steps, each of which is independent from the preceding and
succeeding ten.  Scheduling issues might also be important, but if it's
worthwhile to use separate builds for different processors I would think
that it would also often be worthwhile to use different algorithms.

[toc] | [prev] | [next] | [standalone]

#106295

On 03/17/17 10:23 AM, supercat@casperkitty.com wrote:
> On Thursday, March 16, 2017 at 3:25:01 PM UTC-5, David Brown wrote:
>>
>> Yes, it makes a lot of sense to be concerned about things like
>> scheduling (for time-sensitive code).  Typically, you can make certain
>> assumptions about minimum hardware.  If your target is Win7 and above,
>> that requires a newer processor than an XP user might have.  Then you
>> can decide the range of processors for which your code must work, and
>> the target for optimisation - which is not necessarily the same thing.
>> By optimising for Core 2 while limiting instructions to those from a
>> Pentium 3, your code will be as fast as it can be on modern chips while
>> still running on the old ones.  If you decide that all users will have
>> at least a Core 2 generation, you can take advantage of instructions
>> from there.
>
> General scheduling principles are fine, but worrying about the particulars
> of specific processors is probably not particularly useful.  Further, it
> doesn't make sense to worry about execution efficiency at all in parts of
> the code which won't meaningfully affect performance.

For computationally intensive (vectorisable)  code, such as FFmpeg, the 
particulars of specific processors, especially supported SIMD 
instructions can make a very significantly affect performance.

-- 
Ian

[toc] | [prev] | [next] | [standalone]

#106296

On 03/17/17 11:30 AM, Ian Collins wrote
>
> For computationally intensive (vectorisable)  code, such as FFmpeg, the
> particulars of specific processors, especially supported SIMD
> instructions can make a very significantly affect performance.
>
Need a grammar checker...

For computationally intensive (vectorisable)  code such as FFmpeg the
particulars of specific processors, especially supported SIMD
instructions, can very significantly affect performance.

-- 
Ian

[toc] | [prev] | [next] | [standalone]

#106313

Ian Collins <ian-news@hotmail.com> writes:

> On 03/17/17 11:30 AM, Ian Collins wrote
>>
>> For computationally intensive (vectorisable)  code, such as FFmpeg, the
>> particulars of specific processors, especially supported SIMD
>> instructions can make a very significantly affect performance.
>>
> Need a grammar checker...
>
> For computationally intensive (vectorisable)  code such as FFmpeg the
> particulars of specific processors, especially supported SIMD
> instructions, can very significantly affect performance.

True, but for those purposes FFmpeg often falls back to using inline asm
or explicit __builtin_xxx SIMD instructions, which suggests the
optimisers have some way to on architecture-specific tuning - particular
in the presence of potential aliasing.

[toc] | [prev] | [next] | [standalone]

#106323

On 03/17/17 06:07 PM, Gareth Owen wrote:
> Ian Collins <ian-news@hotmail.com> writes:
>
>> On 03/17/17 11:30 AM, Ian Collins wrote
>>>
>>> For computationally intensive (vectorisable)  code, such as FFmpeg, the
>>> particulars of specific processors, especially supported SIMD
>>> instructions can make a very significantly affect performance.
>>>
>> Need a grammar checker...
>>
>> For computationally intensive (vectorisable)  code such as FFmpeg the
>> particulars of specific processors, especially supported SIMD
>> instructions, can very significantly affect performance.
>
> True, but for those purposes FFmpeg often falls back to using inline asm
> or explicit __builtin_xxx SIMD instructions, which suggests the
> optimisers have some way to on architecture-specific tuning - particular
> in the presence of potential aliasing.

-fno-strict-aliasing?

Falling back to using inline asm is just as bad as chip specific 
optimisation options!

-- 
Ian

[toc] | [prev] | [next] | [standalone]

#106324

Ian Collins <ian-news@hotmail.com> writes:

> On 03/17/17 06:07 PM, Gareth Owen wrote:
>> Ian Collins <ian-news@hotmail.com> writes:
>>
>>> On 03/17/17 11:30 AM, Ian Collins wrote
>>>>
>>>> For computationally intensive (vectorisable)  code, such as FFmpeg, the
>>>> particulars of specific processors, especially supported SIMD
>>>> instructions can make a very significantly affect performance.
>>>>
>>> Need a grammar checker...
>>>
>>> For computationally intensive (vectorisable)  code such as FFmpeg the
>>> particulars of specific processors, especially supported SIMD
>>> instructions, can very significantly affect performance.
>>
>> True, but for those purposes FFmpeg often falls back to using inline asm
>> or explicit __builtin_xxx SIMD instructions, which suggests the
>> optimisers have some way to on architecture-specific tuning - particular
>> in the presence of potential aliasing.
>
> -fno-strict-aliasing?

You'd have to ask them, I'm only kinda familiar with the codebase.  They
are hyper-sensitive to tiny optimisations -- the absolutely fastest
imaginable code.  There's no such thing as "good enough". If the
compiled code was 99% as fast as the inline asm, I suspect they'd pick
the ASM, even given the maintenence headache.

> Falling back to using inline asm is just as bad as chip specific
> optimisation options!

There's a mindset that doesn't care about that though.  Not one I share.

[toc] | [prev] | [next] | [standalone]

#106298

On Thursday, March 16, 2017 at 5:30:20 PM UTC-5, Ian Collins wrote:
> On 03/17/17 10:23 AM, supercat wrote:
> > General scheduling principles are fine, but worrying about the particulars
> > of specific processors is probably not particularly useful.  Further, it
> > doesn't make sense to worry about execution efficiency at all in parts of
> > the code which won't meaningfully affect performance.
> 
> For computationally intensive (vectorisable)  code, such as FFmpeg, the 
> particulars of specific processors, especially supported SIMD 
> instructions can make a very significantly affect performance.

How useful is it to try to apply vectorization into an entire program, rather
than focusing on particular places within it where it is apt to be helpful?
I would think that writing the portions of program that would benefit from
vectorization in a language like FORTRAN which is designed to facilitate
them would make more sense than having a compiler search through an entire
program for opportunities to apply SIMD optimizations which will likely be
useful only in a few localized places.

[toc] | [prev] | [next] | [standalone]

#106312

On Thu, 16 Mar 2017 16:14:42 -0700 (PDT), supercat@casperkitty.com
wrote:

>On Thursday, March 16, 2017 at 5:30:20 PM UTC-5, Ian Collins wrote:
>> On 03/17/17 10:23 AM, supercat wrote:
>> > General scheduling principles are fine, but worrying about the particulars
>> > of specific processors is probably not particularly useful.  Further, it
>> > doesn't make sense to worry about execution efficiency at all in parts of
>> > the code which won't meaningfully affect performance.
>> 
>> For computationally intensive (vectorisable)  code, such as FFmpeg, the 
>> particulars of specific processors, especially supported SIMD 
>> instructions can make a very significantly affect performance.
>
>How useful is it to try to apply vectorization into an entire program, rather
>than focusing on particular places within it where it is apt to be helpful?
>I would think that writing the portions of program that would benefit from
>vectorization in a language like FORTRAN which is designed to facilitate
>them would make more sense than having a compiler search through an entire
>program for opportunities to apply SIMD optimizations which will likely be
>useful only in a few localized places.


Of course the vast majority of programmers are remarkably bad at
guessing what parts of a program is performance critical, or that
would vectorize well.  But once you get past that, some annotations to
the C program to tell the compiler to try and vectorize here, but not
there, would have much the same effect, without the burden of adding a
second language to the build.

OTOH, computers are particularly good at dull and repetitive tasks, so
let it search...

[toc] | [prev] | [next] | [standalone]

#106355

On Thursday, March 16, 2017 at 10:54:26 PM UTC-5, robert...@yahoo.com wrote:
> On Thu, 16 Mar 2017 16:14:42 -0700 (PDT), supercat wrote:
> >How useful is it to try to apply vectorization into an entire program, rather
> >than focusing on particular places within it where it is apt to be helpful?
> >I would think that writing the portions of program that would benefit from
> >vectorization in a language like FORTRAN which is designed to facilitate
> >them would make more sense than having a compiler search through an entire
> >program for opportunities to apply SIMD optimizations which will likely be
> >useful only in a few localized places.
> 
> Of course the vast majority of programmers are remarkably bad at
> guessing what parts of a program is performance critical, or that
> would vectorize well.  But once you get past that, some annotations to
> the C program to tell the compiler to try and vectorize here, but not
> there, would have much the same effect, without the burden of adding a
> second language to the build.

FORTRAN-90 added constructs to perform operations on segments of arrays, and
later versions have added additional features for parallelism though I don't
know the specifics.  Further, its aliasing rules allow many optimizations
that C's rules don't.  Adding more directives to C to specify when things
will and won't alias might improve it to be as good as FORTRAN, but unless
such directives are added the C Standard will merely impede programmers'
ability to use language semantics which are appropriate to their individual
needs.

> OTOH, computers are particularly good at dull and repetitive tasks, so
> let it search...

Searching in places that aren't going to yield optimizations isn't useful.
The philosophy you espouse sounds like a miner who thinks the way to get
a lot of gold is to maximize the amount of random dirt thrown into a wash
plant, rather than trying to figure out which areas of ground have dirt
that's worth running, or at least refrain from running the same worthless
dirt over and over and over again in the hopes that some gold might magically
appear on the 572nd time it's run.  Occasionally a fleck might appear that
had been missed on the previous 571 runs, but repeatedly running the same
dirt is not generally an efficient use of resources.

If a programmer can identify that a certain piece of code needs to be
vectorized and mark it as such, doing that once will improve performance on
every future build.  By contrast, having the compiler search through every
build for optimization opportunities will represent continuous wasted effort.
A compiler may be faster than a programmer at searching for optimization
opportunities, but every minute added to the build process will represent a
wasted hour every sixty builds.

[toc] | [prev] | [next] | [standalone]

#107088

On 03/17/17 12:14 PM, supercat@casperkitty.com wrote:
> On Thursday, March 16, 2017 at 5:30:20 PM UTC-5, Ian Collins wrote:
>> On 03/17/17 10:23 AM, supercat wrote:
>>> General scheduling principles are fine, but worrying about the particulars
>>> of specific processors is probably not particularly useful.  Further, it
>>> doesn't make sense to worry about execution efficiency at all in parts of
>>> the code which won't meaningfully affect performance.
>>
>> For computationally intensive (vectorisable)  code, such as FFmpeg, the
>> particulars of specific processors, especially supported SIMD
>> instructions can make a very significantly affect performance.
>
> How useful is it to try to apply vectorization into an entire program, rather
> than focusing on particular places within it where it is apt to be helpful?
> I would think that writing the portions of program that would benefit from
> vectorization in a language like FORTRAN which is designed to facilitate
> them would make more sense than having a compiler search through an entire
> program for opportunities to apply SIMD optimizations which will likely be
> useful only in a few localized places.
>
Why?  C compilers either with or without Open-MP have been vectorising 
code for years.  More so with CUDA.

-- 
Ian

[toc] | [prev] | [next] | [standalone]

#107122

On Saturday, March 25, 2017 at 8:16:37 PM UTC-5, Ian Collins wrote:
> On 03/17/17 12:14 PM, supercat wrote:
> > How useful is it to try to apply vectorization into an entire program, rather
> > than focusing on particular places within it where it is apt to be helpful?
> > I would think that writing the portions of program that would benefit from
> > vectorization in a language like FORTRAN which is designed to facilitate
> > them would make more sense than having a compiler search through an entire
> > program for opportunities to apply SIMD optimizations which will likely be
> > useful only in a few localized places.
> >
> Why?  C compilers either with or without Open-MP have been vectorising 
> code for years.  More so with CUDA.

C compilers can vectorize certain constructs, but C lacks any nice way to
say that two pointers may be equal, but will not be used in any *other*
form of overlapping fashion, thus making it safe for a compiler to
vectorize something like:

    void add_vector(float * dest, 
                    float const *src1, float const *src2)
    {
      for (int i=0; i<50; i++)
        dest[i] = src1[i] + src2[i];
    }

The "restrict" qualifier can help a lot, but if a function for e.g. a long
vector addition wants to provide options to either store the sum in one
of the original vectors or write the result someplace else, it would need
to be written as:

    void add_vector(float *restrict dest, 
                    float const *restrict src1, float const *restrict src2)
    {
      if (dest == src1)
      {
        if (dest == src2)
          for (int i=0; i<50; i++)
            dest[i] += dest[i] + dest[i];
        else
          for (int i=0; i<50; i++)
            dest[i] += dest[i] + src2[i];
      }
      else if (dest == src2)
        for (int i=0; i<50; i++)
          dest[i] += src1[i] + dest[i];
      else
        for (int i=0; i<50; i++)
          dest[i] = src1[i] + src2[i];
    }

I don't know FORTRAN, but I'm pretty sure it wouldn't require writing out
the code four times to achieve the required semantics.

[toc] | [prev] | [next] | [standalone]

#107123

On 26/03/2017 22:19, supercat@casperkitty.com wrote:
> On Saturday, March 25, 2017 at 8:16:37 PM UTC-5, Ian Collins wrote:
>> On 03/17/17 12:14 PM, supercat wrote:
>>> How useful is it to try to apply vectorization into an entire program, rather
>>> than focusing on particular places within it where it is apt to be helpful?
>>> I would think that writing the portions of program that would benefit from
>>> vectorization in a language like FORTRAN which is designed to facilitate
>>> them would make more sense than having a compiler search through an entire
>>> program for opportunities to apply SIMD optimizations which will likely be
>>> useful only in a few localized places.
>>>
>> Why?  C compilers either with or without Open-MP have been vectorising
>> code for years.  More so with CUDA.
>
> C compilers can vectorize certain constructs, but C lacks any nice way to
> say that two pointers may be equal, but will not be used in any *other*
> form of overlapping fashion, thus making it safe for a compiler to
> vectorize something like:
>
>     void add_vector(float * dest,
>                     float const *src1, float const *src2)
>     {
>       for (int i=0; i<50; i++)
>         dest[i] = src1[i] + src2[i];
>     }
>
> The "restrict" qualifier can help a lot, but if a function for e.g. a long
> vector addition wants to provide options to either store the sum in one
> of the original vectors or write the result someplace else, it would need
> to be written as:
>
>     void add_vector(float *restrict dest,
>                     float const *restrict src1, float const *restrict src2)
>     {
>       if (dest == src1)
>       {
>         if (dest == src2)
>           for (int i=0; i<50; i++)
>             dest[i] += dest[i] + dest[i];
>         else
>           for (int i=0; i<50; i++)
>             dest[i] += dest[i] + src2[i];
>       }
>       else if (dest == src2)
>         for (int i=0; i<50; i++)
>           dest[i] += src1[i] + dest[i];
>       else
>         for (int i=0; i<50; i++)
>           dest[i] = src1[i] + src2[i];
>     }
>
> I don't know FORTRAN, but I'm pretty sure it wouldn't require writing out
> the code four times to achieve the required semantics.

Surely the simplest way is to have a separate INPLACE version (int n 
param omitted to avoid wrap):

void add_vector(float *result, float *a, float *b);  // result=a+b
void iadd_vector(float *a, float *b);                // a+=b


-- 
bartc

[toc] | [prev] | [next] | [standalone]

#107127

On Sun, 26 Mar 2017 22:43:01 +0100
BartC <bc@freeuk.com> wrote:

> Surely the simplest way is to have a separate INPLACE version (int n 
> param omitted to avoid wrap):
> 
> void add_vector(float *result, float *a, float *b);  // result=a+b
> void iadd_vector(float *a, float *b);                // a+=b

I would rather reserve a static buffer to process the calculation such as:

struct vt
{
  double vt_cx;
  double vt_cy;
  double vt_cz;
};

struct vt vecbuf;

struct vt *vecsum(struct vt *v1, struct vt *v2)
{
  vecbuf.vt_cx = v1->vt_cx;
  vecbuf.vt_cy = v1->vt_cy;
  vecbuf.vt_cz = v1->vt_cz;

  vecbuf.vt_cx += v2->vt_cx;
  vecbuf.vt_cy += v2->vt_cy;
  vecbuf.vt_cz += v2->vt_cz;

  return &vecbuf;
};

struct vt u = {123.456, 456.789, 789.123};
struct vt v = {147.258, 258.369, 369.147};
struct vt w = *vecsum(&u, &v);

[toc] | [prev] | [next] | [standalone]

#107133

On Sunday, March 26, 2017 at 4:43:08 PM UTC-5, Bart wrote:
> On 26/03/2017 22:19, supercat wrote:
> >     void add_vector(float *restrict dest,
> >                     float const *restrict src1, float const *restrict src2)
> >     {
> >       if (dest == src1)
> >       {
> >         if (dest == src2)
> >           for (int i=0; i<50; i++)
> >             dest[i] += dest[i] + dest[i];
> >         else
> >           for (int i=0; i<50; i++)
> >             dest[i] += dest[i] + src2[i];
> >       }
> >       else if (dest == src2)
> >         for (int i=0; i<50; i++)
> >           dest[i] += src1[i] + dest[i];
> >       else
> >         for (int i=0; i<50; i++)
> >           dest[i] = src1[i] + src2[i];
> >     }
> >
> > I don't know FORTRAN, but I'm pretty sure it wouldn't require writing out
> > the code four times to achieve the required semantics.
> 
> Surely the simplest way is to have a separate INPLACE version (int n 
> param omitted to avoid wrap):
> 
> void add_vector(float *result, float *a, float *b);  // result=a+b
> void iadd_vector(float *a, float *b);                // a+=b

In most cases, the same machine code should work just fine for the scenario
where the vectors are disjoint, or where the destination coincides with one
or both sources, but would yield semantics inconsistent with the C code in
some other overlap scenarios.  Unless there is a significant speed advantage
to using separate code to handle the in-place operation it would seem silly
to require that the programmer write separate source code for it.

[toc] | [prev] | [next] | [standalone]

#107148

On 27/03/2017 06:07, supercat@casperkitty.com wrote:
> On Sunday, March 26, 2017 at 4:43:08 PM UTC-5, Bart wrote:
>> On 26/03/2017 22:19, supercat wrote:
>>>     void add_vector(float *restrict dest,
>>>                     float const *restrict src1, float const *restrict src2)
>>>     {
>>>       if (dest == src1)
>>>       {
>>>         if (dest == src2)
>>>           for (int i=0; i<50; i++)
>>>             dest[i] += dest[i] + dest[i];
>>>         else
>>>           for (int i=0; i<50; i++)
>>>             dest[i] += dest[i] + src2[i];
>>>       }
>>>       else if (dest == src2)
>>>         for (int i=0; i<50; i++)
>>>           dest[i] += src1[i] + dest[i];
>>>       else
>>>         for (int i=0; i<50; i++)
>>>           dest[i] = src1[i] + src2[i];
>>>     }
>>>
>>> I don't know FORTRAN, but I'm pretty sure it wouldn't require writing out
>>> the code four times to achieve the required semantics.
>>
>> Surely the simplest way is to have a separate INPLACE version (int n
>> param omitted to avoid wrap):
>>
>> void add_vector(float *result, float *a, float *b);  // result=a+b
>> void iadd_vector(float *a, float *b);                // a+=b
>
> In most cases, the same machine code should work just fine for the scenario
> where the vectors are disjoint, or where the destination coincides with one
> or both sources, but would yield semantics inconsistent with the C code in
> some other overlap scenarios.  Unless there is a significant speed advantage
> to using separate code to handle the in-place operation it would seem silly
> to require that the programmer write separate source code for it.

Just a separate interface. iadd_vector can be implemented via 
add_vector, or even vice versa, but now extra information is available 
if there /was/ a way of writing one more efficiently using dedicated 
code, and without cluttering up a single interface with const, restrict 
and whatever other attributes.

You don't need extra /language/ features, other than what is already 
available: fast block copy, faster scalar x+=y compared with x=y+z. But 
if the implementation is capable of doing vector ops, then this could be 
easier to take advantage of.

It's also easier for the user, in the same way that being to write x+=y 
might have an advantage over x=x+y or x=y+z.

(I use the same approach in my dynamic languages, where sort(a) is a 
function returning a new, sorted copy of a, and isort(a) is a procedure 
which does an in-place sort of a.)

-- 
bartc

[toc] | [prev] | [next] | [standalone]

#107155

On Monday, March 27, 2017 at 5:28:59 AM UTC-5, Bart wrote:
> On 27/03/2017 06:07, supercat wrote:
> > In most cases, the same machine code should work just fine for the scenario
> > where the vectors are disjoint, or where the destination coincides with one
> > or both sources, but would yield semantics inconsistent with the C code in
> > some other overlap scenarios.  Unless there is a significant speed advantage
> > to using separate code to handle the in-place operation it would seem silly
> > to require that the programmer write separate source code for it.
> 
> Just a separate interface. iadd_vector can be implemented via 
> add_vector, or even vice versa, but now extra information is available 
> if there /was/ a way of writing one more efficiently using dedicated 
> code, and without cluttering up a single interface with const, restrict 
> and whatever other attributes.
> 
> You don't need extra /language/ features, other than what is already 
> available: fast block copy, faster scalar x+=y compared with x=y+z. But 
> if the implementation is capable of doing vector ops, then this could be 
> easier to take advantage of.
> 
> It's also easier for the user, in the same way that being to write x+=y 
> might have an advantage over x=x+y or x=y+z.
> 
> (I use the same approach in my dynamic languages, where sort(a) is a 
> function returning a new, sorted copy of a, and isort(a) is a procedure 
> which does an in-place sort of a.)

Would you like C if x=x+y was Undefined Behavior, and achieving such
semantics *required* the use of x+=y?

If the same machine code would be usable for the in-place and disjoint-
destination scenarios, would it make sense to require that the code for
the three-operand form check whether the destination matches one of the
sources and call a separate function that runs at just the same speed as
the three-operand form?

[toc] | [prev] | [next] | [standalone]

#107160

On 27/03/2017 15:38, supercat@casperkitty.com wrote:
> On Monday, March 27, 2017 at 5:28:59 AM UTC-5, Bart wrote:

>> It's also easier for the user, in the same way that being to write x+=y
>> might have an advantage over x=x+y or x=y+z.
>>
>> (I use the same approach in my dynamic languages, where sort(a) is a
>> function returning a new, sorted copy of a, and isort(a) is a procedure
>> which does an in-place sort of a.)
>
> Would you like C if x=x+y was Undefined Behavior, and achieving such
> semantics *required* the use of x+=y?
>
> If the same machine code would be usable for the in-place and disjoint-
> destination scenarios, would it make sense to require that the code for
> the three-operand form check whether the destination matches one of the
> sources and call a separate function that runs at just the same speed as
> the three-operand form?

I don't get you. Why would x=x+y be undefined behaviour?

Anyway I'm proposing nothing except that the user interface to such 
function allows those two forms. It's an easy way of provided useful 
extra information to whoever has to implement them, and gives a handy 
extra choice to the user, who doesn't need to worry about annotating 
code with optimisation tips that may not match the actual code.

(However, I've implemented both functions in my own language, with a 
poor optimiser but more transparent code, and there was little 
difference, perhaps 5%, between:

   add_vector(a,a,b,n);

and:

   iadd_vector(a,b,n);

Here, it's probably mostly down to the memory throughput. The test used 
n=1 million, arrays of doubles, mostly containing 0.0, and calling each 
1000 times. Testing it with n=1000, and 1 million iterations to keep 
everything in-cache, then the in-place version was 20% faster.)

-- 
bartc

[toc] | [prev] | [next] | [standalone]

Page 2 of 6 — ← Prev page 1 [2] 3 4 5 6  Next page →

Back to top | Article view | comp.lang.c

csiph-web