Back in April I did some very rough performance measurements of my new notebook vs. my desktop machine:
Back then I got the following numbers for a complete build of CMake:
Desktop, AMD Athlon XP2000+: 3:59 min
Notebook, Intel Core 2 Duo: 1:15 min
The conclusion was that it's time to upgrade my development machine. I did that last week.
So, the new machine is a Intel Q6600 Core 2 Quad. How long will this new CPU take to build CMake, in all its quadcore glory ?
Here's the number for make -j4: 0:33 min
Yes, that's 33 s compared to 359 second on my "old" machine.
That's more than 10 times as fast !
Now that's a real big improvement ! 
Before that Intel all CPUs I bought (except notebooks) were AMD. Why did I go for Intel now ?
Two reasons:
Beside that, I would have probably gone for AMD again.
Now there is also a new shiny Slackware 12.1 running on the box. Installation went smoothly, actually I didn't have to know anything, everything was configured fully automatically. Almost too easy. But of course in good old Slackware-style still completely in text mode
And also Slackware 12.1 still uses Lilo (i.e. no Grub). And this time Lilo even comes with a very stylish Slackware-themed graphical boot menu
Btw. the notebook will probably get a new SUSE 11.1 as soon as it is released. I heard just from too many problems with kUbuntu 8.10. Both kUbuntu 8.10 and SUSE 11.1 are AFAIK the first distros which will come with a kernel version with improved support for the Intel 3945 wlan. It's actually not really nice to have to upgrade the distro in order to get a newer version of a device driver.
Alex
Syndicate Blogs
Intel
I would buy an AMD system if the budget was under € 500.
The main reason are bad Intel chipsets (look at the Intel Onboard graphics - very low performance).
The AMD onboard HD 3200 work very good with Linux (Ubuntu and Opensuse at least) and are even capable of running Crysis with decent framerate's.
Intel graphic driver
re Intel graphic; exactly the reason why my next system will be an Intel too after years with AMD. All those download and reinstall probably problematic drivers after a kernel-upgrade will be gone
re upgrade distro to get a newer version of a device driver; why not just only update the kernel?
3:59 is not 359 seconds
Hey, just a little note on the whole 60 seconds in a minute thing. If it took 3:59 it took 239 seconds not 359 =P. Still a huge speed increase and congrats on your new machine.
Damn
Grmbl, somehow 3:59 looked to me like almost 6 minutes, not 4 minutes. Damn, now my box is slow
Alex
Fedora 10
Fedora 10 will be released in a few hours with a 2.6.27.5 kernel (and a few additional iwl* fixes). As far as I know, that's newer than what (K)Ubuntu 8.10 ships.
That said, in Fedora we do expect you to install our updates regularly! Just think of security updates.
Fedora
The notebook is used mainly by my girl friend, and she just wants it to work.
Isn't Fedora more like a bleeding edge distro, instead of an easy-to-use, rock stable distro ?
I always thought kUbuntu would be an easy-to-use distro for Linux newbies, but apparently the kUbuntu devs now consider "early adopters" their target group, which means it's out of the game for me (i.e. no candidate for my girl friends notebook anymore).
This leaves my basically with SUSE and Mandriva (never tried) I think.
Alex
Compile option
Hi, I think i've read that the j option could be up to nb of cores + 1, have you tried -j5?
Here are some tests with different j parameters on kernel compilation :
make
real 8m16.121s
user 7m17.040s
sys 0m48.452s
make -j3
real 2m56.214s
user 7m31.496s
sys 0m54.206s
make -j4
real 2m28.036s
user 7m39.624s
sys 0m55.730s
make -j5
real 2m24.702s
user 7m43.359s
sys 0m56.364s
although j5 gives a little advantage, it is not as much as i would have expected. But maybe the test is not that relevant...
the reason is
The reason for this is:
Imagine you have 4 tasks running in 4 cpus, and one of them starts reading from the disk. While that job is waiting on IO, the cpu it was assigned to is idle. This under utilizes cpu.
if you have 5 tasks, there will be an additional task waiting in the run queue, so when a process is waiting on IO, the one on the queue can jump in and use the freed up cpu.
More than 1 task may wait for IO, in this case, you would think that -j6, 7, 8.. would help, but there is a point at which the benefit is negligible, and in fact, the overhead of constant context switching will hurt. In the case of compiling, which is a largely CPU bound process, more than #cpu + 1 wont help much.
Same here
Yes, I tried also with -j5 and there was only a minor difference.
Alex