Re: GCC for SPARC Systems
When you're a company like Intel with a relatively small gap between gcc on x86 and icl, it's worth improving the gcc backend, but on Sparc the gap is much wider, so the effort to bridge it may not be justified from a resource point of view. Eh, SPARC is not IA-64 so improving the SPARC back-end should not be more resource-consuming than designing and maintaining a hybrid compiler. If I'm not mistaken, the gap is wide for FP code essentially but Sun doesn't seem to care much about FP anymore if I read the Niagara specs correctly. Personally I wouldn't mind working towards improving gcc sparc backend. Actually we are fixing gcc own bugs and contribute them back. To be clear, not bugs in the SPARC back-end. May I also suggest to find a different name for the product? Presumably it doesn't run on Linux or FreeBSD so GCC for SPARC Systems is a bit misleading, given that FSF GCC for SPARC does run on the aforementioned operating systems in addition to Solaris. Something like Sun GCC for SPARC/Solaris Systems although I'm not sure if using GCC is not already misleading. -- Eric Botcazou
Re: GCC for SPARC Systems
Alexey Starovoytov writes: If Sun starts improving GCC backend now it will never be able to catch up with Sun's own backend. This is a completely ridiculous assertion. Do you have any evidence to back this up? There is no reason that GCC could not intercept Sun CC if some effort were made. SPARC is not that different from other RISC architectures that GCC supports well. If Sun wants to protect its compiler business, that is fine, but it is a business decision, not a technical decision. When you're a company like Intel with a relatively small gap between gcc on x86 and icl, it's worth improving the gcc backend, but on Sparc the gap is much wider, so the effort to bridge it may not be justified from a resource point of view. Has anyone at Sun investigated and analyzed the source of the gap relative to a recent version of GCC? If Sun does not want to cooperate with the Free Software community, that may be a reasonable business decision, but at least provide the real explanation or do not say anything instead of excuses. David
Re: GCC for SPARC Systems
On Friday 03 March 2006 02:46, Alexey Starovoytov wrote: We are pleased to announce the availability of GCC for SPARC (R) Systems (GCCfss) at http://cooltools.sunsource.net/gcc/ Instead of pleased, I'd be ashamed for announcing this. To me it feels like you're announcing with pride how you ripped off gcc. Nota bene on a list that exists to discuss how to improve GCC, not how to take the bits you like and evade the implications of its license And to make things worse, you are explaining to users the reason why gcc4ss should exist using arguments that are simply not true. For example: Especially considering very conservative heuristics and that inlining happens after all tree-level optimization are completed. (quoted from your blog). Anyone who has looked at GCC closely, knows that this is nonsense. Inlining happens _before_ all (tree-level and other) optimizations. I have to assume you also looked at GCC close enough to notice. It is unfortunate, but I guess typical, that Sun has not learned from the mistakes made by others in the past, for example from how SGI tried and failed to pull off the same trick with Pro64. Gr. Steven
Re: GCC for SPARC Systems
On Fri, 10 Mar 2006, Eric Botcazou wrote: Eh, SPARC is not IA-64 so improving the SPARC back-end should not be more resource-consuming than designing and maintaining a hybrid compiler. If I'm gcc4ss wasn't a big effort. gimple form made it easy for us. not mistaken, the gap is wide for FP code essentially but Sun doesn't seem to care much about FP anymore if I read the Niagara specs correctly. You're right about Niagara's FP, but it's just one line of products. May I also suggest to find a different name for the product? Presumably it doesn't run on Linux or FreeBSD so GCC for SPARC Systems is a bit misleading, given that FSF GCC for SPARC does run on the aforementioned operating systems in addition to Solaris. Something like Sun GCC for SPARC/Solaris Systems although I'm not sure if using GCC is not already misleading. Glad you mentioned it. Really. I don't like that name either. Unfortunatelly that what we were told to use. May be we'll try to change it. Also your 'presumtion' is correct for the present only. Alexey. -- Eric Botcazou
Re: GCC for SPARC Systems
On Fri, 10 Mar 2006, David Edelsohn wrote: Alexey Starovoytov writes: If Sun starts improving GCC backend now it will never be able to catch up with Sun's own backend. This is a completely ridiculous assertion. Do you have any evidence to back this up? There is no reason that GCC could not intercept Sun CC if some effort were made. SPARC is not that different from other RISC architectures that GCC supports well. If Sun wants to protect its compiler business, that is fine, but it is a business decision, not a technical decision. So you're saying your team will be able to beat xlc. Ahh. Ok. Good for you. Personally I don't think that sparc gcc backend will be able to catch up with Sun's across the range of tests and benchmarks any time soon. Few major infrastructure features needs to be done first. I'm not here to defend Sun's compilers. The scope of gcc4ss is to deliver performance on SPARC chips. Period. If GCC can beat Sun there. Great! We wouldn't need to do any of this work. Has anyone at Sun investigated and analyzed the source of the gap relative to a recent version of GCC? If Sun does not want to cooperate with the Free Software community, that may be a reasonable business decision, but at least provide the real explanation or do not say anything instead of excuses. Yes. We know the reasons, but it doesn't sound that you want to hear them. You're just concerned about 'excuses'. Again I'm not representing any 'business' decisions. We just want SPARC chips to run faster and gcc4ss is just a tool to deliver that. Alexey.
Re: GCC for SPARC Systems
On Mar 10, 2006, at 3:34 PM, Alexey Starovoytov wrote: Few major infrastructure features needs to be done first. Like? Please give examples. If link time optimizations, that is already starting to be worked on. -- Pinski
Re: GCC for SPARC Systems
On Fri, 10 Mar 2006, Steven Bosscher wrote: On Friday 03 March 2006 02:46, Alexey Starovoytov wrote: We are pleased to announce the availability of GCC for SPARC (R) Systems (GCCfss) at http://cooltools.sunsource.net/gcc/ Instead of pleased, I'd be ashamed for announcing this. To me Being in hardware org I'm ashamed that SPARC cpus are not performing well with GCC, so I'm pleased that we can do something about it with gcc4ss. it feels like you're announcing with pride how you ripped off gcc. We are proud to make SPARC cpus faster. The users care about performance and reliability of their apps. I don't think it's matter to them how compiler is called or that it's rip off of something else. Inlining happens _before_ all (tree-level and other) optimizations. I have to assume you also looked at GCC close enough to notice. I apologize. Not sure what I was thinking when I wrote that. gcc does inline on tree-level. Fixed that. It is unfortunate, but I guess typical, that Sun has not learned from the mistakes made by others in the past, for example from how SGI tried and failed to pull off the same trick with Pro64. I wasn't making any legal/license decisions. I'm aware of open64, but here is way different imho. What do you think is wrong from GPL point of view? Alex. Gr. Steven
Re: GCC for SPARC Systems
On Fri, 10 Mar 2006, Andrew Pinski wrote: On Mar 10, 2006, at 3:34 PM, Alexey Starovoytov wrote: Few major infrastructure features needs to be done first. Like? Please give examples. If link time optimizations, that is already starting to be worked on. I doesn't look that my opinion here worth even 1 cent, but here are few things: - inter-proc (link time) opt I think LLVM is a better approach. - 2nd link time opt not re-optimization like above, but asm code optimizations. Looks like LLVM is targeting that as well. Check -xlinkopt flag and BIT - profile driven opt Great progress in 4.1. I'm very interested to see how you can match it with link time opts. - value profiling doesn't look anything is done - openmp I think it needs to be fully platform dependent, but anyway. Certainly would be interesting to compare with Sun's approach. - struct reorg opts very intersting item on gcc's todo list - loop opts Not sure what exactly is being done, but what I can see in 4.0 and 4.1 needs to be improved. Try -xloopinfo for verbosity. - prefetch It rather hurts performance when I tried it. Check -xprefetch* flags - struct type aliasing Great progress in 4.1, but still much behind Sun. Check -xalias_level flag - auto parallelization doesn't look anything is being done here. Check -xautopar - -ffast-math just compare it with Sun's -fsimple=2 - optimized inline assembler All of the above is done by sun compiler and gcc4ss (except openmp). A lot of other things are coming. Also I don't want to start tree vs orc flame, but it seems that Sun's IR is better suited for the above opts. Ok. Ok. It's not. Alex. -- Pinski
Re: GCC for SPARC Systems
On Mar 10, 2006, at 5:06 PM, Alexey Starovoytov wrote: - value profiling doesn't look anything is done Done and already in 3.4.0 and improved for the tree level in 4.1.0. - openmp I think it needs to be fully platform dependent, but anyway. Certainly would be interesting to compare with Sun's approach. Done on the mainline. -- Pinski
Re: GCC for SPARC Systems
On Mar 10, 2006, at 5:06 PM, Alexey Starovoytov wrote: - prefetch It rather hurts performance when I tried it. Check -xprefetch* flags There is a new tree level prefetching pass on the mainline, maybe you should try it again. -- Pinski
Re: GCC for SPARC Systems
On Fri, 2006-03-10 at 14:06 -0800, Alexey Starovoytov wrote: On Fri, 10 Mar 2006, Andrew Pinski wrote: On Mar 10, 2006, at 3:34 PM, Alexey Starovoytov wrote: Few major infrastructure features needs to be done first. Like? Please give examples. If link time optimizations, that is already starting to be worked on. I doesn't look that my opinion here worth even 1 cent, but here are few things: - inter-proc (link time) opt I think LLVM is a better approach. So is Sun moving to it? We are considering it (GCC being we) - 2nd link time opt not re-optimization like above, but asm code optimizations. Looks like LLVM is targeting that as well. Not as far as i know, actually. Check -xlinkopt flag and BIT - struct type aliasing Great progress in 4.1, but still much behind Sun. Check -xalias_level flag Actually, we aren't. I've looked at what Sun does, and the tree level does better in 4.2 than what you do in terms of struct aliasing. The RTL level doesn't. - auto parallelization doesn't look anything is being done here. Check -xautopar This isn't a useful optimization for more than 10% of users, which is why it's not done yet. All of the above is done by sun compiler and gcc4ss (except openmp). A lot of other things are coming. Also I don't want to start tree vs orc flame, but it seems that Sun's IR is better suited for the above opts. Ok. Ok. It's not. The reality is, you can either sit on the sidelines and pretend that GCC isn't going to each your lunch on every other platform in 5-10 years, or you can help make it work well on your platform. Sitting on the sidelines and saying Look, you don't have this, instead of implementing *that thing* is a bit silly.
Re: GCC for SPARC Systems
On Fri, 2006-03-10 at 12:34 -0800, Alexey Starovoytov wrote: On Fri, 10 Mar 2006, David Edelsohn wrote: Alexey Starovoytov writes: If Sun starts improving GCC backend now it will never be able to catch up with Sun's own backend. This is a completely ridiculous assertion. Do you have any evidence to back this up? There is no reason that GCC could not intercept Sun CC if some effort were made. SPARC is not that different from other RISC architectures that GCC supports well. If Sun wants to protect its compiler business, that is fine, but it is a business decision, not a technical decision. So you're saying your team will be able to beat xlc. Ahh. Ok. Good for you. Personally I don't think that sparc gcc backend will be able to catch up with Sun's across the range of tests and benchmarks any time soon. Few major infrastructure features needs to be done first. I'm not here to defend Sun's compilers. The scope of gcc4ss is to deliver performance on SPARC chips. Period. If GCC can beat Sun there. Great! We wouldn't need to do any of this work. You don't seem to get it. GCC isn't going to get better for *your platform* if you just sit on the sidelines. It will get better for those who work on it. This is why it is the way it performs the way it does for SPARC, not because of anything else. I would bet you Sun could intercept Sun CC using GCC within 5 years if they wanted to. HTH, Dan
Re: GCC for SPARC Systems
Alexey Starovoytov writes: Alexey I doesn't look that my opinion here worth even 1 cent, Alexey but here are few things: ... Alexey All of the above is done by sun compiler and gcc4ss (except openmp). Alexey A lot of other things are coming. None of the items you listed are SPARC-specific or absent from other proprietary compilers. You previously said: ... relatively small gap between gcc on x86 and icl [sic] ..., which means that the gap is in the SPARC-specific part of GCC that Sun is ignoring and not fundamental to GCC. If Sun and its partners do not care about GCC performance on SPARC, no one else will do it for them. No points for heckling from the sidelines. The users care about performance and reliability of their apps. I don't think it's matter to them how compiler is called or that it's rip off of something else. This is an oversimplified assertion. A small but lucrative portion of the market cares about the absolute best performance and specific HPC Features, while most of the market cares about good performance and portability. Any customer who wants a proprietary, lock-in compiler solution would chose Sun CC with GCC compatibility, with or without GCC for SPARC. If Sun want customers to have a better experience with GCC, it should help improve GCC. David
Re: GCC for SPARC Systems
I apologize in advance if this is a bit long or off-topic, but you might be interested to hear first-hand what some of current Sun customers have to say. On Fri, 10 Mar 2006, Alexey Starovoytov wrote: On Fri, 10 Mar 2006, Steven Bosscher wrote: On Friday 03 March 2006 02:46, Alexey Starovoytov wrote: We are pleased to announce the availability of GCC for SPARC (R) Systems (GCCfss) at http://cooltools.sunsource.net/gcc/ This kind of attitude shows, once more, how much your company still has to learn to reach to free software users and understand what they mean by 'community', 'free' and 'appealing'. (hint: 'free' is not free-beer and 'community' is not a group listening to a coordinator) Instead of pleased, I'd be ashamed for announcing this. Especially to this audience! Being in hardware org I'm ashamed that SPARC cpus are not performing well with GCC, so I'm pleased that we can do something about it with gcc4ss. slightly off-topic Well, these days one should be ashamed at SPARC performance, period. GCC is the least of SPARC's problems. Our lab is a large Genome center which used to be SPARC/Solaris-only, and remember when I joined two years ago and argued with our scientists about why I personally ditched SPARCs for cpu-intensive tasks around 1995 (ah, the late Alpha chip, sob!) and couldn't come close to performance of GNU/Linux on Pentiums since 1999. Showing people that for some of our high-performance bioinformatics applications, I would crush a $30,000 2-CPU V880 UltraSparc 1.2GHz with my $2,000 Dell PentiumIV laptop was, I would say, an eye opener. I am glad Sun has seen the light in terms of hardware and has been selling AMD Opterons (very nice ones by the way) for the last couple of years, which is the only way they could stay in the server/workstation business with us (we bought a lot of their Opteron boxes here, all models). They haven't got it yet for laptops apparently, given the recently announced Ultra-3 SPARC-based line (which my Acer Ferrari will eat for breakfast in energy-saving mode). As for niagara chips, I will consider it the day GNU/Linux and GCC run on it. I can tell you that what we call performance today in my field is called dual-core-Opterons, GNU/Linux and GCC. We let our SPARCs do legacy, file-serving and non-performance tasks, trying to get all our university students off them as well so that they don't get disgusted of Unix by exposure to Solaris, java desktop and X terminals (we give them KDE/GNU/Linux on Opteron workstations). We will publish various performance metrics when time permits in the coming months on Single/Dual core Sun Opterons with GCC-4.1.0 on Fedora Core 5 and GCC-3.4.4 on Fedora Core 3. /slightly off-topic it feels like you're announcing with pride how you ripped off gcc. We are proud to make SPARC cpus faster. The users care about performance and reliability of their apps. I don't think it's matter to them how compiler is called or that it's rip off of something else. You are wrong, and in my case by a long shot. First because, as an engineer I do not like inefficent processes consisting in making something slightly better if you are in a position to contribute to it and make it a lot better. Second because having worked 15 years in the field of genomics and bioinfromatics, I can tell you that the sequencing of genomes and molecular understanding of biology that was produced over the last two decades owes pretty much everything to the power of open raw data access and free software to handle it, for which GCC can claim to be a cornerstone. I have witnessed this in academia, biotechs and large pharma companies. We (creators and users of this information) have been _delayed_ by attitudes like yours. So you are not bringing performance, you are reaping short-term gains but preventing larger ones by not putting your energy where it would have the most impact. So please start contributing to GCC, and then we will consider looking at what you are doing. And thank you very much to all GCC developpers. Best regards, -- Philippe Rigault (GCC user since 1990). Bioinformatics Director, Centre de Génomique de Québec
Re: GCC for SPARC Systems
Alexey Starovoytov [EMAIL PROTECTED] writes: We are pleased to announce the availability of GCC for SPARC (R) Systems (GCCfss) at http://cooltools.sunsource.net/gcc/ GCCfss extends GCC to be able to use the optimizing Sun(tm) Code Generator for SPARC systems (SCGfss). A couple of questions: * Would it be possible to use the same technique for Solaris/x86 or Linux/x86, too? Both versions of Studio 11 provide libsunir.so as well. * Maybe it would be possible to perform further development on a vendor branch in the GCC svn repository? I'm not sure if this would require SC buy-in, though. Perhaps the changes might become acceptible for FSF GCC at some point in time; there have been discussions over at opensolaris.org about opening the sources to the Sun compilers. Thanks. Rainer -- - Rainer Orth, Faculty of Technology, Bielefeld University
Re: GCC for SPARC Systems
On Thu, 9 Mar 2006, Rainer Orth wrote: Alexey Starovoytov [EMAIL PROTECTED] writes: We are pleased to announce the availability of GCC for SPARC (R) Systems (GCCfss) at http://cooltools.sunsource.net/gcc/ GCCfss extends GCC to be able to use the optimizing Sun(tm) Code Generator for SPARC systems (SCGfss). A couple of questions: * Would it be possible to use the same technique for Solaris/x86 or Linux/x86, too? Both versions of Studio 11 provide libsunir.so as well. It is certainly possible, but considered as not desirable. As an engineer I can say that it wouldn't be too difficult to do the x86, but I don't think it will happen any time soon. * Maybe it would be possible to perform further development on a vendor branch in the GCC svn repository? I'm not sure if this would require SC buy-in, though. Perhaps the changes might become acceptible for FSF GCC at some point in time; there have been discussions over at opensolaris.org about opening the sources to the Sun compilers. Personally I'd like to arrange it as a gcc branch or contribute it in some way, but my previous effort of much smaller scale (gcc2c) had quite negative reception, so I don't expect any sort of approval. Also I'd like to emphasize that GCC for SPARC Systems is trying to deliver performance on SPARC cpus to those users who use plain GCC compiler there. That's it. I tried to explain my personal opinion of gcc4ss vs gcc on sparc on my blog: http://blogs.sun.com/roller/page/alexey Please don't hesitate to ask questions. I'll be glad to share the details of implementation and hope that few things may be useful to GCC developers as well. Thank you. Alexey. Thanks. Rainer -- - Rainer Orth, Faculty of Technology, Bielefeld University
Re: GCC for SPARC Systems
* Maybe it would be possible to perform further development on a vendor branch in the GCC svn repository? I'm not sure if this would require SC buy-in, though. Perhaps the changes might become acceptible for FSF GCC at some point in time; there have been discussions over at opensolaris.org about opening the sources to the Sun compilers. Personally I'd like to arrange it as a gcc branch or contribute it in some way, but my previous effort of much smaller scale (gcc2c) had quite negative reception, so I don't expect any sort of approval. Honestly, i doubt you would ever get it. At a bare minimum, i'd expect nobody would even consider it until the sources to Sun's compilers were GPL'd or put under a GPL compatible license[1]. Also I'd like to emphasize that GCC for SPARC Systems is trying to deliver performance on SPARC cpus to those users who use plain GCC compiler there. Right. and instead of taking the route that other companies like IBM, and recently, Intel and HP, have taken, which is to work *with* the GCC community, and improve GCC, Sun apparently has decided to just work around it. It is one thing to say that short term, you need to do something else (like hook up GCC to ORC or something) because GCC won't improve fast enough. But as far as i can tell Sun has absolutely no long term goal to actually attempt to improve GCC so they don't need to do these kinds of things. [1] For the curious, what they are doing is simply taking our IR, and converting it to their IR, and writing it to a file, and then passing the file off to something else. Much like Open64 did.
GCC for SPARC Systems
We are pleased to announce the availability of GCC for SPARC (R) Systems (GCCfss) at http://cooltools.sunsource.net/gcc/ GCCfss extends GCC to be able to use the optimizing Sun(tm) Code Generator for SPARC systems (SCGfss). We encourage you to download it and try it. The compiler commands are the same as GCC: gcc and g++. All of the GCC command-line options are there and MORE! Crank up the optimization level (-O3 and -fast). Use interprocedural optimizations (-xipo). Use profile driven optimization (-xprofile). And this is just the initial version! More optimizations will follow shortly. Programs compiled with GCCfss follow the same ABI as programs compiled by GCC. You can mix and match GCCfss and GCC compiled objects. We would be pleased to answer your questions and hear your feedback in our cooltools forum: http://forum.sun.com/forum.jspa?forumID=283 The companion SCGfss software is also available for free download (and must be installed to obtain the full benefit of GCCfss.) Besides the SPARC code generator itself, SCGfss includes other cool tools that have also been recently made available for Sun Studio 11: - Automatic Tuning and Troubleshooting System (ATS) http://cooltools.sunsource.net/ats/ ATS is a binary reoptimization and recompilation tool that can be used for tuning and troubleshooting applications. ATS works by rebuilding the compiled PEC (Portable Executable Code) binary - the original source code is not required. Examples of what can be achieved using ATS are: * Find the compiler options that give the best performance * Find the object file and the optimization flag that is causing a runtime problem * Rebuild the application using new compiler options - Binary Instrumentation Tool (BIT) http://cooltools.sunsource.net/bit/ BIT - Binary Improvement Tool, is a tool containing various resources for working with SPARC binaries. It can instrument and analyze binaries, providing exact count runtime information for purposes of performance or coverage analysis. It can also optimize binaries to improve runtime performance, particularly with respect to instruction cache usage. BIT can work on binaries which have been compiled with the Sun Studio 11 compiler or with GCCfss using the -xbinopt=prepare option. Regards, GCC for SPARC Systems team.
