Software devs still not doing their jobs right!

[aidanjt]

I've been ranting on about this for years, always falls under deaf ears or mockery.. Software developers are ripping people off!.. none more so than Microsoft themselves (I'm aware that this is not a complete revelation to most people here). But to further my point, MMX has been around for well over 10 years now, and how many softare applications use MMX opt codes?.. very very few, even games which benifit greatly from MMX don't use it.. the old excuse "to support older cpu's" no longer stands, most people own a computer with a CPU over 1Ghz, most CPU's above that frequency supports SSE, even at that, the excuse is pathetic and flawed, you can write software to check supported instruction sets when it loads and enable opt code optimised algortyhims.

Also, symetrical multi-processing platforms have been around as long as MMX itself, I've been ranting that developers need to write software to leverage threading properly for a longgg time, again people say "why bother?.. most people only have a 1 cpu system"... only conviently forgetting Xeon workstations/servers and P4 HTT because of their AMD's uniprocessor or nothing stance.. Now with the event of Dual-Core CPU's, the term 'I told you so', just doesn't express how right I was.

So, currently CPU's stand like this:
SMP/Dual-core/HTT support: virtually none, very little software exists that properly distributes heavy processing loads evenly across CPUs via use of threading mechanisms.
x86_64 support: linux and gcc supports it, not 100% stable, lots of multimedia apps compiled under linux for amd64 fails or breaks, mileage varies greatly between configs. Windows XP x64 is released but virtually no software exists to use it.
SIMD Instruction sets (MMX, 3DNOW, SSE, etc): little software properly leverages SIMD opt codes to increase performance for mathmatically intensive software, instead relying on the compilers default FPU math, I was curious about the difference myself, and SSE3 managed to do mathmatical calculations on average 3 times faster than the FPU on my 3.2Ghz Intel P4E.. that is no small margn my friends, that's significant performance loss. And for all you AMD advocets out there yelling "thats why Intel sucks".. SSE on AMD CPU's are still faster than AMD's superior FPU.. however when compairing AMD and Intel's top end CPU's and having them do math with SSE, Intel comes out top.

So software developers need to:
1) stop releasing bloated FPU only binaries, control memory allocation, stop trying to make your program do 1000000 things at once, make it do its 1 specific job, and do it RIGHT, feature freeze to focus on fixing bugs once and awhile!
2) put the app into sleep if it has no work to do while waiting on messages.
* if the program at any time hits 99%+ CPU usage:
3) read up on threads, Intel and MSDN has plenty of documentation on it.. share workload between worker threads efficentively and evenly.
4) include SIMD opt codes, this will make a BIGGG difference to the performance of the application.

If software developers continue to fail to utilise CPU's and their acompanied architecture properly then we're just getting ripped off being forced to throw more money into RAM and CPU upgrades on an annual basis.

</rant>

If anyone has any comments, feel free to make them. I want to hear people's thoughts on the subject.

[Dougal]

I agree with this.

I'm finding it hard to find the 64 bit assembly codes.

And the stability problem with linux is more something to do with the kernel.

[StoneNewt]

I agree with most of what you have said, things really do need to change, I hope that seeing OSX on Intel processors will help at least help things a long some what. However...

And for all you AMD advocets out there yelling "thats why Intel sucks".. SSE on AMD CPU's are still faster than AMD's superior FPU.. however when compairing AMD and Intel's top end CPU's and having them do math with SSE, Intel comes out top.

... this is totally contradictory to what I've seen, I'm dealing with scientific programs written in FORTRAN & C using the Intel compilers. I've run various test & benchmarks on a wide range of code, types of calculations, compiler & compiler options as to which give the best performance on each CPU type and how each processor stacks up against the other, by far the best compilers are the Intel native compilers. With AMD processors I've found that turning off MMX & all SSE gives the best performance, run times are typically increased by 4% but can be up to ~15% (GCC compiled, Intel compiled code rand 4~6% longer when SIMD optimisation was enabled) when using compiled SIMD optimisation flags. Admittedly though this is compiler optimised not coder (we're talking scientists here not programmers). For Intel CPUs it's a different matter, SIMD optimisation rules, when properly optimised it's very close between the two manus as to which is quicker, in percentage terms it's near 50/50 split. However while AMD processors always give there or there abouts performance, the Intel CPUs can be way below par, in one case an old Athlon XP 2200+ (t-bread) was faster than a P4 3.2GHz (Prescott) on code that on the XP was bus limited (a 1.8GHz S754 processor completed the task in about 60% of the XP's time)

[aidanjt]

PrivatePyle, im not sure what you're trying to say here... if you develop a multi-threaded application it will work on both SMP and Uniprocessor machines, the kernel of the operating system deals with scheduling and thread distribution across the processors.

Multi-threading does not equate to hard to maintain and buggy code if it is done correctly. In actual fact, if leveraged properly, using worker threads to do different tasks is more benifical as you don't have to manually code your own scheduling methods, Operating systems schedual work distribution much more efficeint.

Software can request cpu allocation.. Windows doesn't do a horrible job of it... although Linux does a much better job of it..
I'm not sure what you're trying to say about your multi-threaded development, each process is launched within its own parent thread. Idealy this thread should only deal with GUI stuff since that isn't intensive work, should a program about to start heavy processing it should spawn an individual worker thread within that parent for each CPU and pass data onto the worker threads to work on.. Why expect Windows to do everything for you?.. thats just lazy and incompodent.

[Dougal]

But if you developed for both multi and single threaded systems, the code will be a LOT larger. Increasing distribution costs.

If you did 2 different versions costs would increase again, two different distributions who would know how many to buy of eachetc..

[StormPC]

I agree completely aidanjt.

The thing that really pisses ME off is that software companies are writing their 32 bit software to check for a 64 bit OS. If the software finds a 64 bit OS it will not even install even though AMD64/XP64 platforms are more than capable of running any 32 bit program. Talk about BA$TARD$!!!! Just makes me want to slap these greedy monkeys!

[aidanjt]

But if you developed for both multi and single threaded systems, the code will be a LOT larger. Increasing distribution costs.

If you did 2 different versions costs would increase again, two different distributions who would know how many to buy of eachetc..

binaries generally don't make the bulk of software's distribution size, a lot of it is theme crap, help files etc..

I can't see how developing multi-threaded code is going to explode bandwidth usage for a download site by adding 40kb or so of code.

[Nein]

PrivatePyle, im not sure what you're trying to say here... if you develop a multi-threaded application it will work on both SMP and Uniprocessor machines, the kernel of the operating system deals with scheduling and thread distribution across the processors.

Multi-threading does not equate to hard to maintain and buggy code if it is done correctly. In actual fact, if leveraged properly, using worker threads to do different tasks is more benifical as you don't have to manually code your own scheduling methods, Operating systems schedual work distribution much more efficeint.

Software can request cpu allocation.. Windows doesn't do a horrible job of it... although Linux does a much better job of it..
I'm not sure what you're trying to say about your multi-threaded development, each process is launched within its own parent thread. Idealy this thread should only deal with GUI stuff since that isn't intensive work, should a program about to start heavy processing it should spawn an individual worker thread within that parent for each CPU and pass data onto the worker threads to work on.. Why expect Windows to do everything for you?.. thats just lazy and incompodent.

"multi-threaded" applications inherently worked better with Distributed Multi-Processing (DMP) than Symmetric Multi-Processing (SMP).

Distributed Processing Multi-Task far more efficiently than Symmetric Processing. Symmetric Processing Single-Task more efficiently than Distributed Processing.

[aidanjt]

"multi-threaded" applications inherently worked better with Distributed Multi-Processing (DMP) than Symmetric Multi-Processing (SMP).

Distributed Processing multitask far more efficiently than Symmetric Processing.

DMP is a much bigger scope and doesn't quite relate to system archs directly. However your statement is generally true.. though SMP's ability to deal with threads is kernel related and not really the fault of the hardware.

[Nein]

DMP is a much bigger scope and doesn't quite relate to system archs directly. However your statement is generally true.. though SMP's ability to deal with threads is kernel related and not really the fault of the hardware.

It had nothing to do with scope, Distributed Processing (Bandwidth Based Processing) inherently be more "Multi" than Symmetric Processing (Time-Share/Time-Division Processing - Processing in round-robin, one at a time sequential symmetric timeslices) could.

[aidanjt]

It had noting to do with scope, Distributed Processing (Bandwidth Based Processing) inherently be more "Multi" than Symmetric Processing (Time-Share/Time-Division Processing) could.

Its out of the scope of this discussion as DMP isn't an architecture that people use at home/office... you don't see DMP systems sitting under peoples desks fragging in quake..

[Nein]

.

[Nein]

Its out of the scope of this discussion as DMP isn't an architecture that people use at home/office... you don't see DMP systems sitting under peoples desks fragging in quake..

Current AMDs are Distributed Processing designs, point-2-point, direct connect architecture, AMD multi-processor versions are DMPs not SMPs as most ignorant people assumed. Especially Intel trained and raised experts, most of them didn't even know what "Symmetric Processing" actually meant, they had no clue it was Intel trademark name for Time-Share/Time-Division Processing.

[StormPC]

Current AMDs are Distributed Processing designs, point-2-point, direct connect architecture, AMD multi-processor versions are DMPs not SMPs as most ignorant people assumed. Especially Intel trained and raised experts, most of them didn't even know what "Symmetric Processing" actually meant, they had no clue it was Intel trademark name for Time-Share/Time-Division Processing.

X2=SMP sort of (since 2 CPUs are sharing memory).

Opteron=DMP sort of (since each CPU can have it's own memory).

The dual-core Opterons use both (sort of) since the cores are sharing memory but the chips are not.

So what is your point and how does it relate to this thread? You know, software developers, etc...?

[Nein]

X2=SMP sort of (since 2 CPUs are sharing memory).

Opteron=DMP sort of (since each CPU can have it's own memory).

The dual-core Opterons use both (sort of) since the cores are sharing memory but the chips are not.

All of them are DMPs, the crossbar memory controllers will provide "simultaneous multiple data streams from multiple sources to multiple destinations" <-- eg. one data stream per processor per task isn't a problem, bandwidth is distributed to all, point-2-point, SIMULTANEOUSLY INSTEAD OF ONE DATA STREAM AT A TIME IN SYMMETRIC TIME SLICES.

They always do "sharing" for both SMP or DMP, SMP = sharing with one at a time sequential symmetric time slices per task (Time-Division - "PCI LATENCY" is a processing time slice duration value), DMP = sharing bandwidth between tasks simultaneously instead of one at a time (Distributed Bandwidth).

A 10/100 8-port HUB is a Symmetric Processing device, one data stream at a time per port in sequential symmetric time slices.

A 10/100 8-port SWITCH is a Distributed Processing device, bandwidth is distributed to all ports at once upon demands, assuming n-ways = 8.

So what is your point and how does it relate to this thread? You know, software developers, etc...?

If software developers are Intel trained (brainwashed - no clue to anything but Symmetric Processing and not even properly understood it meant Time-Share Processing), no clue to the fundamental differences of Distributed Processing from Symmetric Processing... They didn't know squat of how to really write software properly.

[aidanjt]

All of them are DMPs, the crossbar memory controllers will provide "simultaneous multiple data streams from multiple sources to multiple destinations" <-- eg. one data stream per processor per task isn't a problem, bandwidth is distributed to all SIMULTANEOUSLY INSTEAD OF ONE DATA STREAM AT A TIME IN SYMMETRIC TIME SLICES.

They always do "sharing" for both SMP or DMP, SMP = sharing with one at a time sequential symmetric time slices per task (Time-Division - "PCI LATENCY" is a processing time slice duration value), DMP = sharing bandwidth between tasks simultaneously instead of one at a time (Distributed Bandwidth).

A 10/100 8-port HUB is a Symmetric Processing device, one data stream at a time per port in sequential symmetric time slices.

A 10/100 8-port SWITCH is a Distributed Processing device, bandwidth is distributed to all ports at once upon demands, assuming n-ways = 8.


If software developers are Intel trained (brainwashed - no clue to anything but Symmetric Processing and not even properly understood it meant Time-Share Processing), no clue to the fundamental differences of Distributed Processing from Symmetric Processing... They didn't know squat of how to really write software properly.

Woh... First of all, your network annalogy is completely and utterly incorrect.. Hubs replicate the raw binary electrical signal and throw it out to all the ports at the same time.
Switches makes a decission as to which port it should forward a packet to based on the packets destination based on a MAC table the switch builds as it receives and sends traffic. This is why Switches are far better at passing packets around a network.

Secondly, I'm no brainwashed nieve idiot.. DMP has been used for a longggg time with mainframes and supercomputers, AMD isn't the first to use it, and the scale they do it on is largely irrelivent since their design is almost identical to that of SMP without Northbridge intervention between their processors.. All AMD has really done is slap a memory controller onto their CPU's, and renamed the FSB to Hypertransport Bus.. If Opterons were so amazing then why do high capacity servers use SPARC and Xeons?.. seriously get real fanboy.

Real DMP extends it scope way out to fibre links and clustering. Distrubting processing on a different level to software applications.

I also want to add that you've in no way contributed to the ongoing problem of software developers failing to utilise CPU features and techniques that can vastly improve the performance of their software and avoid us having to aquire a new PC every 2 years or so. In short you've completely went off topic and out of scope.