Linux - HardwareThis forum is for Hardware issues.
Having trouble installing a piece of hardware? Want to know if that peripheral is compatible with Linux?
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
But if you're after the performance, bear in mind that the quad core will be outperformed by the dual core. There are still relatively few applications that are dual core ready, let one alone quad core. Add to that the lower clock speed and the slower bus of the quad and you will find that the dual core performs better in real-world situations regardless of benchmarks.
Then again, yes, a quad is probably a bit more future-proof but that shouldn't matter if you are goin to upgrade again in a year or two. We may have dual octo-cores by then...
Intel will be moving away from the FSB VERY soon.
I would like to see some confirmation on that. Yes, they are working on on-die memory controllers but only for high-end server processors. The FSB isn't going to go away for the next few years.
I thought about a similar thing, when buying a new computer: to buy an AMD dualcore or an AMD quadcore. In the end I thought that I don't get that much more use of four cores than I do from two, and because of the exact specs I then picked up the dualcore. And even if Intel and/or AMD were moving to more-core cpus, it's not like the "older" ones are going away: these dualcores have been around for ages, and still you can find rather easily single-core cpus that are nice. If you wanted to be future-proof, you'd need to find yourself a 16-cpu board..but what would you do with it?
Even if you buy a quadcore today, thinking that next year it's still hot and the year after that compared to dualcores, you're forgetting that in a year or two the hardware is (compared to the newly released hardware) old and dusty. If you're a gamer you are still going to renew your machine, and if you're not, you don't care
p.s. I think quadcore cpus are rather old; I run my IRC client on more cpus than that, only the machine I run it on is not mine (I happen to have a shell account) there are several ways to do things, I suppose..
Though I have a question (please excuse my n00bieness), you say that the C2Q is clocked lower than C2D. But what about the cache then (where C2Q has 8mb while C2D only has 4mb)? Will it not affect the performance?
There are still relatively few applications that are dual core ready, let one alone quad core.
If the application supports SMP, it will support both in most cases. Unless, the programmers can't divide tasks into more than 2 that can be run in parallel, in which case it will support only 2 cores. Can you name any examples of something like this ?
That is true but having more threads needn't be an advantage. In many cases, it only means more work and more overhead. And if threads need to wait on each other and send out notifications, the advantage is almost zero, in fact, it will often make an application slower. And the more threads there are, the worse it gets.
Most (certainly not all) of the programs that will see dramatic speed increases have been adapted to multi thread operation. An easy example of this would be Avidemux (video conversion). When it went from single threaded to multithreaded the time needed to do a specific task was reduce to about 60%(on a dual core machine). Other cases like mprime (prime number finder) are still single threaded due to the nature of the problem.
Another point to consider is how many tasks you have running at any one time. Single core cpus will run multiple tasks at once but slow down considerably as you add more tasks. On multicore cpus you can run multiple applications(within reason) with only minimal slow down.
Thank you all very much for the response! May be I should have described what I am planning to use this computer for, in the first place.
First of all this is supposed to be a desktop machine. And here are some of my habits: I am used to have many apps running at the same time. For example, right now I'm running:
openbox - my window manager of choice
amarok - my primary music player
mysqld - used for music statistics server for amarok
konqueror - mainly file browsing, but also some occasional web browsing
firefox - my primary web browser
basket - my primary note jotting software
azureus - my primary source of trying new distros
xterm - I have 9 of these running at any given time
soffice - open pretty much 100% of the time
kmess - my msn client of choice
Occasionally I also run compiz just to show off some nice-looking desktop effects. I also have a second monitor which I usually use for movies (mplayer/xine/vls) or slideshows (smoothslideshow) to provide a kind of a background when I work.
From time to time I do some gaming, random rendering (be it POV Ray - which btw has multi-core support in its latest beta version, or blender+yafray), programming (using either just kwrite or kdevelop for the larger projects) or illustration (gimp + inkscape).
All in all, does this kind of use suggest usage of a dual or quad core cpu?
PS. Is there anyone who could answer my question about the CPU cache? C2Q has 8mb while C2D has only 4mb - what kind of consequence will this have on performance and how important is it really.
Well, bigger CPU cache is better, but this usually scales with the speed of the processor, there's no use for a big CPU cache on a slow processor, as it'll be empty most of the time. Heh, maybe I can argue this is another reason the Quad Core is better
An example might be: I have a P4 with HT (hyperthreading), if I turn off HT it runs slower than with HT on. They say that even unicore processors with no HT will benefit from turning SMP on in the kernel (althrough I don't believe this).
Mostly I think the more multitasking you do, the more you need more cores
Last edited by H_TeXMeX_H; 04-05-2008 at 10:01 AM.
there's no use for a big CPU cache on a slow processor, as it'll be empty most of the time
Hmm, not being too well-versed in the field of hardware (must have become rather apparent by now ), I have to ask: What is the purpose of the CPU cache in the first place? Is it a storage for data already processed or data yet to be processed?
Cache is an extension to RAM built into the CPU. It is an affordable way of speeding up memory accesses as it is faster than RAM (but not all caches are born equally: speed decreases as the cache level increases: L1 > L2 > L3). Having more cache is beneficial as more cache can store more data for fast access. As always, that is only one side of the story, though. Much depends on the implementation. Does the CPU use direct or indirect caching or something in between? What is the ratio between the sizes of the various caches? Is the cache backed by an on-die memory controller? I have the impression that AMD is more responsive doing lighter tasks (such as simply launching a browser) while it definitely gets beaten by Intel when it comes to tasks involving more CPU power (partly) because of the larger cache. However, when its cache gets too small, Intel is once more confronted with its limitations and loses out to AMD with its on-die memory controller. That is something that Intel has implicitly recognized now that they have started work on high-end CPUs that do have an on-chip memory controller.
Now, to answer your question: 4 or 8MB? That would depend on what use the processor is put to. 4 is plenty for a dual core. Whether 8 for a quad core means better would depend on the extent to which all cores get used, which in its turn depends on the software. Was it written to take advantage of as many cores as are available or not? If yes, then more cores and more cache is a good thing; if no, it doesn't matter and it may even hurt. Thinking that all applications that were optimized for dual core will run just as well or even better on a quad core is naive. Each requires different coding decisions. Then again, if you write code yourself, you may as well get a quad as it easier to write for single or dual core on a quad than the other way round. All in all, it's a mixed picture. I read some articles some time ago and it's hard to come to any conclusions. The Quad 2.4Ghz was up to 15% slower in some of the tests while it was up to 35% faster in other ones (but all of those where rendering related). In short,for common tasks today the dual core should be a slightly better choice; the quad for a future-proof CPU (does that even exist?) that is going to do more than occasional multimedia processing or that is going to run many applications at the same time.
for the Quad: 4 x 2.4 GHz = 9.6 GHz
for the Dual: 2 x 3.0 GHz = 6.0 GHz
That comparison doesn't make much sense as you can't simply add up the numbers. With applications that use only one core, you'll have either two that can run at 3.0 or 4 that can run at 2.4. With multi-threading, an app will use a bit of core1, a bit of core2, etc.
With multi-threading, an app will use a bit of core1, a bit of core2, etc.
But is that the case also when running CPU-intensive tasks? I thought that for example rendering would use all present cores pretty much up to their maximum capacity? Because if that is true, you can pretty much add up those numbers as I did, but only for these types of applications.