I've interested Lluís in doing an experimental NixOS [1] port for loongson2f (initial target Lemote Fuloong) sometime in the next several months; Lluís should have a gratis Fuloong from Freedom Included, Inc. late next week. Also Mart is helping to mainstream Gentoo Loongson2f support, so cc:ing him as well.
Am I correct in thinking that all loongson2f-specific patches are now in linux 2.6.34 mainstream, and that is the version it would make sense to base a current GNU/Linux distribution for loongson2f on?
Could someone speak to the current recommended gcc and binutils versions and flags to do fully optimized for loongson2f compiles?
Are loongson2f-specific patches still needed for these versions of gcc and binutils?
Recently it was mentioned [2] that there was a loongson-specific branch of Open64 [3] called "Loongcc" that claims "28.5%/78.4% performance improvement in SPEC2000INT/FP over latest GCC on Loongson 2F" (but this was in 2009).
Does anyone know if Loongcc is still significantly faster than latest mainstream gcc?
Based on the open64 web page, Open64 is GPLv2 - same for Loongcc? The paper mentions that parts of pathscale compiler are used, so if it is the case that it is GPLv2 but pathscale is used I'm a bit confused.
Do people feel Loongcc is at a point where it would make sense to use it for an entire GNU/Linux distribution?
If so, where can Loongcc be obtained? Just compile from head of "/branches/loongson" in Open64 SVN?
About LoongCC, it is developed by a research group in Insititute of Computing Technology(ICT), the same insititute with the one loongson from. As far as I can tell, it does run much faster than gcc, at least on some benchmarks like SPEC CPU2000 etc. But it is not yet ready for building a full distribution due to the lack of carefully production level work. I am not sure how to obtain it for now, will ask the related guys.
> I've interested Lluís in doing an experimental NixOS [1] port for > loongson2f (initial target Lemote Fuloong) sometime in the next > several months; Lluís should have a gratis Fuloong from Freedom > Included, Inc. late next week. Also Mart is helping to mainstream > Gentoo Loongson2f support, so cc:ing him as well.
> Am I correct in thinking that all loongson2f-specific patches are now > in linux 2.6.34 mainstream, and that is the version it would make > sense to base a current GNU/Linux distribution for loongson2f on?
> Could someone speak to the current recommended gcc and binutils > versions and flags to do fully optimized for loongson2f compiles?
> Are loongson2f-specific patches still needed for these versions of gcc > and binutils?
> Recently it was mentioned [2] that there was a loongson-specific > branch of Open64 [3] called "Loongcc" that claims "28.5%/78.4% > performance improvement in SPEC2000INT/FP over latest GCC on Loongson > 2F" (but this was in 2009).
> Does anyone know if Loongcc is still significantly faster than latest > mainstream gcc?
> Based on the open64 web page, Open64 is GPLv2 - same for Loongcc? The > paper mentions that parts of pathscale compiler are used, so if it is > the case that it is GPLv2 but pathscale is used I'm a bit confused.
> Do people feel Loongcc is at a point where it would make sense to use > it for an entire GNU/Linux distribution?
> If so, where can Loongcc be obtained? Just compile from head of > "/branches/loongson" in Open64 SVN?
> I've interested Lluís in doing an experimental NixOS [1] port for > loongson2f (initial target Lemote Fuloong) sometime in the next > several months; Lluís should have a gratis Fuloong from Freedom > Included, Inc. late next week. Also Mart is helping to mainstream > Gentoo Loongson2f support, so cc:ing him as well.
> Am I correct in thinking that all loongson2f-specific patches are now > in linux 2.6.34 mainstream, and that is the version it would make > sense to base a current GNU/Linux distribution for loongson2f on?
> Could someone speak to the current recommended gcc and binutils > versions and flags to do fully optimized for loongson2f compiles?
> Are loongson2f-specific patches still needed for these versions of gcc > and binutils?
> Recently it was mentioned [2] that there was a loongson-specific > branch of Open64 [3] called "Loongcc" that claims "28.5%/78.4% > performance improvement in SPEC2000INT/FP over latest GCC on Loongson > 2F" (but this was in 2009).
> Does anyone know if Loongcc is still significantly faster than latest > mainstream gcc?
> Based on the open64 web page, Open64 is GPLv2 - same for Loongcc? The > paper mentions that parts of pathscale compiler are used, so if it is > the case that it is GPLv2 but pathscale is used I'm a bit confused.
> Do people feel Loongcc is at a point where it would make sense to use > it for an entire GNU/Linux distribution?
> If so, where can Loongcc be obtained? Just compile from head of > "/branches/loongson" in Open64 SVN?
On Fri, 2010-07-02 at 12:17 -0400, Daniel Clark wrote:
[...]
> Am I correct in thinking that all loongson2f-specific patches are now > in linux 2.6.34 mainstream, and that is the version it would make > sense to base a current GNU/Linux distribution for loongson2f on?
Basically, 2.6.34 is enough, but some YeeLoong, LynLoong specific patches are not upstreamed, including the platform specific drivers and the rtl8187b wireless driver.
And also, perhaps some latest bug-fixes are not in the mainline 2.6.34.
So, The one maintained in [1] is recommended.
> Could someone speak to the current recommended gcc and binutils > versions and flags to do fully optimized for loongson2f compiles?
Perhaps gcc 4.5 is the best choice, here are some potential options for optimization:
The following one may be supported by gcc >= 4.4, but some applications may not work under -mabi=n32(Seems Zhang Le have maintained the supported ones here[2], and also, the applications there should be the ones optimized for loongson2f with loongson specific instructions!).
-O3 -march=loongson2f -mabi=n32
The gcc 4.5 specific optimization options may be found at [3].
For binutils, the one in its mainline cvs repo should be the choice for I'm sure the loongson specific patches have been there. If you need the stable release, please get the one have the -mfix-loongson2f-nop and -mfix-loongson2f-jump options. As I explained before, these two options are needed to compile the kernel(will be applied if the binutils support them), but only -mfix-loongson2f-nop is needed to compile the user-space applications[4].
> Are loongson2f-specific patches still needed for these versions of gcc > and binutils?
As I know, no, but perhaps some patches are maintained internally in ICT ;)
Best Regards, Wu Zhangjin ---------------------------------
[1] http://dev.lemote.com/code/linux-loongson-community [2] http://www.gentoo-cn.org/gitweb/?p=loongson.git;a=summary [3] http://lwn.net/Articles/387122/ [4] In the future loongson2f / 03, these two options will be not needed, but for the compatibility of the old loongson2f / 01|02, we'd better use them all the time for they have no big negative impact on loongson2f / 03 except some potential performance declining. In the future, If the kernel patch[5] for fixing the user-space NOP issue become matured, I will apply it to avoid using -mfix-loongson2f-nop in user-space.
If you really don't want to compile the kernel with the -mfix... for loongson2f / 03, you can disable the kernel config option: CPU_LOONGSON2F_WORKAROUNDS. [5] loongson-dev google group: Dynamic fix loongson2f nop in kernel
> On Fri, 2010-07-02 at 12:17 -0400, Daniel Clark wrote: > [...]
> > Am I correct in thinking that all loongson2f-specific patches are now > > in linux 2.6.34 mainstream, and that is the version it would make > > sense to base a current GNU/Linux distribution for loongson2f on?
> Basically, 2.6.34 is enough, but some YeeLoong, LynLoong specific > patches are not upstreamed, including the platform specific drivers and > the rtl8187b wireless driver.
> And also, perhaps some latest bug-fixes are not in the mainline 2.6.34.
> So, The one maintained in [1] is recommended.
> > Could someone speak to the current recommended gcc and binutils > > versions and flags to do fully optimized for loongson2f compiles?
> Perhaps gcc 4.5 is the best choice, here are some potential options for > optimization:
> The following one may be supported by gcc >= 4.4, but some applications > may not work under -mabi=n32(Seems Zhang Le have maintained the > supported ones here[2], and also, the applications there should be the > ones optimized for loongson2f with loongson specific instructions!).
> -O3 -march=loongson2f -mabi=n32
> The gcc 4.5 specific optimization options may be found at [3].
Actually Gentoo recommends:
"-O3: This is the highest level of optimization possible, and also the riskiest. It will take a longer time to compile your code with this option, and in fact it should not be used system-wide with gcc 4.x."
> For binutils, the one in its mainline cvs repo should be the choice for > I'm sure the loongson specific patches have been there. If you need the > stable release, please get the one have the -mfix-loongson2f-nop and > -mfix-loongson2f-jump options. As I explained before, these two options > are needed to compile the kernel(will be applied if the binutils support > them), but only -mfix-loongson2f-nop is needed to compile the user-space > applications[4].
> > Are loongson2f-specific patches still needed for these versions of gcc > > and binutils?
> As I know, no, but perhaps some patches are maintained internally in > ICT ;)
> Best Regards, > Wu Zhangjin > ---------------------------------
> [1] http://dev.lemote.com/code/linux-loongson-community > [2] http://www.gentoo-cn.org/gitweb/?p=loongson.git;a=summary > [3] http://lwn.net/Articles/387122/ > [4] In the future loongson2f / 03, these two options will be not needed, > but for the compatibility of the old loongson2f / 01|02, we'd better use > them all the time for they have no big negative impact on loongson2f / > 03 except some potential performance declining. In the future, If the > kernel patch[5] for fixing the user-space NOP issue become matured, I > will apply it to avoid using -mfix-loongson2f-nop in user-space.
> If you really don't want to compile the kernel with the -mfix... for > loongson2f / 03, you can disable the kernel config option: > CPU_LOONGSON2F_WORKAROUNDS. > [5] loongson-dev google group: Dynamic fix loongson2f nop in kernel
> -- > You received this message because you are subscribed to the Google Groups "loongson-dev" group. > To post to this group, send email to loongson-dev@googlegroups.com. > To unsubscribe from this group, send email to loongson-dev+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/loongson-dev?hl=en.
On Fri, Jul 2, 2010 at 9:26 PM, zhangfx <zhan...@lemote.com> wrote: > LoongCC people confirmed that the version in open64 is usable but might not > be the best/newest version.
Is there a better/newer version available in another public location?
-- \|/ Daniel JB Clark | Activist; Owner FREEDOM -+-> INCLUDED ~ http://freedomincluded.com /|\ Free Software respecting hardware
<virik...@gmail.com> wrote: > On Fri, Jul 02, 2010 at 12:17:34PM -0400, Daniel Clark wrote: >> I've interested Lluís in doing an experimental NixOS [1] port for >> loongson2f (initial target Lemote Fuloong) sometime in the next >> several months; Lluís should have a gratis Fuloong from Freedom >> Included, Inc. late next week. Also Mart is helping to mainstream >> Gentoo Loongson2f support, so cc:ing him as well.
> Regarding [your 2], I've been trying the path64 [1] compiler on nix > x86_64-linux. Isn't that the pathscale compiler made free? They have a nice > cmake build definition, and builds much easier than open64. At > irc.freenode.net#pathscale they work on that path64 compiler, and they looked > very active to me. I don't know how much they work on mipsel, though; I've seen > them busy on amd64, arm, and nvidia targets (HMPP related).
> I just knew about path64 from your letter. Maybe you know better about this.
I'm not sure what exactly the licensing situation is with LoongCC (the open64 branch for loongson).
Off-list I submitted it to FSF for license evaluation and cc:ed someone from Lemote; the person from Lemote said that they still need to work out some stuff regarding licensing / making the newest versions available, so as far as I know FSF isn't looking into it until we hear back from Lemote.
I hadn't seen / found http://www.path64.org before. It does look like at least parts of pathscale made free software, which is great. But I don't know if it has loongson2f support - perhaps people from ICT can comment on that.
-- \|/ Daniel JB Clark | Activist; Owner FREEDOM -+-> INCLUDED ~ http://freedomincluded.com /|\ Free Software respecting hardware
> > On Fri, 2010-07-02 at 12:17 -0400, Daniel Clark wrote: > > [...]
> > > Am I correct in thinking that all loongson2f-specific patches are now > > > in linux 2.6.34 mainstream, and that is the version it would make > > > sense to base a current GNU/Linux distribution for loongson2f on?
> > Basically, 2.6.34 is enough, but some YeeLoong, LynLoong specific > > patches are not upstreamed, including the platform specific drivers and > > the rtl8187b wireless driver.
> > And also, perhaps some latest bug-fixes are not in the mainline 2.6.34.
> > So, The one maintained in [1] is recommended.
> > > Could someone speak to the current recommended gcc and binutils > > > versions and flags to do fully optimized for loongson2f compiles?
> > Perhaps gcc 4.5 is the best choice, here are some potential options for > > optimization:
> > The following one may be supported by gcc >= 4.4, but some applications > > may not work under -mabi=n32(Seems Zhang Le have maintained the > > supported ones here[2], and also, the applications there should be the > > ones optimized for loongson2f with loongson specific instructions!).
> > -O3 -march=loongson2f -mabi=n32
> > The gcc 4.5 specific optimization options may be found at [3].
> Actually Gentoo recommends:
> "-O3: This is the highest level of optimization possible, and also the > riskiest. It will take a longer time to compile your code with this > option, and in fact it should not be used system-wide with gcc 4.x."
> > For binutils, the one in its mainline cvs repo should be the choice for > > I'm sure the loongson specific patches have been there. If you need the > > stable release, please get the one have the -mfix-loongson2f-nop and > > -mfix-loongson2f-jump options. As I explained before, these two options > > are needed to compile the kernel(will be applied if the binutils support > > them), but only -mfix-loongson2f-nop is needed to compile the user-space > > applications[4].
> > > Are loongson2f-specific patches still needed for these versions of gcc > > > and binutils?
> > As I know, no, but perhaps some patches are maintained internally in > > ICT ;)
> > [1] http://dev.lemote.com/code/linux-loongson-community > > [2] http://www.gentoo-cn.org/gitweb/?p=loongson.git;a=summary > > [3] http://lwn.net/Articles/387122/ > > [4] In the future loongson2f / 03, these two options will be not needed, > > but for the compatibility of the old loongson2f / 01|02, we'd better use > > them all the time for they have no big negative impact on loongson2f / > > 03 except some potential performance declining. In the future, If the > > kernel patch[5] for fixing the user-space NOP issue become matured, I > > will apply it to avoid using -mfix-loongson2f-nop in user-space.
> > If you really don't want to compile the kernel with the -mfix... for > > loongson2f / 03, you can disable the kernel config option: > > CPU_LOONGSON2F_WORKAROUNDS. > > [5] loongson-dev google group: Dynamic fix loongson2f nop in kernel
> > -- > > You received this message because you are subscribed to the Google Groups "loongson-dev" group. > > To post to this group, send email to loongson-dev@googlegroups.com. > > To unsubscribe from this group, send email to loongson-dev+unsubscribe@googlegroups.com. > > For more options, visit this group at http://groups.google.com/group/loongson-dev?hl=en.
> -- > You received this message because you are subscribed to the Google Groups "loongson-dev" group. > To post to this group, send email to loongson-dev@googlegroups.com. > To unsubscribe from this group, send email to loongson-dev+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/loongson-dev?hl=en.
On Fri, Jul 16, 2010 at 4:44 AM, Zhang Le <r0be...@gentoo.org> wrote: > On 11:42 Sat 03 Jul , bao.mengq...@gmail.com wrote: > > Comments on GCC optimization below..
> > > On Fri, 2010-07-02 at 12:17 -0400, Daniel Clark wrote: > > > [...]
> > > > Am I correct in thinking that all loongson2f-specific patches are now > > > > in linux 2.6.34 mainstream, and that is the version it would make > > > > sense to base a current GNU/Linux distribution for loongson2f on?
> > > Basically, 2.6.34 is enough, but some YeeLoong, LynLoong specific > > > patches are not upstreamed, including the platform specific drivers and > > > the rtl8187b wireless driver.
> > > And also, perhaps some latest bug-fixes are not in the mainline 2.6.34.
> > > So, The one maintained in [1] is recommended.
> > > > Could someone speak to the current recommended gcc and binutils > > > > versions and flags to do fully optimized for loongson2f compiles?
> > > Perhaps gcc 4.5 is the best choice, here are some potential options for > > > optimization:
> > > The following one may be supported by gcc >= 4.4, but some applications > > > may not work under -mabi=n32(Seems Zhang Le have maintained the > > > supported ones here[2], and also, the applications there should be the > > > ones optimized for loongson2f with loongson specific instructions!).
> > > -O3 -march=loongson2f -mabi=n32
> > > The gcc 4.5 specific optimization options may be found at [3].
> > Actually Gentoo recommends:
> > "-O3: This is the highest level of optimization possible, and also the > > riskiest. It will take a longer time to compile your code with this > > option, and in fact it should not be used system-wide with gcc 4.x."
> Things apply to x86, may not apply to MIPS, especially Loongson, :)
> IIRC, -O3 performs better than -O2 in benchmarks on Loongson.
> > > For binutils, the one in its mainline cvs repo should be the choice for > > > I'm sure the loongson specific patches have been there. If you need the > > > stable release, please get the one have the -mfix-loongson2f-nop and > > > -mfix-loongson2f-jump options. As I explained before, these two options > > > are needed to compile the kernel(will be applied if the binutils > support > > > them), but only -mfix-loongson2f-nop is needed to compile the > user-space > > > applications[4].
> > > > Are loongson2f-specific patches still needed for these versions of > gcc > > > > and binutils?
> > > As I know, no, but perhaps some patches are maintained internally in > > > ICT ;)
> > > [1] http://dev.lemote.com/code/linux-loongson-community > > > [2] http://www.gentoo-cn.org/gitweb/?p=loongson.git;a=summary > > > [3] http://lwn.net/Articles/387122/ > > > [4] In the future loongson2f / 03, these two options will be not > needed, > > > but for the compatibility of the old loongson2f / 01|02, we'd better > use > > > them all the time for they have no big negative impact on loongson2f / > > > 03 except some potential performance declining. In the future, If the > > > kernel patch[5] for fixing the user-space NOP issue become matured, I > > > will apply it to avoid using -mfix-loongson2f-nop in user-space.
> > > If you really don't want to compile the kernel with the -mfix... for > > > loongson2f / 03, you can disable the kernel config option: > > > CPU_LOONGSON2F_WORKAROUNDS. > > > [5] loongson-dev google group: Dynamic fix loongson2f nop in kernel
> > > -- > > > You received this message because you are subscribed to the Google > Groups "loongson-dev" group. > > > To post to this group, send email to loongson-dev@googlegroups.com. > > > To unsubscribe from this group, send email to > loongson-dev+unsubscribe@googlegroups.com<loongson-dev%2Bunsubscribe@google groups.com> > . > > > For more options, visit this group at > http://groups.google.com/group/loongson-dev?hl=en.
> > -- > > You received this message because you are subscribed to the Google Groups > "loongson-dev" group. > > To post to this group, send email to loongson-dev@googlegroups.com. > > To unsubscribe from this group, send email to > loongson-dev+unsubscribe@googlegroups.com<loongson-dev%2Bunsubscribe@google groups.com> > . > > For more options, visit this group at > http://groups.google.com/group/loongson-dev?hl=en.
> Things apply to x86, may not apply to MIPS, especially Loongson, :)
> IIRC, -O3 performs better than -O2 in benchmarks on Loongson.
To elaborate on this; x86 is CISC, and descended from an architecture
that was designed to fit big programs into small ROMs. Historically
it could implement a whole string copy in half the space it takes MIPS
to issue a single instruction. With a RISC processor, though, you
don't have so much opportunity to make programs more compact. I
expect that most of the questionable optimisations that can be
performed on MIPS code are going to be loop unrolling and function
inlining. Although in some cases function inlining will also make
code smaller by means of constant propagation and the removal of
register marshalling and function prologue and epilogue costs.
Conventional wisdom has been to optimise all of your support libraries
and non-essential routines for size so as to keep more room in your i-
cache available for critical routines. If you expand your code too
far with space-wasting speed optimisations then you'll exhaust your i-
cache and end up running essentially as if you had none at all (or
even slightly worse). Benchmarks can fail to take this into account
if the tests that they perform are too simple compared to real
programs.
If you're going to unroll a loop you want to know that you're going to
get something good for it, like better use of the register file. Not
just the elimination of every second branch instruction. I don't know
if gcc will ever revert an unroll if it realises that it's not gaining
anything.
And with a program that does a trivial job, if you over-inflate it
with unrolled loops then you may lose more time loading it than you
save during its execution; and this penalty recurs when you have to
swap it out of main memory. These costs are normally trivial, but you
have to wonder why you would spend extra time compiling code with high
optimisation settings just to make it marginally slower and more
wasteful.
