1 |
On 08/19/2016 05:05 PM, C Bergström wrote: |
2 |
> On Sat, Aug 20, 2016 at 4:52 AM, james <garftd@×××××××.net> wrote: |
3 |
> |
4 |
> <snip> |
5 |
> |
6 |
|
7 |
You removed your rude remark::: |
8 |
" Sorry to be the party crasher, but..." |
9 |
|
10 |
So let's put it back, just for clarity. |
11 |
|
12 |
|
13 |
>>> Back to my own glass house.. It will take a few years, but I am trying |
14 |
>>> to make it easier (internally) to expose in some clear way all the |
15 |
>>> pieces which compose a fine tuning per-processor. If this was "just" |
16 |
>>> scheduling models it would be really easy, but it's not.. Those |
17 |
>>> latencies and other magic bits decide things like.. "should I unroll |
18 |
>>> this loop or do something else" and then you venture into the land of |
19 |
>>> accelerators where a custom regalloc may be what you really need and |
20 |
>>> *nothing* off the shelf fits to meet your goals.. (projects like that |
21 |
>>> can take 9 months and in the end only give a general 1-5% median |
22 |
>>> performance gain..) |
23 |
>> |
24 |
>> |
25 |
>> If this is your mantra, I resend the generous comments. Cray use to work |
26 |
>> that way, milking the Petroleum Industry for tons of money, but, things have |
27 |
>> changed and the change is accelerating, rapidly. Perhaps too much off those |
28 |
>> Cray patents that your company owns are leaking toxins into the brain-trust |
29 |
>> where you park? |
30 |
>> |
31 |
>> Vendor walk-back is sad, imho. ymmv. |
32 |
>> |
33 |
>> Best of luck to your company's 5-year plan.... |
34 |
> |
35 |
> I have no idea what on earth you were trying to say in most of your |
36 |
> reply. I am speaking only from a compiler perspective. Nothing more |
37 |
> and nothing less.. it may be my difficultly to describe the target |
38 |
> level and processor specific optimization choices a compiler *must* |
39 |
> make. |
40 |
|
41 |
Nobody disagreed with the principals you espoused. If compiler |
42 |
development and optimizations all occurred glacially as you suggest for |
43 |
all things related, we'd be nowhere near where the industry currently |
44 |
is. In fact this sort of work is greatly accelerating. ymmv. So, I |
45 |
included some prose to 'encourage' folks that this work is open to all |
46 |
and a very prosperous area. Just because I dipped a bit into the |
47 |
financial status of folks involved, is no reason for you to be insulted. |
48 |
Facts are facts and the assimilation of diverse data usually enhances |
49 |
one's personal evaluation of where they should spend their technical |
50 |
attention. |
51 |
|
52 |
|
53 |
> Beyond not understanding your email, I found it insulting. |
54 |
|
55 |
If you did not understand what I wrote, how could you be insulted? |
56 |
|
57 |
|
58 |
> So please keep rude comments to yourself. |
59 |
|
60 |
Right back at you. Your opening remark |
61 |
"Sorry to be the party crasher, but..." |
62 |
|
63 |
Was found by me to be highly insulting, inaccurate and discouraging to |
64 |
folks to learn about some of the inner goals of HPC. |
65 |
|
66 |
It was totally rude and discouraging. Keep that sort of attitude to |
67 |
yourself, thank you. It's simple to ignore what you do not like or |
68 |
disagree with, most of us do that all the time. YOU direct an insult |
69 |
directly at me, high or low brow, your gonna get 'domain data', that |
70 |
sheds light, right back at you. |
71 |
|
72 |
|
73 |
> So again to try to explain the technical side of this - We can't and |
74 |
> have no desire to optimize for every class of processor on the planet. |
75 |
> We have a narrow band of focus on mostly HPC centric code patterns and |
76 |
> processors which are are typically used in HPC workloads. I'd love to |
77 |
> expand past this, but we're a small company and that's our niche. |
78 |
> There's no walking back or trying to claim to be something we're not.. |
79 |
> this is pure honest transparency. (imagine it like - do one thing and |
80 |
> do it well) |
81 |
> |
82 |
> The only special note I'd add on to this - the CPU isn't where we |
83 |
> spend most of our time tuning, it's by far more on the accelerator |
84 |
> support. |
85 |
|
86 |
|
87 |
hth, |
88 |
James |