Plans for gcc 4.0.0?

jery_wang2002 · 2005-05-18 05:40:20

Agree to what you said.

To add,

I guess IO is more important, many of use like to close/open application quite often, and everytime we use our PC, we need to wait for the system to load from hd. When we browse we are waiting for the page to be loaded.

Everyone (average user) is using browser nowadays. Much of time is spend on waiting: application to opens up/load, page to load, copying files locally, or through network. Downloading files, etc.

The most noticeable speed difference if the system allows me to click any part of the desktop and the action comes right away. Just an example, on my P4 2.4 GHz, 1GB RAM system, Suse 9.3 takes about 1-2 seconds to response my clicking on the gnome menu for the first time.

When I open too many application and window, alt-tabbing application is not so fast. Sound sometimes is interrrupted when copying large files. This is something that the average user will see.

I suggest arch should try to improve the responsivity of the desktop including network and filesystem efficiency. Very few user will need the high performance like FFT calculation unless this indirectly the responsitivity of the desktop.

phrakture wrote:

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

JGC · 2005-05-19 11:26:49

gcc 4.0.0 produces buggy code and is blacklisted by KDE, which renders it unusable.
At this moment I'm running a gnome 2.11 prerelease branch with gcc 4.0.1 snapshot, which has been "released" to the public for testing a few days ago:

[jan@jan gnopernicus]$ gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.0-20050514/configure --prefix=/usr --enable-shared --enable-languages=c,c++,objc --enable-threads=posix --enable-__cxa_atexit
Thread model: posix
gcc version 4.0.1 20050514 (prerelease)

This one runs together with binutils 2.16 and an updated glibc snapshot. As far as I have seen, there haven't been problems with this combination yet, but I didn't compile KDE with it (yet).

cactus · 2005-05-23 00:58:22

I cant wait to try -D_FORTIFY_SOURCE=1
Supposedly there is very little overhead too.

celeron2002 · 2005-07-08 13:47:28

July 7, 2005
GCC 4.0.1 has been released.

iphitus · 2005-07-08 14:12:30

jery_wang2002 wrote:

Agree to what you said.
To add,
I guess IO is more important, many of use like to close/open application quite often, and everytime we use our PC, we need to wait for the system to load from hd. When we browse we are waiting for the page to be loaded.
Everyone (average user) is using browser nowadays. Much of time is spend on waiting: application to opens up/load, page to load, copying files locally, or through network. Downloading files, etc.
The most noticeable speed difference if the system allows me to click any part of the desktop and the action comes right away. Just an example, on my P4 2.4 GHz, 1GB RAM system, Suse 9.3 takes about 1-2 seconds to response my clicking on the gnome menu for the first time.
When I open too many application and window, alt-tabbing application is not so fast. Sound sometimes is interrrupted when copying large files. This is something that the average user will see.
I suggest arch should try to improve the responsivity of the desktop including network and filesystem efficiency. Very few user will need the high performance like FFT calculation unless this indirectly the responsitivity of the desktop.
phrakture wrote:
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

Try patch your kernel with the ck patchset. I find that I never get audio skipping and things when doing hard driver work or other intensive things. ATM im on a vanilla Arch 2.6.11.10, and it's driving me up the wall with music skipping when I restart X or do heavy hdd work, CK never did that

iphitus.

scarecrow · 2005-07-08 19:30:27

Music never skips here with stock 2.6.11.10 and either the onboard Intel i8x0 crap or an Echo Mia... so the issue "might" be hardware dependent.

iphitus · 2005-07-09 01:47:26

If I do anything particularly intensive or do something like, an updatedb (update of the slocate database) or switch out of X, or restart X, it skips.

It's not hardware dependent if the CK patches 'fix' it.

Cotton · 2005-07-10 13:47:58

I get music skips when there's intensive hd activity but I've put it down to a memory leak in Firefox (lots of tabs open), even though top & htop report 100's of MB free swap but <10 MB RAM available (out of 512 MB physical).

And I'm using the 2.6.12-ck3 patch on an XP1800 machine.

It does appear more sluggish on first usage after leaving it on overnight.

reub2000 · 2005-07-25 08:33:36

Very few people I know still use a P2, so I don't know why a distro like arch has to support it. Besides, they will always be supported by another distribution like debian.

iphitus · 2005-07-25 08:43:36

reub2000 wrote:

Very few people I know still use a P2, so I don't know why a distro like arch has to support it. Besides, they will always be supported by another distribution like debian.

Heh, no, get stuffed?

Take a look outside your suburb. Not everyone has a pentium 4. Not everyone has dough to throw around. Many people still have a pentium 2 or even lower as their primary computer.

My server is a P2, which runs Arch. *Plenty* of people run Arch on P2s.

Besides, it's not like its any trouble to support a P2.

iphitus

reub2000 · 2005-07-25 09:00:50

Yeah, there are still people that use P2 and lower computers. But I don't really see why one of hundreds of linux distros has to try and serve everybody and their grandma.

iphitus · 2005-07-25 09:10:28

reub2000 wrote:

Yeah, there are still people that use P2 and lower computers. But I don't really see why one of hundreds of linux distros has to try and serve everybody and their grandma.

You're here ten minutes and already making provocative comments.

I like you! I needed someone new to flame!!!

Why?

Again, it's no skin off the knees of JUdd or any of the developers to support pentium 2. It's no extra effort at all.

And to be frank, most distros support i486 or Pentium 1's (i586) and above. Arch is unusual and in a small (non existant?) group of distros that support P2 (i686) and above.

iphitus

deficite · 2005-07-25 17:52:47

reub2000 wrote:

Yeah, there are still people that use P2 and lower computers. But I don't really see why one of hundreds of linux distros has to try and serve everybody and their grandma.

Do you even understand how to use Arch yet? If you really understood Arch you'd know that serving "everybody and their grandma" is not our goal. Like iphitus said, we are in a small group of distros that are P2 and up. What do you want? A distro that isn't compatible with anything but gets a whole 2 or 3 more FPS in Unreal Tournament 2004 by optimizing for a specific architecture?

Also, if you really understood how to use Arch you'd realize that using makepkg you can optimize for whatever architecture you choose. You want to gain a whole 3 FPS in Unreal Tournament? Just recompile everything from source and try to fight Arch. Or you can try to understand Arch and embrace its beauty in simplicity.

JGC · 2005-07-25 21:03:53

Ah, so I have to use an unmaintained pentium2 port for my netboot clients... Thought that I got rid of that problem by switching my K6 and Pentium MMX machines with cheap P2 PCs... wrong guess it seems...

Optimizing for anything more than i686 would be useless also: we could use -mtune=pentium4, which allows code to run on all i686 machines, but tunes for pentium4. But what about the Athlon users? Do we optimize our distro for only half of our users? Not everyone has a P4.

I think the only optimized packages we will support will be kernel and glibc, the same way debian does with athlon/p4/whatever kernels and a libc6-i686 package.

iBertus · 2005-07-26 04:12:44

It's just not worth it to make things so complex! Arch is very fast and adding --uber-optimize and specific CPU optimizations just wouldn't make much difference. Most optimization benchmarks show differences in 1/1000s of seconds at the most. Also, too many optimizations can break some software packages completely.

I personally like the fact that Arch will run on any i686. I've got a P4, PIII, Athlon XP all running or eventually running Arch. Can't really tell a difference between them unless I'm using stuff like Gimp or playing games.

sarah31 · 2005-07-26 05:44:54

and even then the speed differences are not always from optimizations but differences in architecture and the efficiency of each architecture.

Arch Linux

#26 2005-05-18 05:40:20

Re: Plans for gcc 4.0.0?

#27 2005-05-19 11:26:49

Re: Plans for gcc 4.0.0?

#28 2005-05-23 00:58:22

Re: Plans for gcc 4.0.0?

#29 2005-07-08 13:47:28

Re: Plans for gcc 4.0.0?

#30 2005-07-08 14:12:30

Re: Plans for gcc 4.0.0?

#31 2005-07-08 19:30:27

Re: Plans for gcc 4.0.0?

#32 2005-07-09 01:47:26

Re: Plans for gcc 4.0.0?

#33 2005-07-10 13:47:58

Re: Plans for gcc 4.0.0?

#34 2005-07-25 08:33:36

Re: Plans for gcc 4.0.0?

#35 2005-07-25 08:43:36

Re: Plans for gcc 4.0.0?

#36 2005-07-25 09:00:50

Re: Plans for gcc 4.0.0?

#37 2005-07-25 09:10:28

Re: Plans for gcc 4.0.0?

#38 2005-07-25 17:52:47

Re: Plans for gcc 4.0.0?

#39 2005-07-25 21:03:53

Re: Plans for gcc 4.0.0?

#40 2005-07-26 04:12:44

Re: Plans for gcc 4.0.0?

#41 2005-07-26 05:44:54

Re: Plans for gcc 4.0.0?

Board footer