Current loongson2f linux version / compiler / version flags wisdom?

222 views
Skip to first unread message

Daniel Clark

unread,
Jul 2, 2010, 12:17:34 PM7/2/10
to loongs...@googlegroups.com, Lluís Batlle i Rossell, zhoush...@ict.ac.cn, liuyi...@ict.ac.cn, f...@ict.ac.cn, yi...@ict.ac.cn, leih...@ict.ac.cn, lis...@ict.ac.cn, mach...@ict.ac.cn, gaoz...@ict.ac.cn, lian...@ict.ac.cn, Mart Raudsepp
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?

[1] NixOS
http://nixos.org/nixos/

[2] Loongson comments and questions from a HPC friend
http://groups.google.com/group/loongson-dev/browse_thread/thread/c1b94dd15882d1dc

[3] Open64 Research Compiler
http://www.open64.net/

Thanks,
--
       \|/      Daniel JB Clark | Activist; Owner
FREEDOM -+-> INCLUDED ~ http://freedomincluded.com
       /|\      Free Software respecting hardware

zhangfx

unread,
Jul 2, 2010, 9:01:53 PM7/2/10
to loongs...@googlegroups.com
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.

Regards

zhangfx

unread,
Jul 2, 2010, 9:26:23 PM7/2/10
to loongs...@googlegroups.com
LoongCC people confirmed that the version in open64 is usable but might not be the best/newest version.


Regards

On 2010年07月03日 00:17, Daniel Clark wrote:

Wu Zhangjin

unread,
Jul 3, 2010, 12:06:17 AM7/3/10
to loongs...@googlegroups.com, Lluís Batlle i Rossell, zhoush...@ict.ac.cn, liuyi...@ict.ac.cn, f...@ict.ac.cn, yi...@ict.ac.cn, leih...@ict.ac.cn, lis...@ict.ac.cn, mach...@ict.ac.cn, gaoz...@ict.ac.cn, lian...@ict.ac.cn, Mart Raudsepp
Hi,

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

bao.me...@gmail.com

unread,
Jul 3, 2010, 5:42:28 AM7/3/10
to loongs...@googlegroups.com, Lluís Batlle i Rossell, zhoush...@ict.ac.cn, liuyi...@ict.ac.cn, f...@ict.ac.cn, yi...@ict.ac.cn, leih...@ict.ac.cn, lis...@ict.ac.cn, mach...@ict.ac.cn, gaoz...@ict.ac.cn, lian...@ict.ac.cn, Mart Raudsepp
Comments on GCC optimization below..

On 12:06 03 Jul 10, Wu Zhangjin wrote:
> Hi,
>
> 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."

and

"Using -O3 is not recommended for gcc 4.x."

[source: http://www.gentoo.org/doc/en/gcc-optimization.xml]

> --
> You received this message because you are subscribed to the Google Groups "loongson-dev" group.
> To post to this group, send email to loongs...@googlegroups.com.
> To unsubscribe from this group, send email to loongson-dev...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/loongson-dev?hl=en.
>

Daniel Clark

unread,
Jul 3, 2010, 11:26:12 PM7/3/10
to loongs...@googlegroups.com
On Fri, Jul 2, 2010 at 9:26 PM, zhangfx <zha...@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 Clark

unread,
Jul 8, 2010, 12:02:37 AM7/8/10
to Lluís Batlle i Rossell, loongs...@googlegroups.com, zhoush...@ict.ac.cn, liuyi...@ict.ac.cn, f...@ict.ac.cn, yi...@ict.ac.cn, leih...@ict.ac.cn, lis...@ict.ac.cn, mach...@ict.ac.cn, gaoz...@ict.ac.cn, lian...@ict.ac.cn, Mart Raudsepp, Brett C Smith, Kelly Hopkins, Narayan Desai, Peter Olson
On Wed, Jul 7, 2010 at 4:28 PM, Lluís Batlle i Rossell
<viri...@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.
>
> Thank you for the copy.

>
>> [2] Loongson comments and questions from a HPC friend
>> http://groups.google.com/group/loongson-dev/browse_thread/thread/c1b94dd15882d1dc
>>
>> [3] Open64 Research Compiler
>> http://www.open64.net/
>
>
> 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.
>
> [1] http://www.path64.org/

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.

Zhang Le

unread,
Jul 15, 2010, 10:44:21 PM7/15/10
to loongs...@googlegroups.com, Lluís Batlle i Rossell, zhoush...@ict.ac.cn, liuyi...@ict.ac.cn, f...@ict.ac.cn, yi...@ict.ac.cn, leih...@ict.ac.cn, lis...@ict.ac.cn, mach...@ict.ac.cn, gaoz...@ict.ac.cn, lian...@ict.ac.cn, Mart Raudsepp

Things apply to x86, may not apply to MIPS, especially Loongson, :)

IIRC, -O3 performs better than -O2 in benchmarks on Loongson.

--
Zhang, Le
Gentoo/Loongson Developer
http://zhangle.is-a-geek.org
0260 C902 B8F8 6506 6586 2B90 BC51 C808 1E4E 2973

包孟謙

unread,
Jul 16, 2010, 7:41:03 AM7/16/10
to loongs...@googlegroups.com, Lluís Batlle i Rossell, zhoush...@ict.ac.cn, liuyi...@ict.ac.cn, f...@ict.ac.cn, yi...@ict.ac.cn, leih...@ict.ac.cn, lis...@ict.ac.cn, mach...@ict.ac.cn, gaoz...@ict.ac.cn, lian...@ict.ac.cn, Mart Raudsepp
as long as you found this through experimenting, it is good to hear!
 
thank you

ToobMug

unread,
Jul 16, 2010, 5:12:16 AM7/16/10
to loongson-dev
On Jul 16, 3:44 am, Zhang Le <r0be...@gentoo.org> wrote:
> On 11:42 Sat 03 Jul     , bao.mengq...@gmail.com wrote:
> > Actually Gentoo recommends:
> > [...]
> > "Using -O3 is not recommended for gcc 4.x."
> >
> > [source:http://www.gentoo.org/doc/en/gcc-optimization.xml]
>
> 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.
Reply all
Reply to author
Forward
0 new messages