Bilte a PC for programing......

Status
Not open for further replies.
Solution
As a rule of the thumb, high level languages DO NOT utilize the CPU well. And high-level algorithms DO NOT utilize the most obvious speed boost, namely multi-core. I would bet that using 4 cores would increase your speed two folds, at least. But the cost in programmer's time....

High-level makes your code easier to understand, and is less error prone. You pay with speed. You pay with a bloated code. But who cares? Wordstar editor ( 1970-1985) used 27 KB, with inline help. Word uses more then 100 MB of code. The Incredible Machine game was stored on a single disk, 360 KB. Current games use a single DVD , 4.7 GB of code.

Either you use the high-level C# and enjoy the ease of programming, or you insert complicated SSE mnemonics -...
As a rule of the thumb, high level languages DO NOT utilize the CPU well. And high-level algorithms DO NOT utilize the most obvious speed boost, namely multi-core. I would bet that using 4 cores would increase your speed two folds, at least. But the cost in programmer's time....

High-level makes your code easier to understand, and is less error prone. You pay with speed. You pay with a bloated code. But who cares? Wordstar editor ( 1970-1985) used 27 KB, with inline help. Word uses more then 100 MB of code. The Incredible Machine game was stored on a single disk, 360 KB. Current games use a single DVD , 4.7 GB of code.

Either you use the high-level C# and enjoy the ease of programming, or you insert complicated SSE mnemonics - gaining some speed, loosing the clarity of the code. You can't have them both.

If speed is a real issue, I suggest the proven 'Finish first, Optimize later' method:

(A) Define your most time-consuming operations. (B) Put them into separate routines. Simple ones, 'compare two arrays', 'combine two arrays', nothing complicated. Calling a routine (Call/Return) costs a few cycles, less then a sub-optimal IF/THEN/ELSE. (C) Write those routines in C, C#, X.net, whatever. (D) Build a library of those routines, and link it to your applications. (E) Finish your application, and test it.

Profile your application. How many times routine A was called? how long did it take? Use Intel tools (or others').

Now start replacing each routine, one by one, with a highly optimized version: only those that are worth it. Test by comparing the results of 'old version' to the 'new version', on real big data-sets: the comparison is automatic, for 'exactly the same' . Any inequality means a bug. Preferably, use C (lower level) or better - ASM with SSE.

And the optimal CPU? Don't waste your time fighting it with the acquisitions department. Just insist on a good one. Within half a year you will have a new, better CPU, 30% quicker. The fight may take longer.

Is there a budget? If Not, I'd recommend the 4930k, easily able to overclock and takes on anything.


...

Thanks,
Mrunited12
 
Solution
Status
Not open for further replies.