| 1 |
On Sat, Aug 20, 2016 at 4:52 AM, james <garftd@×××××××.net> wrote: |
| 2 |
|
| 3 |
<snip> |
| 4 |
|
| 5 |
>> Back to my own glass house.. It will take a few years, but I am trying |
| 6 |
>> to make it easier (internally) to expose in some clear way all the |
| 7 |
>> pieces which compose a fine tuning per-processor. If this was "just" |
| 8 |
>> scheduling models it would be really easy, but it's not.. Those |
| 9 |
>> latencies and other magic bits decide things like.. "should I unroll |
| 10 |
>> this loop or do something else" and then you venture into the land of |
| 11 |
>> accelerators where a custom regalloc may be what you really need and |
| 12 |
>> *nothing* off the shelf fits to meet your goals.. (projects like that |
| 13 |
>> can take 9 months and in the end only give a general 1-5% median |
| 14 |
>> performance gain..) |
| 15 |
> |
| 16 |
> |
| 17 |
> If this is your mantra, I resend the generous comments. Cray use to work |
| 18 |
> that way, milking the Petroleum Industry for tons of money, but, things have |
| 19 |
> changed and the change is accelerating, rapidly. Perhaps too much off those |
| 20 |
> Cray patents that your company owns are leaking toxins into the brain-trust |
| 21 |
> where you park? |
| 22 |
> |
| 23 |
> Vendor walk-back is sad, imho. ymmv. |
| 24 |
> |
| 25 |
> Best of luck to your company's 5-year plan.... |
| 26 |
|
| 27 |
I have no idea what on earth you were trying to say in most of your |
| 28 |
reply. I am speaking only from a compiler perspective. Nothing more |
| 29 |
and nothing less.. it may be my difficultly to describe the target |
| 30 |
level and processor specific optimization choices a compiler *must* |
| 31 |
make. |
| 32 |
|
| 33 |
Beyond not understanding your email, I found it insulting. So please |
| 34 |
keep rude comments to yourself. |
| 35 |
|
| 36 |
So again to try to explain the technical side of this - We can't and |
| 37 |
have no desire to optimize for every class of processor on the planet. |
| 38 |
We have a narrow band of focus on mostly HPC centric code patterns and |
| 39 |
processors which are are typically used in HPC workloads. I'd love to |
| 40 |
expand past this, but we're a small company and that's our niche. |
| 41 |
There's no walking back or trying to claim to be something we're not.. |
| 42 |
this is pure honest transparency. (imagine it like - do one thing and |
| 43 |
do it well) |
| 44 |
|
| 45 |
The only special note I'd add on to this - the CPU isn't where we |
| 46 |
spend most of our time tuning, it's by far more on the accelerator |
| 47 |
support. |
Archives