From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 2F76E13832E for ; Fri, 19 Aug 2016 21:41:26 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 8C68CE0B74; Fri, 19 Aug 2016 21:41:17 +0000 (UTC) Received: from omr-m008e.mx.aol.com (omr-m008e.mx.aol.com [204.29.186.7]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 97F12E0B2B for ; Fri, 19 Aug 2016 21:41:16 +0000 (UTC) Received: from mtaout-mcc01.mx.aol.com (mtaout-mcc01.mx.aol.com [172.26.253.77]) by omr-m008e.mx.aol.com (Outbound Mail Relay) with ESMTP id B2DBB3800095 for ; Fri, 19 Aug 2016 17:41:15 -0400 (EDT) Received: from [192.168.1.52] (0x5b3139322e3136382e312e35325d [71.122.242.106]) by mtaout-mcc01.mx.aol.com (MUA/Third Party Client Interface) with ESMTPA id 5BB4738000082; Fri, 19 Aug 2016 17:41:15 -0400 (EDT) Subject: Re: [gentoo-dev] New project: LLVM To: gentoo-dev@lists.gentoo.org References: <20160816182204.61c27681.mgorny@gentoo.org> <20160819020737.5419083.98443.119986@pathscale.com> <36efd7a3-ce51-43ed-8aef-e1d6d79a4e5d@gentoo.org> <1b9f33d3-3807-bf55-f021-3ecfb0654c7d@verizon.net> <905c6752-af7d-f19e-2698-b31f2ee5f89d@verizon.net> From: james Message-ID: Date: Fri, 19 Aug 2016 17:41:13 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit x-aol-global-disposition: G x-aol-sid: 3039ac1afd4d57b77cfb7064 X-AOL-IP: 71.122.242.106 X-Archives-Salt: 7e905e3d-f268-49d5-a80a-e46dc693aa18 X-Archives-Hash: 7f117ae7a150ca7b79158f98ae319ebe On 08/19/2016 05:05 PM, C Bergström wrote: > On Sat, Aug 20, 2016 at 4:52 AM, james wrote: > > > 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