My system has 2 cpu's (xeon) with each 2 cores, so that's four total. That's certainly enough for now, one might think. But does Murphy's law still apply? When does enough cores break the bottleneck and turn the speed of the hard drive into the systems' bottle neck?

From the core monitor I can see that the OS is smart enough in spreading the load over the cores, and it is all snappy and what not. But will I in two years from now already crave for 4 cpu's or 2 cpu's with quad cores, etc?

Isn't basically anything over 1ghz that let's say .. has enough ram and fast bus speeds enough to do 90% of today's tasks?

Your CPUs are only a part of an overall system and your Motherboard dictates your Max, a higher board will give you the option of higher processing

Originally Posted by Floris

My system has 2 cpu's (xeon) with each 2 cores, so that's four total. That's certainly enough for now, one might think. But does Murphy's law still apply?

A good way to judge this? Open up taskmgr.exe, & go to its menus where you can select columns to display... once there, select THREADS.

Editing now for detail -> I *think* iirc, it is the EDIT menu, Select Columns to display submenu (I don't run "std. taskmgr.exe" here anymore, but instead, process explorer, which has some features I like, (such as being able to see services called libs & .exe's that svchost.exe, broker's - std. taskmgr.exe can't in Windows NT/2000/XP/Server 2003 @ least, & THAT FEATURE ALONE makes it excellent for finding & STOPPING malwares, even if service brokered))

Anyhow - The more "parent & child threads" you run, the greater the possibility of using ALL the cores (especially when the first one is "saturated" (nearing or @ 100% usage))...

The OS "process scheduler" subsystem kernel component's job is to do so, & NO NEED for what I call "explicitly multithreaded design" (where your code has to do # of CPU's detected PLUS Win32 API calls such as "SetProcessAffinity" either & the worst part, building your OWN scheduler for this)... just by designing via MULTITHREAD design, you get "SMP/HT/XCore ready code" because of this "implicitly".

Today's OS are HUGE leaps in this area, & continually get better @ it as well!

Even LINUX folks jumped onboard this 'bandwagon' & had to...

E.G. (iirc) -> Sub 2.2 linux kernel did NOT have re-entrant safe function/subroutine code @ the OS core level/kernel level (necessary for "enterprise level class" certification, for server class applications on multitasking/multithreaded OS)... & @ usermode/Ring3/RPL3 level, only an "emulation" of REAL threading (via round-robin to a single kernel mode thread)...

So, Linux Penguin #1 (L.T.) & others put it in... good stuff, made linux a contender @ every level now.

Originally Posted by Floris

When does enough cores break the bottleneck and turn the speed of the hard drive into the systems' bottle neck?

This can be offset, & NOT via CPU upgrades...

In fact, partially simply by using a 2nd disk, & moving the pagefile.sys there can help (& other stuff too like browser caches, temp ops, & logging + more too, creativity being the ONLY limit) as far as "disk I/O" & is generally CHEAPER too as a bonus...

HOWEVER - it's NOT cheaper, if you purchase TRUE SSD's as I have (solid-state drives, basically ram on a card with IO interface via a driver to an array/buffer, formatted & virtualized by the OS to appear to the HAL as a std. diskdrive)... but, you have MASSIVE speed this way (especially on seeks & access)!

Put it this way - I run "ONLY" 512mb of RAM in system RAM here... but, have a 1gb pagefile.sys partition on that SSD (which has the entire PCI 2.2 bus, all to itself, no other devices are on it in the way of addon boards/cards)...

What offsets lag here? Paging basically to RAM, albeit NOT system RAM, but that of the SSD instead... so, technically/in a manner of speaking?

My System RAM is really an L4 cache for me here... for the CPU!

I adopted this YEARS ago, & did well with a company called CENATEK, & EEC Systems (was on both their websites in reviews, front page etc. before ALL others, even Microsoft's "Tech Ed", 2 yrs. in a row in its hardest category (SQL Server Performance Enhancement), no less)...

... & MS is just starting to, now, use a variation of this very theme, in VISTA, with their use of Flashdrives for something VERY like it (bad move imo, using FLASH, but... then, what do I know, right?)

----

HOWEVER/PERHAPS? For MOST folks here, on this account?? Buying more RAM, if you can afford it & have room for it on your system's mobo IS THE BEST ROUTE... provided your system can function correctly with a full set of banks (not all mobos do well here though - especially w/ the 32-bit limit of 4gb).

----

If that is NOT an option? Look into "Trimming Services" (tuneups for XP/VISTA/2000 etc., as they work, not as well imo @ hardware (there is no software substitute imo, for more powerful hardwares) but, it works!), budget route, but can help!

Originally Posted by Floris

From the core monitor I can see that the OS is smart enough in spreading the load over the cores, and it is all snappy and what not. But will I in two years from now already crave for 4 cpu's or 2 cpu's with quad cores, etc?

Heh, probably - INTEL & AMD love programmers, especially gaming ones (or multimedia ones like video editing tools)... give coders the available power? They'll figure out HOW to "suck it up" & because mgt. today (& yes, this has happened to myself more than once) is so "keen on the HOLY DOLLAR" (shortsighted imo, releasing TOO quick, only to have to patch (or worse) later)?

We're told "Send it out the door anyhow", even if it has small bugs &/or useability issues... ones that might only take a few days more to resolve & remove, especially w/ Quality Assurance team feedback (not every company has this & should, would make more jobs & better product) via their regression tests & such!

We also design in "RAD" tools nowadays... vs. languages like Assembler or C (vs. C++, VB, Delphi (best of the lot here & I can PROVE this much from valid sources, especially for math & strings work which EVERY program does) etc.). Sure, makes for faster dev. times but, more "weight"... every object you instance? An extra 472 bytes... may NOT sound like much, but do it a few million times? You get my point.

However, mgt. is NOT "all wrong/off" here... bottom line is, it's about DOLLARS/POUNDS...

( & they often have "venture capitalists" behind the monies on projects (folks with a LOT of bread, who fund R&D for example, to get tax shields & such + to make coins too for their "ROI"... software's a cheapie too, compared to hardware intensive R&D))...

HOWEVER - if you deliver "late"? You get penalized...

This is the problem imo, w/ mgt. who have NOT done the job, hands-on, for years in the trenches... because they have not, they make INSANE deadlines promises.

However, on the "flip side"? Deliver shoddy product, you shoot yourself in the foot... it's a balance, like most things.

Originally Posted by Floris

Isn't basically anything over 1ghz that let's say .. has enough ram and fast bus speeds enough to do 90% of today's tasks?

It's all a (mgt. 'buzzword') 'synergistic system', pretty much like Cat said... every part, matters... depends on what kind of tasks you do!

FOR instance? Largely, a lot of what I do, is "diskbound" (mostly in WRITES too no less, which most folks don't do a LOT of, they do mostly READS)...

So, I spent a good chunk on THAT here, via a Promise Ex8350 RAID Caching Controller (128mb ECC ram onboard) + Dual WD Raptor "X" 10,000 rpm 16mb buffered disk in RAID 1 (for recovery purposes via the mirror effect of RAID 1)... I had to spend it for security AND speed, basically, on DISK subsystem here.

Only YOU know what you do most of though, so... that's a pretty varied question, with varied & personal answers!

APK

P.S.=> Now, there IS, yet another way... more involved, & DOES TAKE TIME (via performance counters & such, & perfmon.exe)... if you want/need that explanation? Let me know, I can post it... (editing this in later, it CAN be important)... apk

Floris wrote

crave for 4 cpu's or 2 cpu's with quad cores, etc?

maybe hun and maybe i will

@APK, Floris, Cinders - thank you guys - this has been one of THE most interesting posts so far. Excellent and very illuminating

Glad you enjoyed it Nick "we need to discuss more about general computing"

Originally Posted by Flamingo Rinse

@APK, Floris, Cinders - thank you guys - this has been one of THE most interesting posts so far. Excellent and very illuminating

Cool man... I am glad you enjoyed it - I "got into it", lol, so-to-speak!



* There IS more to do, but, the init. poster never replied (thank goodness, because using perfmon.exe to monitor performance counters, & being SURE they are ALL ON (well, in this case, memory/cpu/disk/OS really only are required imo)? It's a TINY BOOK to write out!)

APK