* [gentoo-dev] New project: LLVM @ 2016-08-16 16:22 Michał Górny 2016-08-18 13:48 ` Ian Bloss 0 siblings, 1 reply; 20+ messages in thread From: Michał Górny @ 2016-08-16 16:22 UTC (permalink / raw To: gentoo-dev-announce; +Cc: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 390 bytes --] Hello, everyone. I have the pleasure of announcing that after the long period of split maintenance, we are forming an united LLVM project [1] to maintain all of LLVM packages in Gentoo and work on establishing improved support for a healthy, gcc-free ecosystem. [1]:https://wiki.gentoo.org/wiki/Project:LLVM -- Best regards, Michał Górny <http://dev.gentoo.org/~mgorny/> [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 949 bytes --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [gentoo-dev] New project: LLVM 2016-08-16 16:22 [gentoo-dev] New project: LLVM Michał Górny @ 2016-08-18 13:48 ` Ian Bloss 2016-08-18 13:56 ` C Bergström 0 siblings, 1 reply; 20+ messages in thread From: Ian Bloss @ 2016-08-18 13:48 UTC (permalink / raw To: gentoo-dev, gentoo-dev-announce [-- Attachment #1: Type: text/plain, Size: 522 bytes --] Woot! Don't tell Stallman lol. On Tue, Aug 16, 2016, 09:22 Michał Górny <mgorny@gentoo.org> wrote: > Hello, everyone. > > I have the pleasure of announcing that after the long period of split > maintenance, we are forming an united LLVM project [1] to maintain all > of LLVM packages in Gentoo and work on establishing improved support for > a healthy, gcc-free ecosystem. > > [1]:https://wiki.gentoo.org/wiki/Project:LLVM > > -- > Best regards, > Michał Górny > <http://dev.gentoo.org/~mgorny/> > [-- Attachment #2: Type: text/html, Size: 958 bytes --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [gentoo-dev] New project: LLVM 2016-08-18 13:48 ` Ian Bloss @ 2016-08-18 13:56 ` C Bergström 2016-08-18 23:33 ` Lei Zhang 0 siblings, 1 reply; 20+ messages in thread From: C Bergström @ 2016-08-18 13:56 UTC (permalink / raw To: Anthony G. Basile; +Cc: gentoo-dev-announce @mgorny may be able to help with some of this and has quite a bit of experience building clang/llvm. Where I work we use a "wrapper" that helps coordinate a lot of the moving pieces. https://github.com/pathscale/llvm-suite/ This may not be the perfect "gentoo" way to handle it, but the approach would produce a clean and correct compiler. With llvm dependencies getting more and more complicated, I'm not sure if it would be possible to have both a gnu-free and also perfect 1-project-source-repo:1-ebuild ratio. I'm sure there's llvm/clang ebuilds already and curious what others think.. On Thu, Aug 18, 2016 at 9:48 PM, Ian Bloss <ianlinkcd@gmail.com> wrote: > Woot! Don't tell Stallman lol. > > > On Tue, Aug 16, 2016, 09:22 Michał Górny <mgorny@gentoo.org> wrote: >> >> Hello, everyone. >> >> I have the pleasure of announcing that after the long period of split >> maintenance, we are forming an united LLVM project [1] to maintain all >> of LLVM packages in Gentoo and work on establishing improved support for >> a healthy, gcc-free ecosystem. >> >> [1]:https://wiki.gentoo.org/wiki/Project:LLVM >> >> -- >> Best regards, >> Michał Górny >> <http://dev.gentoo.org/~mgorny/> ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [gentoo-dev] New project: LLVM 2016-08-18 13:56 ` C Bergström @ 2016-08-18 23:33 ` Lei Zhang 2016-08-19 2:07 ` cbergstrom 0 siblings, 1 reply; 20+ messages in thread From: Lei Zhang @ 2016-08-18 23:33 UTC (permalink / raw To: gentoo-dev; +Cc: gentoo-dev-announce 2016-08-18 21:56 GMT+08:00 C Bergström <cbergstrom@pathscale.com>: > @mgorny may be able to help with some of this and has quite a bit of > experience building clang/llvm. Where I work we use a "wrapper" that > helps coordinate a lot of the moving pieces. > > https://github.com/pathscale/llvm-suite/ > > This may not be the perfect "gentoo" way to handle it, but the > approach would produce a clean and correct compiler. With llvm > dependencies getting more and more complicated, I'm not sure if it > would be possible to have both a gnu-free and also perfect > 1-project-source-repo:1-ebuild ratio. Currently the ebuilds for libunwind, libc++abi and libc++ all involve some hackery to support standalone build. And the package clang is just a placeholder, while it's actually built in llvm. Maybe we can put them all into the llvm package, and control what components to build via USE flags. Lei ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [gentoo-dev] New project: LLVM 2016-08-18 23:33 ` Lei Zhang @ 2016-08-19 2:07 ` cbergstrom 2016-08-19 2:40 ` Lei Zhang 0 siblings, 1 reply; 20+ messages in thread From: cbergstrom @ 2016-08-19 2:07 UTC (permalink / raw To: Lei Zhang, gentoo-dev; +Cc: gentoo-dev-announce That seems a lot like what we've already done. I guess a GSOC student is working on the libcxxabi piece. The only advantage to using our runtime, libcxxrt, is performance and code size. Original Message From: Lei Zhang Sent: Friday, August 19, 2016 06:34 To: gentoo-dev@lists.gentoo.org Reply To: gentoo-dev@lists.gentoo.org Cc: gentoo-dev-announce@lists.gentoo.org Subject: Re: [gentoo-dev] New project: LLVM 2016-08-18 21:56 GMT+08:00 C Bergström <cbergstrom@pathscale.com>: > @mgorny may be able to help with some of this and has quite a bit of > experience building clang/llvm. Where I work we use a "wrapper" that > helps coordinate a lot of the moving pieces. > > https://github.com/pathscale/llvm-suite/ > > This may not be the perfect "gentoo" way to handle it, but the > approach would produce a clean and correct compiler. With llvm > dependencies getting more and more complicated, I'm not sure if it > would be possible to have both a gnu-free and also perfect > 1-project-source-repo:1-ebuild ratio. Currently the ebuilds for libunwind, libc++abi and libc++ all involve some hackery to support standalone build. And the package clang is just a placeholder, while it's actually built in llvm. Maybe we can put them all into the llvm package, and control what components to build via USE flags. Lei ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [gentoo-dev] New project: LLVM 2016-08-19 2:07 ` cbergstrom @ 2016-08-19 2:40 ` Lei Zhang 2016-08-19 3:11 ` C Bergström 0 siblings, 1 reply; 20+ messages in thread From: Lei Zhang @ 2016-08-19 2:40 UTC (permalink / raw To: gentoo-dev, llvm 2016-08-19 10:07 GMT+08:00 <cbergstrom@pathscale.com>: > That seems a lot like what we've already done. I guess a GSOC student is working on the libcxxabi piece. I am that GSoC student :) I'm currently trying to push libc++abi to replace libcxxrt as the default runtime: https://github.com/gentoo/gentoo/pull/2048 The reason is I think libc++abi blends in more naturally with other LLVM components, and it has a clear version number as opposed to libcxxrt. > The only advantage to using our runtime, libcxxrt, is performance and code size. Honestly I don't know what essential difference these two libs have; I can't find any decent comparison of them on the internet. Do you have some real numbers to show the difference in performance and code size? Lei ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [gentoo-dev] New project: LLVM 2016-08-19 2:40 ` Lei Zhang @ 2016-08-19 3:11 ` C Bergström 2016-08-19 15:01 ` Luca Barbato 2016-08-19 16:54 ` Lei Zhang 0 siblings, 2 replies; 20+ messages in thread From: C Bergström @ 2016-08-19 3:11 UTC (permalink / raw To: Anthony G. Basile; +Cc: llvm I think you're getting a bit confused libsupc++ is the default now, from GNU libcxxabi is the bloated runtime from Apple libcxxrt is the faster c++ runtime, PathScale+David Chisnall, which PathScale and FreeBSD use by default. We don't need a version number because it's pretty much rock solid stable for a while. I'd encourage you to consider libcxxrt for at least the code size and performance reasons. Build it and you'll see. Locally my unoptimized libcxxrt.so is like 88K. How much is your libcxxabi (static and shared) 88K /opt/enzo-2016-06-26/lib/6.0.983/x8664/64/libcxxrt.so 140K /opt/enzo-2016-06-26/lib/6.0.983/x8664/64/libcxxrt.a // This seems larger than I remember and I need to check why. https://github.com/pathscale/libcxxrt On Fri, Aug 19, 2016 at 10:40 AM, Lei Zhang <zhanglei.april@gmail.com> wrote: > 2016-08-19 10:07 GMT+08:00 <cbergstrom@pathscale.com>: >> That seems a lot like what we've already done. I guess a GSOC student is working on the libcxxabi piece. > > I am that GSoC student :) > > I'm currently trying to push libc++abi to replace libcxxrt as the > default runtime: https://github.com/gentoo/gentoo/pull/2048 > > The reason is I think libc++abi blends in more naturally with other > LLVM components, and it has a clear version number as opposed to > libcxxrt. > >> The only advantage to using our runtime, libcxxrt, is performance and code size. > > Honestly I don't know what essential difference these two libs have; I > can't find any decent comparison of them on the internet. Do you have > some real numbers to show the difference in performance and code size? > > > Lei > ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [gentoo-dev] New project: LLVM 2016-08-19 3:11 ` C Bergström @ 2016-08-19 15:01 ` Luca Barbato 2016-08-19 15:15 ` C Bergström 2016-08-19 16:54 ` Lei Zhang 1 sibling, 1 reply; 20+ messages in thread From: Luca Barbato @ 2016-08-19 15:01 UTC (permalink / raw To: gentoo-dev On 19/08/16 05:11, C Bergström wrote: > I think you're getting a bit confused > > libsupc++ is the default now, from GNU > > libcxxabi is the bloated runtime from Apple > > libcxxrt is the faster c++ runtime, PathScale+David Chisnall, which > PathScale and FreeBSD use by default. We don't need a version number > because it's pretty much rock solid stable for a while. C++ is evolving so it will be needed in the future =) Please consider adding some versions even if it is a bourden. > I'd encourage you to consider libcxxrt for at least the code size and > performance reasons. Build it and you'll see. Locally my unoptimized > libcxxrt.so is like 88K. How much is your libcxxabi (static and > shared) > > 88K /opt/enzo-2016-06-26/lib/6.0.983/x8664/64/libcxxrt.so > 140K /opt/enzo-2016-06-26/lib/6.0.983/x8664/64/libcxxrt.a > // This seems larger than I remember and I need to check why. > > https://github.com/pathscale/libcxxrt BTW is pathscale ready to be used as system compiler as well? lu ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [gentoo-dev] New project: LLVM 2016-08-19 15:01 ` Luca Barbato @ 2016-08-19 15:15 ` C Bergström 2016-08-19 17:38 ` Luca Barbato 2016-08-19 18:02 ` james 0 siblings, 2 replies; 20+ messages in thread From: C Bergström @ 2016-08-19 15:15 UTC (permalink / raw To: Anthony G. Basile On Fri, Aug 19, 2016 at 11:01 PM, Luca Barbato <lu_zero@gentoo.org> wrote: > BTW is pathscale ready to be used as system compiler as well? I wish, but no. We have known issues when building grub2, glibc and the Linux kernel at the very least. Someone* did report a long time ago that with their unofficial port, were able to build/boot the NetBSD kernel. (*A community dev we trusted with our sources and was helping us with portability across platforms) The stuff with grub2 may potentially be fixed in the "near" future... the others are more tricky. In general if clang can do it, we have a strong chance as well. As a philosophy - "we" aren't really trying to be the best generic compiler in the world. We aim more on optimizing as much for known targets. So if by system you mean, a compiler that would produce an "OS" which only runs on a single class of hardware, then yeah it could work at some point in the future. Specifically, on x86 we default on host CPU optimizations. So on newer Intel hardware it's easy to get a binary that won't run on AMD or older 64bit Intel. More recently on ARMv8 - we turn on processor specific tuning. So while it may "run", the difference between APM's mustang and Cavium ThunderX is pretty big and running binaries intended for A and ran on B would certainly take a hit.. (this is just the tip of the iceberg) For general scalar OS code it isn't likely to matter... the real impact being like 1-10% difference (being very general.. it could be less or more in the real world..) For HPC codes or anything where you get loops or computationally complex - the gloves are off and I could see big differences... (again being general and maybe a bit dramatic for fun) ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [gentoo-dev] New project: LLVM 2016-08-19 15:15 ` C Bergström @ 2016-08-19 17:38 ` Luca Barbato 2016-08-19 18:02 ` james 1 sibling, 0 replies; 20+ messages in thread From: Luca Barbato @ 2016-08-19 17:38 UTC (permalink / raw To: gentoo-dev On 19/08/16 17:15, C Bergström wrote: > On Fri, Aug 19, 2016 at 11:01 PM, Luca Barbato <lu_zero@gentoo.org> wrote: >> BTW is pathscale ready to be used as system compiler as well? > > I wish, but no. We have known issues when building grub2, glibc and > the Linux kernel at the very least. Someone* did report a long time > ago that with their unofficial port, were able to build/boot the > NetBSD kernel. > (*A community dev we trusted with our sources and was helping us with > portability across platforms) > > The stuff with grub2 may potentially be fixed in the "near" future... > the others are more tricky. In general if clang can do it, we have a > strong chance as well. I see, it is getting quite close =) > As a philosophy - "we" aren't really trying to be the best generic > compiler in the world. We aim more on optimizing as much for known > targets. So if by system you mean, a compiler that would produce an > "OS" which only runs on a single class of hardware, then yeah it could > work at some point in the future. Specifically, on x86 we default on > host CPU optimizations. So on newer Intel hardware it's easy to get a > binary that won't run on AMD or older 64bit Intel. > > More recently on ARMv8 - we turn on processor specific tuning. So > while it may "run", the difference between APM's mustang and Cavium > ThunderX is pretty big and running binaries intended for A and ran on > B would certainly take a hit.. (this is just the tip of the iceberg) This is not a problem for Gentoo, actually sounds a good match for one of our many use-cases =) > For HPC codes or anything where you get loops or computationally > complex - the gloves are off and I could see big differences... (again > being general and maybe a bit dramatic for fun) I started to do some decoding benchmark across compiler version some time ago, I should try to put in the mix your compiler as well and eventually blog about it =) lu ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [gentoo-dev] New project: LLVM 2016-08-19 15:15 ` C Bergström 2016-08-19 17:38 ` Luca Barbato @ 2016-08-19 18:02 ` james 2016-08-19 18:20 ` C Bergström 1 sibling, 1 reply; 20+ messages in thread From: james @ 2016-08-19 18:02 UTC (permalink / raw To: gentoo-dev On 08/19/2016 11:15 AM, C Bergström wrote: > On Fri, Aug 19, 2016 at 11:01 PM, Luca Barbato <lu_zero@gentoo.org> wrote: >> BTW is pathscale ready to be used as system compiler as well? > > I wish, but no. We have known issues when building grub2, glibc and > the Linux kernel at the very least. Someone* did report a long time > ago that with their unofficial port, were able to build/boot the > NetBSD kernel. > (*A community dev we trusted with our sources and was helping us with > portability across platforms) > > The stuff with grub2 may potentially be fixed in the "near" future... > the others are more tricky. In general if clang can do it, we have a > strong chance as well. > > As a philosophy - "we" aren't really trying to be the best generic > compiler in the world. We aim more on optimizing as much for known > targets. So if by system you mean, a compiler that would produce an > "OS" which only runs on a single class of hardware, then yeah it could > work at some point in the future. Specifically, on x86 we default on > host CPU optimizations. So on newer Intel hardware it's easy to get a > binary that won't run on AMD or older 64bit Intel. > > More recently on ARMv8 - we turn on processor specific tuning. So > while it may "run", the difference between APM's mustang and Cavium > ThunderX is pretty big and running binaries intended for A and ran on > B would certainly take a hit.. (this is just the tip of the iceberg) > > For general scalar OS code it isn't likely to matter... the real > impact being like 1-10% difference (being very general.. it could be > less or more in the real world..) > > For HPC codes or anything where you get loops or computationally > complex - the gloves are off and I could see big differences... (again > being general and maybe a bit dramatic for fun) OK (actually fantastic!). Looking at the pathscale site pages and github, perhaps a cheap arm embedded board where llvm is the centerpiece of compiling a minimal system to entice gentoo-llvm testers, would be possible in the near future?. I have a 96boards, HiKey arm64v8 that I could dedicate to gentoo+armv8-llvm testing, if that'd help. [1] Perhaps a baseline bootstrap iso (or such) version targeted at llvm-centric testers on x86-64 or armv8 ? Skip grub2 and use grub-legacy or lilo or (?), since there seems to be issues with llvm-grub2. [1] http://dev.gentoo.org/~tgall/ No matter how you slice it, from someone who is focused on building minimized and embedded (bare metal) systems that are customized and coalesced into a heterogeneous gentoo cluster for HPC, this is wonderful news. Finally a vendor in the cluster space, with some vision and common-sense, imho. Heterogeneous and open HPC is where is at, imho. If there is a forum where the community and pathscale folks discuss issues, point that out as I could not find one for deeper reading.... hth, James ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [gentoo-dev] New project: LLVM 2016-08-19 18:02 ` james @ 2016-08-19 18:20 ` C Bergström 2016-08-19 20:52 ` james 0 siblings, 1 reply; 20+ messages in thread From: C Bergström @ 2016-08-19 18:20 UTC (permalink / raw To: Anthony G. Basile Sorry to be the party crasher, but... I'd love to have optimizations for everything out there, but it takes a lot of work to fine tune for something specific. Right now I see a few variants of ARMv8 ------------ ARM reference stuff - A57 cores and the newer bits.. The scheduling and stuff seems more-or-less similar enough that one tuning could probably work for the vast majority of these parts. Cavium ThunderX - It's ground up and quite different from the ARM reference stuff under the hood APM - Mustang, again ground up and different. I don't have enough hands on to know how different from reference. Broadcom - Coming Soon(tm) - Again no hands on or any data, but certainly very interesting.. ... now add in every variant of ground up implementation and you have 50 shades of gray.. ------------- Soo.. depending on your target hardware, you may be better off with gcc if the end goal is general all-around performance. (It does a quite respectable job of being generic) I realize a lot of people have strong feelings for or against it. I leave that to the reader to decide.. 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..) -------------- On Sat, Aug 20, 2016 at 2:02 AM, james <garftd@verizon.net> wrote: > On 08/19/2016 11:15 AM, C Bergström wrote: >> >> On Fri, Aug 19, 2016 at 11:01 PM, Luca Barbato <lu_zero@gentoo.org> wrote: >>> >>> BTW is pathscale ready to be used as system compiler as well? >> >> >> I wish, but no. We have known issues when building grub2, glibc and >> the Linux kernel at the very least. Someone* did report a long time >> ago that with their unofficial port, were able to build/boot the >> NetBSD kernel. >> (*A community dev we trusted with our sources and was helping us with >> portability across platforms) >> >> The stuff with grub2 may potentially be fixed in the "near" future... >> the others are more tricky. In general if clang can do it, we have a >> strong chance as well. >> >> As a philosophy - "we" aren't really trying to be the best generic >> compiler in the world. We aim more on optimizing as much for known >> targets. So if by system you mean, a compiler that would produce an >> "OS" which only runs on a single class of hardware, then yeah it could >> work at some point in the future. Specifically, on x86 we default on >> host CPU optimizations. So on newer Intel hardware it's easy to get a >> binary that won't run on AMD or older 64bit Intel. >> >> More recently on ARMv8 - we turn on processor specific tuning. So >> while it may "run", the difference between APM's mustang and Cavium >> ThunderX is pretty big and running binaries intended for A and ran on >> B would certainly take a hit.. (this is just the tip of the iceberg) >> >> For general scalar OS code it isn't likely to matter... the real >> impact being like 1-10% difference (being very general.. it could be >> less or more in the real world..) >> >> For HPC codes or anything where you get loops or computationally >> complex - the gloves are off and I could see big differences... (again >> being general and maybe a bit dramatic for fun) > > > > OK (actually fantastic!). Looking at the pathscale site pages and github, > perhaps a cheap arm embedded board where llvm is the centerpiece of > compiling a minimal system to entice gentoo-llvm testers, would be possible > in the near future?. I have a 96boards, HiKey arm64v8 that I could dedicate > to gentoo+armv8-llvm testing, if that'd help. [1] > > Perhaps a baseline bootstrap iso (or such) version targeted at > llvm-centric testers on x86-64 or armv8 ? Skip grub2 and use grub-legacy or > lilo or (?), since there seems to be issues with llvm-grub2. > > > [1] http://dev.gentoo.org/~tgall/ > > > No matter how you slice it, from someone who is focused on building > minimized and embedded (bare metal) systems that are customized and > coalesced into a heterogeneous gentoo cluster for HPC, this is wonderful > news. Finally a vendor in the cluster space, with some vision and > common-sense, imho. Heterogeneous and open HPC is where is at, imho. If > there is a forum where the community and pathscale folks discuss issues, > point that out as I could not find one for deeper reading.... > > > hth, > James > ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [gentoo-dev] New project: LLVM 2016-08-19 18:20 ` C Bergström @ 2016-08-19 20:52 ` james 2016-08-19 21:05 ` C Bergström 0 siblings, 1 reply; 20+ messages in thread From: james @ 2016-08-19 20:52 UTC (permalink / raw To: gentoo-dev On 08/19/2016 02:20 PM, C Bergström wrote: > Sorry to be the party crasher, but... > > I'd love to have optimizations for everything out there, but it takes > a lot of work to fine tune for something specific. Agreed. Right now on Armv8 alone, there are dozens of teams working on the identical concepts presented in this thread. Most are also targeting specific domains. At some point there with pathways, just like in Computational Chemistry, where the optimization pathway for new silicon is fast and previous work helps tremendously. That is, you are not alone in your quests, far, far from it. > Right now I see a few variants of ARMv8 > ------------ > ARM reference stuff - A57 cores and the newer bits.. The scheduling > and stuff seems more-or-less similar enough that one tuning could > probably work for the vast majority of these parts. > > Cavium ThunderX - It's ground up and quite different from the ARM > reference stuff under the hood > > APM - Mustang, again ground up and different. I don't have enough > hands on to know how different from reference. > > Broadcom - Coming Soon(tm) - Again no hands on or any data, but > certainly very interesting.. > > ... now add in every variant of ground up implementation and you have > 50 shades of gray.. And billions of dollars financing those efforts in parallel. It's an arms race, (like the pun?). Wonder why a Japanese conglomerate offered to purchase ARM ltd. for such a large figure? Wonder why intel has arm licenses now? Your group might only be able to focus on a few ARM offerings, but there are dozens and dozens of ARM teams alone that would dispute your arithmetic above. > ------------- > Soo.. depending on your target hardware, you may be better off with > gcc if the end goal is general all-around performance. (It does a > quite respectable job of being generic) I realize a lot of people have > strong feelings for or against it. I leave that to the reader to > decide.. You misconstrue concepts. Nobody, especially me, implies that one pathway (to a Unikernel [1] if you like) suites all near-optimized solutions. That would be pointless. What you allude to, already exists in some of the more progressive data/cloud vendor clouds. We are talking about a unikernel for different classes of problems, across arm8 and x86-64 and GPU architectures, not thousands of (arch) processor variants. However, those other processor (arch) variants and the folks that earn a living off of those variants, are not sitting back idle, either. > 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.... [2] http://unikernel.org/ hth, James > -------------- > > > On Sat, Aug 20, 2016 at 2:02 AM, james <garftd@verizon.net> wrote: >> On 08/19/2016 11:15 AM, C Bergström wrote: >>> >>> On Fri, Aug 19, 2016 at 11:01 PM, Luca Barbato <lu_zero@gentoo.org> wrote: >>>> >>>> BTW is pathscale ready to be used as system compiler as well? >>> >>> >>> I wish, but no. We have known issues when building grub2, glibc and >>> the Linux kernel at the very least. Someone* did report a long time >>> ago that with their unofficial port, were able to build/boot the >>> NetBSD kernel. >>> (*A community dev we trusted with our sources and was helping us with >>> portability across platforms) >>> >>> The stuff with grub2 may potentially be fixed in the "near" future... >>> the others are more tricky. In general if clang can do it, we have a >>> strong chance as well. >>> >>> As a philosophy - "we" aren't really trying to be the best generic >>> compiler in the world. We aim more on optimizing as much for known >>> targets. So if by system you mean, a compiler that would produce an >>> "OS" which only runs on a single class of hardware, then yeah it could >>> work at some point in the future. Specifically, on x86 we default on >>> host CPU optimizations. So on newer Intel hardware it's easy to get a >>> binary that won't run on AMD or older 64bit Intel. >>> >>> More recently on ARMv8 - we turn on processor specific tuning. So >>> while it may "run", the difference between APM's mustang and Cavium >>> ThunderX is pretty big and running binaries intended for A and ran on >>> B would certainly take a hit.. (this is just the tip of the iceberg) >>> >>> For general scalar OS code it isn't likely to matter... the real >>> impact being like 1-10% difference (being very general.. it could be >>> less or more in the real world..) >>> >>> For HPC codes or anything where you get loops or computationally >>> complex - the gloves are off and I could see big differences... (again >>> being general and maybe a bit dramatic for fun) >> >> >> >> OK (actually fantastic!). Looking at the pathscale site pages and github, >> perhaps a cheap arm embedded board where llvm is the centerpiece of >> compiling a minimal system to entice gentoo-llvm testers, would be possible >> in the near future?. I have a 96boards, HiKey arm64v8 that I could dedicate >> to gentoo+armv8-llvm testing, if that'd help. [1] >> >> Perhaps a baseline bootstrap iso (or such) version targeted at >> llvm-centric testers on x86-64 or armv8 ? Skip grub2 and use grub-legacy or >> lilo or (?), since there seems to be issues with llvm-grub2. >> >> >> [1] http://dev.gentoo.org/~tgall/ >> >> >> No matter how you slice it, from someone who is focused on building >> minimized and embedded (bare metal) systems that are customized and >> coalesced into a heterogeneous gentoo cluster for HPC, this is wonderful >> news. Finally a vendor in the cluster space, with some vision and >> common-sense, imho. Heterogeneous and open HPC is where is at, imho. If >> there is a forum where the community and pathscale folks discuss issues, >> point that out as I could not find one for deeper reading.... >> >> >> hth, >> James >> > > ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [gentoo-dev] New project: LLVM 2016-08-19 20:52 ` james @ 2016-08-19 21:05 ` C Bergström 2016-08-19 21:41 ` james 0 siblings, 1 reply; 20+ messages in thread From: C Bergström @ 2016-08-19 21:05 UTC (permalink / raw To: Anthony G. Basile On Sat, Aug 20, 2016 at 4:52 AM, james <garftd@verizon.net> wrote: <snip> >> 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. Beyond not understanding your email, I found it insulting. So please keep rude comments to yourself. 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. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [gentoo-dev] New project: LLVM 2016-08-19 21:05 ` C Bergström @ 2016-08-19 21:41 ` james 2016-08-20 5:45 ` C Bergström 0 siblings, 1 reply; 20+ messages in thread From: james @ 2016-08-19 21:41 UTC (permalink / raw To: gentoo-dev On 08/19/2016 05:05 PM, C Bergström wrote: > On Sat, Aug 20, 2016 at 4:52 AM, james <garftd@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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [gentoo-dev] New project: LLVM 2016-08-19 21:41 ` james @ 2016-08-20 5:45 ` C Bergström 0 siblings, 0 replies; 20+ messages in thread From: C Bergström @ 2016-08-20 5:45 UTC (permalink / raw To: Anthony G. Basile On Sat, Aug 20, 2016 at 5:41 AM, james <garftd@verizon.net> wrote: > On 08/19/2016 05:05 PM, C Bergström wrote: >> >> On Sat, Aug 20, 2016 at 4:52 AM, james <garftd@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. I'll forgive you because it seems English may not be your native language, but this expression is rarely to never seen as offensive. Further, you should be able to infer I was talking about *my* own party. I was clarifying about the limitations of using "my" compiler in a system context. This had nothing to do you. So again please keep your tone civil, adult and if possible on-topic. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [gentoo-dev] New project: LLVM 2016-08-19 3:11 ` C Bergström 2016-08-19 15:01 ` Luca Barbato @ 2016-08-19 16:54 ` Lei Zhang 2016-08-19 17:13 ` C Bergström 1 sibling, 1 reply; 20+ messages in thread From: Lei Zhang @ 2016-08-19 16:54 UTC (permalink / raw To: gentoo-dev; +Cc: llvm 2016-08-19 11:11 GMT+08:00 C Bergström <cbergstrom@pathscale.com>: > I think you're getting a bit confused > > libsupc++ is the default now, from GNU > > libcxxabi is the bloated runtime from Apple > > libcxxrt is the faster c++ runtime, PathScale+David Chisnall, which > PathScale and FreeBSD use by default. We don't need a version number > because it's pretty much rock solid stable for a while. > I'd encourage you to consider libcxxrt for at least the code size and > performance reasons. Build it and you'll see. Locally my unoptimized > libcxxrt.so is like 88K. How much is your libcxxabi (static and > shared) > > 88K /opt/enzo-2016-06-26/lib/6.0.983/x8664/64/libcxxrt.so > 140K /opt/enzo-2016-06-26/lib/6.0.983/x8664/64/libcxxrt.a > // This seems larger than I remember and I need to check why. > > https://github.com/pathscale/libcxxrt Currently libcxxrt is the default ABI lib for libc++ in Gentoo. I mean to replace it with libc++abi in that context. I'm interested in benchmarking to reveal the claimed difference in performance. Perhaps I can build the same program against libcxxrt and libc++abi respectively and see how it behaves. Do you have some hints on what kind of programs I should test? Thanks, Lei ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [gentoo-dev] New project: LLVM 2016-08-19 16:54 ` Lei Zhang @ 2016-08-19 17:13 ` C Bergström 2016-08-19 17:34 ` Luca Barbato 2016-08-21 1:10 ` Lei Zhang 0 siblings, 2 replies; 20+ messages in thread From: C Bergström @ 2016-08-19 17:13 UTC (permalink / raw To: Anthony G. Basile; +Cc: llvm I finally got it to build and here's the size numbers 952K ./lib/libc++abi.a 616K ./lib/libc++abi.so.1.0 If the above isn't enough motivation and you really want benchmarks which prove it's a pig... I'll try to figure something else Not exactly a 1:1 comparison because I think other things are mixed in, but... 352K /usr/lib/gcc/x86_64-linux-gnu/4.9/libsupc++.a 356K /usr/lib/gcc/x86_64-linux-gnu/5/libsupc++.a In the land of HPC we frequently statically link stuff... not that 864KB is big by any sort of modern definition, but it does raise questions.. On Sat, Aug 20, 2016 at 12:54 AM, Lei Zhang <zhanglei.april@gmail.com> wrote: > 2016-08-19 11:11 GMT+08:00 C Bergström <cbergstrom@pathscale.com>: >> I think you're getting a bit confused >> >> libsupc++ is the default now, from GNU >> >> libcxxabi is the bloated runtime from Apple >> >> libcxxrt is the faster c++ runtime, PathScale+David Chisnall, which >> PathScale and FreeBSD use by default. We don't need a version number >> because it's pretty much rock solid stable for a while. >> I'd encourage you to consider libcxxrt for at least the code size and >> performance reasons. Build it and you'll see. Locally my unoptimized >> libcxxrt.so is like 88K. How much is your libcxxabi (static and >> shared) >> >> 88K /opt/enzo-2016-06-26/lib/6.0.983/x8664/64/libcxxrt.so >> 140K /opt/enzo-2016-06-26/lib/6.0.983/x8664/64/libcxxrt.a >> // This seems larger than I remember and I need to check why. >> >> https://github.com/pathscale/libcxxrt > > Currently libcxxrt is the default ABI lib for libc++ in Gentoo. I mean > to replace it with libc++abi in that context. > > I'm interested in benchmarking to reveal the claimed difference in > performance. Perhaps I can build the same program against libcxxrt and > libc++abi respectively and see how it behaves. Do you have some hints > on what kind of programs I should test? > > > Thanks, > Lei > ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [gentoo-dev] New project: LLVM 2016-08-19 17:13 ` C Bergström @ 2016-08-19 17:34 ` Luca Barbato 2016-08-21 1:10 ` Lei Zhang 1 sibling, 0 replies; 20+ messages in thread From: Luca Barbato @ 2016-08-19 17:34 UTC (permalink / raw To: C Bergström, gentoo-dev; +Cc: llvm On 19/08/16 19:13, C Bergström wrote: > I finally got it to build and here's the size numbers > 952K ./lib/libc++abi.a > 616K ./lib/libc++abi.so.1.0 > > If the above isn't enough motivation and you really want benchmarks > which prove it's a pig... I'll try to figure something else > > Not exactly a 1:1 comparison because I think other things are mixed in, but... > 352K /usr/lib/gcc/x86_64-linux-gnu/4.9/libsupc++.a > 356K /usr/lib/gcc/x86_64-linux-gnu/5/libsupc++.a > > In the land of HPC we frequently statically link stuff... not that > 864KB is big by any sort of modern definition, but it does raise > questions.. > We aren't in love with any specific implementation of it so it is nice to have some comparison. We could probably start a page in the wiki about it. As said, the only part that makes uncomfortable about libcxxrt seems the lack of versions and releases. Surely we can cut another snapshot out of it and be happy about it. lu ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [gentoo-dev] New project: LLVM 2016-08-19 17:13 ` C Bergström 2016-08-19 17:34 ` Luca Barbato @ 2016-08-21 1:10 ` Lei Zhang 1 sibling, 0 replies; 20+ messages in thread From: Lei Zhang @ 2016-08-21 1:10 UTC (permalink / raw To: C Bergström; +Cc: Anthony G. Basile, llvm 2016-08-20 1:13 GMT+08:00 C Bergström <cbergstrom@pathscale.com>: > I finally got it to build and here's the size numbers > 952K ./lib/libc++abi.a > 616K ./lib/libc++abi.so.1.0 > > If the above isn't enough motivation and you really want benchmarks > which prove it's a pig... I'll try to figure something else > > Not exactly a 1:1 comparison because I think other things are mixed in, but... > 352K /usr/lib/gcc/x86_64-linux-gnu/4.9/libsupc++.a > 356K /usr/lib/gcc/x86_64-linux-gnu/5/libsupc++.a > > In the land of HPC we frequently statically link stuff... not that > 864KB is big by any sort of modern definition, but it does raise > questions.. Though larger code size might be detrimental to performance (more cache misses), seeing the runtime of a real world program is probably more convincing :) Speaking of HPC, could you recommend some HPC programs that I can benchmark against libcxxrt/libc++abi? Lei ^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2016-08-21 1:10 UTC | newest] Thread overview: 20+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2016-08-16 16:22 [gentoo-dev] New project: LLVM Michał Górny 2016-08-18 13:48 ` Ian Bloss 2016-08-18 13:56 ` C Bergström 2016-08-18 23:33 ` Lei Zhang 2016-08-19 2:07 ` cbergstrom 2016-08-19 2:40 ` Lei Zhang 2016-08-19 3:11 ` C Bergström 2016-08-19 15:01 ` Luca Barbato 2016-08-19 15:15 ` C Bergström 2016-08-19 17:38 ` Luca Barbato 2016-08-19 18:02 ` james 2016-08-19 18:20 ` C Bergström 2016-08-19 20:52 ` james 2016-08-19 21:05 ` C Bergström 2016-08-19 21:41 ` james 2016-08-20 5:45 ` C Bergström 2016-08-19 16:54 ` Lei Zhang 2016-08-19 17:13 ` C Bergström 2016-08-19 17:34 ` Luca Barbato 2016-08-21 1:10 ` Lei Zhang
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox