Path: csiph.com!news.mixmin.net!border2.nntp.ams1.giganews.com!nntp.giganews.com!buffer1.nntp.ams1.giganews.com!nntp.brightview.co.uk!news.brightview.co.uk.POSTED!not-for-mail
NNTP-Posting-Date: Fri, 17 Mar 2017 02:59:55 -0500
From: Gareth Owen <gwowen@gmail.com>
Newsgroups: comp.lang.c
Subject: Re: C Compilers QoI
References: <oa8pdp$nok$1@dont-email.me> <1cdfa44b-0165-4850-aa65-a31c35881d27@googlegroups.com> <oa93q5$t4l$1@dont-email.me> <4fVxA.62281$Bp6.47291@fx36.iad> <74bd9556-d8eb-4507-8780-11df9311b5d2@googlegroups.com> <ibWxA.69903$k61.43609@fx05.iad> <c117efc1-24a2-40cb-bc44-0c8833dff448@googlegroups.com> <oaa93r$obp$1@z-news.wcss.wroc.pl> <ed6e2220-879c-4c33-a3e4-fbefc9376fcb@googlegroups.com> <oachdi$87i$1@dont-email.me> <nFAyA.59220$wC7.37730@fx14.iad> <ee666f30-bdca-4137-ade2-047c1b508e92@googlegroups.com> <ej0543Fhe9iU7@mid.individual.net> <36081992-3483-4719-8fa7-c49d256155c4@googlegroups.com> <oaes52$34d$1@dont-email.me> <65fe56dc-d555-40c4-84b1-ae83e5913810@googlegroups.com> <ej0hvkFhe9iU11@mid.individual.net> <ej0if2Fhe9iU13@mid.individual.net> <87d1dgpk3p.fsf@gmail.com> <ej1hcnFhe9iU16@mid.individual.net>
Date: Fri, 17 Mar 2017 07:59:55 +0000
Message-ID: <87lgs4wcxw.fsf@gmail.com>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)
Cancel-Lock: sha1:HmJxHaD8Yf3FjZLqeSM76BJ1VmU=
MIME-Version: 1.0
Content-Type: text/plain
Lines: 34
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-JHgQx4mFh+OvPEEeBmbk+JObV8LndkGSw7b21MwxWBcn73EKsGeZMJqw37Ch3zsZhQBdVmOV5CycXIQ!0U+1CNGSCl9ObyZ3N40No+w7udRV71XOYXjLrIZzHW8FlX5D7kvjs2dVcDnl/O/rW28+UQA=
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 3189
Xref: csiph.com comp.lang.c: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.