Re: [gentoo-dev] New project: LLVM

[james]

On 08/19/2016 05:05 PM, C Bergström wrote:
> On Sat, Aug 20, 2016 at 4:52 AM, james <garftd@×××××××.net> wrote:
>
> <snip>
>

You removed your rude remark:::
" Sorry to be the party crasher, but..."

So let's put it back, just for clarity.


>>> Back to my own glass house.. It will take a few years, but I am trying
>>> to make it easier (internally) to expose in some clear way all the
>>> pieces which compose a fine tuning per-processor. If this was "just"
>>> scheduling models it would be really easy, but it's not.. Those
>>> latencies and other magic bits decide things like.. "should I unroll
>>> this loop or do something else" and then you venture into the land of
>>> accelerators where a custom regalloc may be what you really need and
>>> *nothing* off the shelf fits to meet your goals.. (projects like that
>>> can take 9 months and in the end only give a general 1-5% median
>>> performance gain..)
>>
>>
>> If this is your mantra, I resend the generous comments. Cray use to work
>> that way, milking the Petroleum Industry for tons of money, but, things have
>> changed and the change is accelerating, rapidly. Perhaps too much off those
>> Cray patents that your company owns are leaking toxins into the brain-trust
>> where you park?
>>
>> Vendor walk-back is sad, imho. ymmv.
>>
>> Best of luck to your company's  5-year plan....
>
> I have no idea what on earth you were trying to say in most of your
> reply. I am speaking only from a compiler perspective. Nothing more
> and nothing less.. it may be my difficultly to describe the target
> level and processor specific optimization choices a compiler *must*
> make.

Nobody disagreed with the principals you espoused. If compiler 
development and optimizations all  occurred glacially as you suggest for 
all things related, we'd be nowhere near where the industry currently 
is. In fact this sort of work is greatly accelerating. ymmv. So, I 
included some prose to 'encourage' folks that this work is open to all 
and a very prosperous area. Just because I dipped a bit into the 
financial status of folks involved, is no reason for you to be insulted.
Facts are facts and the assimilation of diverse data usually enhances 
one's personal evaluation of where they should spend their technical 
attention.


> Beyond not understanding your email, I found it insulting.

If you did not understand what I wrote, how could you be insulted?


 > So please keep rude comments to yourself.

Right back at you. Your opening remark
"Sorry to be the party crasher, but..."

  Was found by me to be highly insulting, inaccurate and discouraging to 
folks to learn about some of the inner goals of HPC.

It was totally rude and discouraging. Keep that sort of attitude to 
yourself, thank you. It's simple to ignore what you do not like or 
disagree with, most of us do that all the time. YOU direct an insult 
directly at me, high or low brow, your gonna get 'domain data', that 
sheds light, right back at you.


> So again to try to explain the technical side of this - We can't and
> have no desire to optimize for every class of processor on the planet.
> We have a narrow band of focus on mostly HPC centric code patterns and
> processors which are are typically used in HPC workloads. I'd love to
> expand past this, but we're a small company and that's our niche.
> There's no walking back or trying to claim to be something we're not..
> this is pure honest transparency. (imagine it like - do one thing and
> do it well)
>
> The only special note I'd add on to this - the CPU isn't where we
> spend most of our time tuning, it's by far more on the accelerator
> support.


hth,
James