multi core cpu's?

GhengisKhan

Supreme [H]ardness
Joined
May 16, 2005
Messages
7,776
I'm currently running Mint Cinnamon 16 on my main rig which has an AMD 6 core. I feel like I'm not getting the performance I should be getting. Is there any way to tell if my system is utilizing all 6 cores? Under Windows I had to install special drivers to have more than one core recognized, is there something I need to do?
 
is there something I need to do?

Most likely No. Linux will use all cores without any need for the user to make any settings change. The last time I had to worry about this was the late 1990s early 2000s.

Is there any way to tell if my system is utilizing all 6 cores?

cat /proc/cpuinfo

for example:
Code:
jmd0 ~ # cat /proc/cpuinfo 
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 23
model name      : Intel(R) Core(TM)2 Quad  CPU   Q9550  @ 2.83GHz
stepping        : 7
microcode       : 0x703
cpu MHz         : 2003.000
cache size      : 6144 KB
physical id     : 0
siblings        : 4
core id         : 0
cpu cores       : 4
apicid          : 0
initial apicid  : 0
fpu             : yes
fpu_exception   : yes
cpuid level     : 10
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good nopl aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 lahf_lm dtherm tpr_shadow vnmi flexpriority
bogomips        : 5965.99
clflush size    : 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

processor       : 1
vendor_id       : GenuineIntel
cpu family      : 6
model           : 23
model name      : Intel(R) Core(TM)2 Quad  CPU   Q9550  @ 2.83GHz
stepping        : 7
microcode       : 0x703
cpu MHz         : 2003.000
cache size      : 6144 KB
physical id     : 0
siblings        : 4
core id         : 1
cpu cores       : 4
apicid          : 1
initial apicid  : 1
fpu             : yes
fpu_exception   : yes
cpuid level     : 10
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good nopl aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 lahf_lm dtherm tpr_shadow vnmi flexpriority
bogomips        : 5965.99
clflush size    : 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

processor       : 2
vendor_id       : GenuineIntel
cpu family      : 6
model           : 23
model name      : Intel(R) Core(TM)2 Quad  CPU   Q9550  @ 2.83GHz
stepping        : 7
microcode       : 0x703
cpu MHz         : 2003.000
cache size      : 6144 KB
physical id     : 0
siblings        : 4
core id         : 2
cpu cores       : 4
apicid          : 2
initial apicid  : 2
fpu             : yes
fpu_exception   : yes
cpuid level     : 10
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good nopl aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 lahf_lm dtherm tpr_shadow vnmi flexpriority
bogomips        : 5965.99
clflush size    : 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

processor       : 3
vendor_id       : GenuineIntel
cpu family      : 6
model           : 23
model name      : Intel(R) Core(TM)2 Quad  CPU   Q9550  @ 2.83GHz
stepping        : 7
microcode       : 0x703
cpu MHz         : 2003.000
cache size      : 6144 KB
physical id     : 0
siblings        : 4
core id         : 3
cpu cores       : 4
apicid          : 3
initial apicid  : 3
fpu             : yes
fpu_exception   : yes
cpuid level     : 10
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good nopl aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 lahf_lm dtherm tpr_shadow vnmi flexpriority
bogomips        : 5965.99
clflush size    : 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:
 
I'm currently running Mint Cinnamon 16 on my main rig which has an AMD 6 core. I feel like I'm not getting the performance I should be getting. Is there any way to tell if my system is utilizing all 6 cores? Under Windows I had to install special drivers to have more than one core recognized, is there something I need to do?

Linux is THE multi threading operating system. It uses all CPU cores and memory much more efficiently than windows ever did.
The 2 main things that make linux sluggish (besides just plain antiquated system) is video and not having enough memory.
For the most part 2d and 3d performance for linux is poor compared to Windows which always has finely tuned OEM drivers.
If you use linux likely your are running a "hack" video driver for the lack of better words.
This is the open source drivers that the distro defaults to. Its effectiveness is all over the map depending on your hardware. And that can be good on some hardware, no boot at all on others. There are OEM linux drivers from AMD and Invidia. Overall they are better then the open source one but still the performance is not as good as the windows versions. This is 100% the fault of the AMD and Nvidia. It isn't as good because they do not want it to be. If they were not snobbish to this end; they would invest as much effort into getting linux video performance up to part as they have in windows.
But like everything it is a calculation. The (skewed in my opinion) survey says only 1.5% of computer users use linux. That equals a waste of time to them. :mad:
 
Linux is THE multi threading operating system. It uses all CPU cores and memory much more efficiently than windows ever did.
The 2 main things that make linux sluggish (besides just plain antiquated system) is video and not having enough memory.
For the most part 2d and 3d performance for linux is poor compared to Windows which always has finely tuned OEM drivers.
If you use linux likely your are running a "hack" video driver for the lack of better words.
This is the open source drivers that the distro defaults to. Its effectiveness is all over the map depending on your hardware. And that can be good on some hardware, no boot at all on others. There are OEM linux drivers from AMD and Invidia. Overall they are better then the open source one but still the performance is not as good as the windows versions. This is 100% the fault of the AMD and Nvidia. It isn't as good because they do not want it to be. If they were not snobbish to this end; they would invest as much effort into getting linux video performance up to part as they have in windows.
But like everything it is a calculation. The (skewed in my opinion) survey says only 1.5% of computer users use linux. That equals a waste of time to them. :mad:

NVIDIA driver performance on Linux is equivalent to Windows. It has to be because NVIDIA has traditionally had important business customers on Linux.

AMD's are not up to snuff because they don't have the money to invest in Linux, and have preferred to fund the open-source drivers instead.

I agree though that the OP's performance issues are probably GPU related.
 
I am running an ATI card, with the AMD Catalyst drivers, maybe time to get an nvidia card.
 
thank you, all cores showed up.

Linux Mint might just be bloated enough that the performance you're getting is the performance you should be getting. Is the performance particularly bad? Is it much worse than Windows? You'd have to be a little more specific.

Linux is THE multi threading operating system.

No it isn't. There's absolutely nothing special about multi-threading in Linux compared to any other operating system.

It uses all CPU cores and memory much more efficiently than windows ever did.

Go ahead and try to substantiate that claim. You'll, run into a few problems, one namely being that it isn't true.
 
No it isn't. There's absolutely nothing special about multi-threading in Linux compared to any other operating system.



Go ahead and try to substantiate that claim. You'll, run into a few problems, one namely being that it isn't true.

Sure there is something special about multi-threading in any OS as they all use different schedulers. Performance from any 1 scheduler will show differences. However the biggest differences appear in the GUI. In linux there is a choice of what you would like to pull from userspace to create a system to fulfill your needs. In windows this does not exist. MS will tell you what you need. Therefore direct comparisons are difficult at best.
Modern Windows uses a much more complicated scheduler as opposed to Linux. But this is straying from the point. It is not such a black and white answer. We could continue discussing how a multilevel feedback queue compares to CFS (or BFS) and we haven't even touched on a BSD's larger multilevel feedback queue, but leads to a very technical discussion that is probably better left to a student writing a paper than someone like me who would rather go outside than try and remember lectures.
 
Sure there is something special about multi-threading in any OS as they all use different schedulers.

Different != special. Certainly not to the extent which would make Linux 'THE multithreading operating system'. Every modern operating system provides the necessary facilities and structures for fast scheduling and multi-threading. Certainly anybody who has written software for Windows and Linux alike can tell you that the threading model in Windows is very, very much different from something like pthreads. However, they both offer threading models and you can write high performance code for either platform. The differences between these threading models might matter if you're trying to write a very fast parallel implementation of the Jacobi eigenvalue algorithm for a matrix data structure you're writing to model electron trapping in organometallic compounds. (maybe you're a solar panel researcher, for instance). These differences are not going to matter in general-purpose computing, e.g. how fast your operating system's GUI feels.

The different threading facilities between, say, Linux and Windows are merely differing means to a similar end, that end being performance. While these means may be different, the end goal is the same and for general purpose computing both of them are going to fall along the same yard-line. The idea that Linux's multi-threading facilities would allow it to be far more responsive than Windows if it weren't for 'slow drivers' (this is the notion I was combating in the post you quoted, in case you didn't bother to read it in context) is absurd.

In case you're having trouble stepping back and looking at the big picture, threading on Linux versus Windows has absolutely nothing to do with the thread starter's performance nor his system's potential for performance compared to when he was running Windows. Posters shouldn't be giving him the expectation that his system should be so much faster running Linux than Windows, or saying that Linux will use his resources better than Windows can, because these statements aren't true. If his system isn't all that fast on Linux, it might just be because it isn't going to be all that fast on Linux, rather than there being some 'problem' holding him back from unleashing Linux's 'superior threading'.
 
@Dogs, that is absolutely true in regards to what the OP was asking. Didn't mean to derail this thread.
 
NVIDIA driver performance on Linux is equivalent to Windows. It has to be because NVIDIA has traditionally had important business customers on Linux.

AMD's are not up to snuff because they don't have the money to invest in Linux, and have preferred to fund the open-source drivers instead.

I agree though that the OP's performance issues are probably GPU related.

Nvidia doesn't actually invest anything to linux. The blob drivers are maintained by two coders much like a hobby.
 
Back
Top