The state of 64-bit Desktop Linux

D. Hugh Redelmeier hugh-pmF8o41NoarQT0dZR+AlfA at public.gmane.org
Sat Feb 14 03:06:55 UTC 2009


| From: Marc Lanctot <lanctot-yfeSBMgouQgsA/PxXw9srA at public.gmane.org>

| > - Is the bottleneck CPU cycles, disk activity, network bandwidth, or
| >   something else?  We have been inferring that you think CPU cycle are
| >   the issue.
| 
| Definitely not network bandwidth. I doubt disk activity unless there's
| something going on that I don't know about, or Ubuntu is doing something
| wonky. I have reason to believe it's some interaction with the video
| card/driver because sometimes when I restart X it lessens the problem for
| about 20 minutes. Sometimes it doesn't help at all. I'm using NVidia
| proprietary drivers; at first I used the ones packaged with Ubuntu, now I
| mostly just download them from the NVidia site and build them. I have a
| GeForce 8600 GT.

There can be problems with caching of memory.  Have a look at
/proc/mtrr.  Is your video frame buffer write-combining?  All of it?
Is all your RAM write-back?

Is your BIOS the latest released by HP?

| >   + is there heat-throttling going on?  The P4D is quite capable of
| >     slowing down when it gets hot.
| 
| How can I tell?

There are applets that show the CPU speed and hence should reflect
throttling (I think).  The Gnome panel can have "CPU Frequency Scaling Monitor"
added on my F10 system, for example.  That would tell you the speed,
but not why the speed is set the way it is (heat? lack of work?).

| >   + is some kernel activity eating CPU.  Most tools don't help you
| >     figure that out.  I've seen that happen too.
| 
| Any tools that do?

I don't actually know.  Accounting for kernel time is a hard problem
because interrupts "steal" time from the user process that was
running.  Accounting correctly can add overhead to paths that must be
fast so historically that hasn't been done.

I imagine that there are now appropriate instruments but I don't know
them.

vmstat might work.  I don't know.

| > I recently had an interesting experience.  My hard drive was dying.
| > It would cause system slowdowns (I think) because of retrying.  No
| > symptoms but speed.  SMART scanning found some problems.  Touch wood,
| > the system seems much better with a new drive.
| 
| Is SMART an acronym for some program or used for emphasis? I wonder if it is
| disk activity. What did you use to find this?

Yeah, it is an acronym.  Try "man startctl".
http://en.wikipedia.org/wiki/Self-Monitoring,_Analysis,_and_Reporting_Technology

| > I like HP desktops so far.  Lennart has higher/different standards.
| > My HPs have been quite quiet.  But then I've never bought a P4
| > (Athlons seemed always like a better choice).
| 
| I don't like this thing at all. It's always had problems .. repartitioning
| Windows was a pain

That's likely a Windows issue, not an HP issue.

| and for some reason (BIOS problem?), drives are detected in
| different orders each time I boot in Linux. One time I'll boot and my Western
| Digital will be /dev/sda while my Seagate gets /dev/sdb. Next time I'll boot
| they'll be reversed.

Drives detected in different order may well be due to non-determinism
in controller detection.  Using UUIDs in fstab makes this a
non-problem.

| Well I would consider selling it to you at a decent price if you're interested
| :)

I haven't bought P4-based systems so far.  I'd have to have a
compelling reason to change that.  (Hint: I'm a cheapskate.)

| > P4s do 64-bit really badly.  I think many 64-bit operations have to go
| > through the ALU twice.  It was a tack on.  Athlon 64 and Core 2 are
| > quite good at 64-bit operation.

I should have said 64-bit integer operations.  I would expect (but
don't know) that the FPU is 64-bit.

Various bus widths might or might not be different too.

In serious number crunching, memory bandwidth (not just cache
bandwidth) often matters.  The Athlon and Intel Core i7 memory
controllers are better than previous generation CPUs.

| > 64-bit isn't as much of a win as one would expect.  Code density goes
| > down so there is higher cache pressure.  I've run x86-64 on my desktop
| > for three or four years but I don't think that I'd notice the
| > performance difference (it takes a fairly large difference to be
| > noticeable without some yardstick).
| 
| I can guarantee you that the things I run on it there will be a noticeable
| difference, not just in performance but accuracy of computation. Right now I'm
| working on solution techniques for large games.. most of the computation is
| double-precision arithmetic. The more accurate the computations are, the less
| iterations the algorithm needs to do to ensure a certain tolerance/precision.
| So... any extra speed I get from using it as a desktop is just bonus.
| 
| At the moment I need to run my large jobs on remote servers; it'll be nice to
| run some of my large jobs overnight without worry that I'd be affecting other
| people's work and that they won't be affecting mine.

The x87 FPU (used in i386 ABI) does intermediate calculations in
greater precision than the SSE FPU (used in x86-64 ABI).
Fundamentally, the x87 FP registers are 80-bit rather than 64.  This
can make a significant difference in the error accumulation is such
calculations as inner product.  Other than that, the FP precisions are
the same in both architectures, I think.

The P4 has SSE if you prefer it to x87.

Doing FP calculations in video cards is starting to become
interesting.  Decent double precision support may be coming (it wasn't
there when I last looked).  The IBM Cell's latest version does DP
better than the one in the Sony PS3, if I remember correctly.  But the
programming model is quite different from single processors.
--
The Toronto Linux Users Group.      Meetings: http://gtalug.org/
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://gtalug.org/wiki/Mailing_lists





More information about the Legacy mailing list