On 08/19/2016 05:05 PM, C Bergström wrote:
On Sat, Aug 20, 2016 at 4:52 AM, james <gar...@verizon.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
