Plans for gcc 4.0.0?

Duke · 2005-04-22 04:21:36

Just wondering what Archlinux plans are for gcc 4.0.0, now that it's released. It seems rather interesting the new features for optimizing, which seems to be right up arch's alley. An i686-optimized linux distribution, after all, would benefit from better optimizations.

I'm just hoping that not too much is broken with this new release (everyone remembers gcc 2.95 -> 3), but since this release came much faster and isn't an almost complete rewrite like egcs was, hopefully we can expect a smoother transition.

I for one am excited about this new gcc release, much more than a new kde, gnome or x.org or whatever... Maybe it's just me that likes compilers so much and hates bytecode. But still, what is Arch's stance on this? Any plans to move forward? Maybe provide a gcc 4 package but keep compiling arch packages with 3.x until bugs get ironed out? Or be truly bleeding edge (it is stable software afterall though) and take the plunge and compile arch packages with this new fancy gcc?

Autovectorization seems rather interesting ( http://gcc.gnu.org/projects/tree-ssa/vectorization.html there's the link for anyone interested), yet needs -msse or -msse2 flags to be set. Is this feasible? Would this binary nicely optimized for processors with sse or sse2 run that much worse on hardware without such instructions?

What is arch's stance on instructions like sse or 3dnow? Are packages compiled with such optimizations? If so why or if not why not? I personally think that most arch users use relatively recent hardware and would benefit... But then again, I'm just wondering aloud.

Anyways, sorry for all the questions...

phrakture · 2005-04-22 04:36:52

Duke wrote:

What is arch's stance on instructions like sse or 3dnow? Are packages compiled with such optimizations? If so why or if not why not? I personally think that most arch users use relatively recent hardware and would benefit... But then again, I'm just wondering aloud.

This has been discussed alot - my stance (not Arch's) is that Arch is i686 based - that's the common factor... if you start creeping with that, when will it stop? first we require SSE, then MMX, then SSE2... we may end up switching from "an i686 optimized distro" to "a distro optimized to run on AMD processors produced after November 12th 2004".

In addition, SSE instructions only make sense in advanced math applications, FFT programs, and multimedia stuff... it's a small subset of the applications... think about it: how could something like vim benefit from loop vectorization? it really can't... sure you may get some things improved... but it's vim, you don't need to do 50 calculations in the time it takes to do 1 - it's not processor intensive.

And let's look at the apps that do make use of SSE: multimedia - improve the performance of mpegs and mp3s? who watches that much porn?
:shock: :shock:
FFT programs - anyone seriously doing complex FFT/DSP calcs on Arch? I doubt it
Advanced Math - sure might make sense, but it doesn't warrant a recompile and optimization of the entire set of packages.

So, in my opinion, enabling SSE/SSE2/MMX/MMX2/whatever else you get:
- loss of some processor support
+ improvement in MP3 playback
+ faster calculation of PI
- a bunch of apps you had to redownload with negligable performance gain

shadowhand · 2005-04-22 04:46:05

Isn's SSE standard in i686 + processors? Or only in Pentium/Athlon/Duron/Celeron and above? I've never owned a computer that wasn't a least a Pentium something, so bear with me.

If it's not standard to i686, then it shouldn't be added.

phrakture · 2005-04-22 04:55:00

Pentium
Pentium MMX -- MMX
Pentium II -- MMX
Celeron -- MMX
Pentium III -- MMX , EMMX , SSE
Celeron II -- MMX , EMMX , SSE
Pentium 4 -- MMX , EMMX , SSE , SSE2
AMD K6 -- MMX
AMD K6-2, K6-3-- MMX , 3DNow!
AMD Athlon -- MMX , EMMX , 3DNow!
AMD Duron -- MMX , EMMX , 3DNow!
AMD Athlon4/MP/XP -- MMX , EMMX , 3DNow!, SSE

ArchLinux: A Distribution Optimized for Intel Processors (P3 and Up) and Morgan-core Athlons

shadowhand · 2005-04-22 04:56:04

Ah, well then, SSE should be disabled.

Duke · 2005-04-22 04:57:05

No, not all i686s have sse, neither do they have 3dnow+ (is it + or maybe !, I can't remember, either way).

I was just wondering what arch's stance was. Regardless of uses, autovectorization is rather "cool", interesting to say the least.

Emulators, or games, or anything repeating simple loops over and over again would probably benefit from it though. But then again, abs can be used for such things.

Regardless, is the move to gcc 4 being considered?

phrakture · 2005-04-22 04:57:16

And from a gcc writeup about the architecture categories:

    * i386: All of the chips mentioned above.
    * i486: All chips mentioned above except the 386.
    * i586: All chips from above step, additionally eliminating 486.
    * i686: All chips from above step, additionally eliminating the Pentium, PentiumMMX, K5, K6, K6-2, and K6-3 chips. 

Note that due to the various extensions, these chip catagories are only binary compatible if you use strict x86 instructions (no SSE or 3DNow!, etc).

arooaroo · 2005-04-22 10:41:40

Duke, if you want the "cool" optimisations, then you are free to roll up your sleaves and get re-compiling your fav. packages via ABS.

I may try building a few packages myself to see the difference, but at the end of the day, I wouldn't not to see Arch break i686 compatbility. It's unfeasible to provide binaries for the possible permutations of i686 processors.

JGC · 2005-04-22 19:01:08

We won't bitch around with CFLAGS, only thing that could be added is -mmmx, since every i686 has MMX (and then suddenly some company makes an i686 without MMX, it happened to VIA C3 with CMOV )

About gcc 4.0: Not everything builds with gcc 3.4 yet, so I don't expect gcc 4.0 to be flawless. As with the new hal/dbus stuff we're having in testing, we have one very big example: Fedora Rawhide. They made the compiler, they make the patches, we patch our sources with it.

About gcc 4.0 that would be faster than 3.4: I don't think it's a big gain, since the thing that causes the biggest speedup is the visibility stuff that we got backported in our GCC 3.4 (not even gentoo has that )

phrakture · 2005-04-22 19:09:22

JGC wrote:

About gcc 4.0 that would be faster than 3.4: I don't think it's a big gain, since the thing that causes the biggest speedup is the visibility stuff that we got backported in our GCC 3.4 (not even gentoo has that )

And the visibility stuff is only going to affect shared objects which have *alot* of symbols which shouldn't be exported... kde/gnome - they have alot of symbols which should be internal to the library only

darkcoder · 2005-04-22 20:50:51

Due to the competition between AMD / INTEL it should be very difficult to completely optimize for one architecture without compromizing the other. Intel chips do not support 3Dnow extensions in any way, and AMD chips usually have problems with SSE type optimizations (imcomplete, slower than Intel ones), etc, etc.

Right now, the only distributions that allow full optimizations are metadata (source) distributions like Gentoo, SourceMage, OneBase and others.

Another point specified here is, except for multimedia and maybe scientific applications, nearly no one use those extensions. And in Linux, if you use a media player that uses the windows codecs like MPlayer or Xine based ones, the extensios are already used by the codecs itself.

Since the conflicts outweight the gains in providing extension binaries, dunno they ever be implemented on Arch. So you either: compile your own sources, beginning with the kernel, switch to a metadata distro, or switch to a better architecture like x64 or PPC and use an optimized distro which are very common for those two.

darkcoder · 2005-04-24 06:21:23

and forgot to tell you, as an ex Gentoo user with a P4 computer, I can tell you that some multimedia software in Linux has problems with either SSE or SSE2 flag. And you can check the Gentoo ebuilds and you'll found some of them filtering those flags.

jonathantan86 · 2005-04-24 06:33:15

JGC wrote:

We won't bitch around with CFLAGS, only thing that could be added is -mmmx, since every i686 has MMX (and then suddenly some company makes an i686 without MMX, it happened to VIA C3 with CMOV )

IIRC the Pentium Pro also is i686 but does not have MMX.

Gullible Jones · 2005-04-24 10:37:29

About GCC 4: like everything else, I'm guessing it will be implemented when it's proven to be stable and non-buggy enough for general use.

rose · 2005-04-25 07:13:55

It is a stable release, so why not? Arch should get gcc 4.0 as soon as possible.

Mythoz · 2005-04-25 08:26:05

rose wrote:

It is a stable release, so why not? Arch should get gcc 4.0 as soon as possible.

I would call it "stable" because there are still some cases where it produces wrong code.

rose · 2005-04-25 16:47:30

I didn't know that. I thought gcc guys don't release gcc versions which has serious code generation problems.

So I say you should wait until they resolve the issues, or switch to TCC or LCC or ICC or something else.

Gullible Jones · 2005-04-25 20:20:22

If you're going to release GCC 4, wouldn't you want to recompile all the Arch programs and libraries with it? Or is the difference not big enough to warrant that?

phrakture · 2005-04-25 20:27:32

I'd assume the difference won't be that great... and they'll all get compiled at some point (though it might bw worthwhile to recompile like libc or something)

miqorz · 2005-04-25 21:00:10

(paranoyd@tobias ~) $ gcc --version
gcc (GCC) 4.0.0
Copyright (C) 2005 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

No huge issues yet, Then again. I haven't been able to compile shit. lol

phrakture · 2005-04-25 21:01:53

mine says:

$ gcc --version
gcc (GCC) 4.0.0
Copyright (C) 2005 Free Software Foundation, Inc.
This is free software; see the soSegmentation fault

Gullible Jones · 2005-04-25 21:08:33

Wow.

neri · 2005-04-25 22:59:30

Hi,

some observations from recompiling packages with the new glibc/gcc combo.
- cpp on gcc definately feels faster
- resulting packages are remarkably smaller in size

but I can see no reason to force a recompilation of the whole distro so far.

-neri

miqorz · 2005-04-26 00:17:46

Well, I've just compiled wxgtk 2.6.0, amule-cvs, xchat 2.4.3 and other stuff against gcc 4.0 with zero issues.

JGC · 2005-04-26 12:04:51

Well, I just found out that the glibc snapshot has broken regular expression code.
grep doesn't work so well anymore with nested [ ] expressions ([[:space:]] results in an error about missing ] bracket... WTF?)
Also, flex is completely broken with this glibc snapshot. Fedora people can't reproduce it, so I'm compiling the package with their specific build options.

Arch Linux

#1 2005-04-22 04:21:36

Plans for gcc 4.0.0?

#2 2005-04-22 04:36:52

Re: Plans for gcc 4.0.0?

#3 2005-04-22 04:46:05

Re: Plans for gcc 4.0.0?

#4 2005-04-22 04:55:00

Re: Plans for gcc 4.0.0?

#5 2005-04-22 04:56:04

Re: Plans for gcc 4.0.0?

#6 2005-04-22 04:57:05

Re: Plans for gcc 4.0.0?

#7 2005-04-22 04:57:16

Re: Plans for gcc 4.0.0?

#8 2005-04-22 10:41:40

Re: Plans for gcc 4.0.0?

#9 2005-04-22 19:01:08

Re: Plans for gcc 4.0.0?

#10 2005-04-22 19:09:22

Re: Plans for gcc 4.0.0?

#11 2005-04-22 20:50:51

Re: Plans for gcc 4.0.0?

#12 2005-04-24 06:21:23

Re: Plans for gcc 4.0.0?

#13 2005-04-24 06:33:15

Re: Plans for gcc 4.0.0?

#14 2005-04-24 10:37:29

Re: Plans for gcc 4.0.0?

#15 2005-04-25 07:13:55

Re: Plans for gcc 4.0.0?

#16 2005-04-25 08:26:05

Re: Plans for gcc 4.0.0?

#17 2005-04-25 16:47:30

Re: Plans for gcc 4.0.0?

#18 2005-04-25 20:20:22

Re: Plans for gcc 4.0.0?

#19 2005-04-25 20:27:32

Re: Plans for gcc 4.0.0?

#20 2005-04-25 21:00:10

Re: Plans for gcc 4.0.0?

#21 2005-04-25 21:01:53

Re: Plans for gcc 4.0.0?

#22 2005-04-25 21:08:33

Re: Plans for gcc 4.0.0?

#23 2005-04-25 22:59:30

Re: Plans for gcc 4.0.0?

#24 2005-04-26 00:17:46

Re: Plans for gcc 4.0.0?

#25 2005-04-26 12:04:51

Re: Plans for gcc 4.0.0?

Board footer