Software devs still not doing their jobs right!

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.

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.

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...

Quote:

---

Originally Posted by aidanjt

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)

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.

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..

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! :rant:

Quote:

---

Originally Posted by 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..

---

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.

Quote:

---

Originally Posted by 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.

---

"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.

Quote:

---

Originally Posted by Nein

"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.

Quote:

---

Originally Posted by aidanjt

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.

Quote:

---

Originally Posted by Nein

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..

.

Quote:

---

Originally Posted by aidanjt

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.

Quote:

---

Originally Posted by Nein

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...?

Quote:

---

Originally Posted by StormPC

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.

Quote:

---

Originally Posted by StormPC

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.

Quote:

---

Originally Posted by Nein

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.

Oh I see. Well I can't really argue the point that software people are keeping up with hardware. They aren't. In fact, it seems that the faster computers get the more inept programmers become, simply because they can. They are dealing with virtually unlimited storage and memory, and incredible processor and graphics card performance. They simply do not need to be as good as programmers used to be.

Fanboy aidanjt? That's really unnecessary.

And just about everyone knows why servers use Intel more often than AMD. It's pretty much the same reason more people use Celeron than A64. Nothing complicated, just marketing.

The new X2 will stomp most Xeon dualies at almost everything. The dual-core Opterons are so much more powerful than anything Intel has to offer. Does it matter? No, because most IT Networking types know squat about hardware.

StormPC.. thats a true and valid point, hardware is performing extreamly well, however all that is driven by monies invested by companies and individuals splashing out every two years on new desktops and workstations because software is bogging down their old machines with bloat, poor code, and not taking full advantage of the processors. Which is the thing that is annoying me.

Quote:

---

Originally Posted by aidanjt

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.

---

How about one data stream broadcasting to all ports for one intended destination? How did it perform 2 data streams to 2 destinations -- at once or sequential one at a time?

Quote:

---

Originally Posted by aidanjt

quSwitches 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.

---

Switches are simultaneous n-ways devices, one data stream to 8 ports or 8 data streams to 8 ports, hubs are one data stream at a time devices.

Quote:

---

Originally Posted by aidanjt

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.

---

Actually, we graphic hardware guys were the majority and the first users of DMP. Our graphic problems had always been with insufficient never enough bandwidth, bandwidth based processing is our normal solution. Notice GPUs tended to be very low core frequency? They aren't Time-Share Processing designs, had not been for a long long time.

Quote:

---

Originally Posted by aidanjt

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

---

No wonder when nVIDIA mentioned "Scalable Link Interface" and no one seemed to have a clue.

A hub is nothing more than a multi-port repeater.
Switches DO NOT send the same packet out to different ports the recipent is already listed on the MAC table

Who the hell taught you networking?

Right.. so nVidia GPU's existed long before the days of mainframes? Do some research.

And you're still going off topic. How rude.

Quote:

---

Originally Posted by aidanjt

A hub is nothing more than a multi-port repeater.
Switches DO NOT send the same packet out to different ports the recipent is already listed on the MAC table

---

A switch can function as a hub by sending one data stream to all ports, a hub can not function as a switch as it can only send one data stream at a time.

Quote:

---

Originally Posted by aidanjt

Who the hell taught you networking?

---

I worked on Scalable Link Interface hardware even before T1 (mid '80) came into existence.

Quote:

---

Originally Posted by aidanjt

Right.. so nVidia GPU's existed long before the days of mainframes? Do some research.

---

nVIDIA didn't invent GPUs.

Quote:

---

Originally Posted by aidanjt

And you're still going off topic. How rude.

---

off topic? :D Proper Processing is proper programming.

Listen to me, NIC1 sends out a packet to NIC2 on Tx, the hub receives it and fires the same packet off to NIC1,2,3,4,5,6,7,8 on Rx all at the same time, thus the term 100BaseTx ethernet, it is a dumb simple electronic device.

A switch on the otherhand is different, with NIC1 adding NIC2's MAC address to the Ethernet header, it allows the switch to determine what port NIC2 is connected to via its internal MAC table.

They do two completely different things and that is why switches are a hell of a lot more efficent at dealing with heavily congested networks.

"I worked on Scalible Link Interface hardware even before T1 came into existance"
I'm sure you did considering its an nVidia patiented technology. Graphics technology before T1 consisted of a VGA controller and the CPU doing Bitblt processing. You're not kidding anyone.

"nVidia didn't invent GPUs."
Wow really?

And yes, you're completely off topic in every way possible.. I started this thread discussing how software developers are failing end users by bogging down their systems with crap software which doesn't tap the potential of their hardware. You've went on an SMP vs. DMP rampage and complete distorted the flow of discussion.

Quote:

---

Originally Posted by aidanjt

Listen to me, NIC1 sends out a packet to NIC2 on Tx, the hub receives it and fires the same packet off to NIC1,2,3,4,5,6,7,8 on Rx all at the same time, thus the term 100BaseTx ethernet, it is a dumb simple electronic device.

---

Yes, one data stream at a time broadcasting everywhere (one data stream to all points).

Quote:

---

Originally Posted by aidanjt

A switch on the otherhand is different, with NIC1 adding NIC2's MAC address to the Ethernet header, it allows the switch to determine what port NIC2 is connected to via its internal MAC table.

---

Yes, one data stream to all MAC addresses (one data stream to all points), or multiple different data streams to and from multiple different MAC addresses (point-2-point).

Quote:

---

Originally Posted by aidanjt

They do two completely different things and that is why switches are a hell of a lot more efficent at dealing with heavily congested networks.

---

More efficient because it can do more than one data stream at a time, multiple connections simultaneously (point-2-point). Or it can function as a hub by sending one data stream at a time everywhere (one data stream to all points).

Quote:

---

Originally Posted by aidanjt

I'm sure you did considering its an nVidia patiented technology. Graphics technology before T1 consisted of a VGA controller and the CPU doing Bitblt processing. You're not kidding anyone.

---

nVIDIA trademark is "SLI", they can't patent "Scalable Link Interface", it's decades old technology already. Examples of "Scalable Link Interface" hardware - T1, T2, T3, HyperTransport, PCI-Express, 10/100 Ethernet, Fibre-Channel, USB, FireWire, DVI, etc....

Quote:

---

Originally Posted by aidanjt

And yes, you're completely off topic in every way possible.. I started this thread discussing how software developers are failing end users by bogging down their systems with crap software which doesn't tap the potential of their hardware. You've went on an SMP vs. DMP rampage and complete distorted the flow of discussion.

---

Did I not mention the nearly complete ignorance of proper processing? Hence the lack of proper programming, for example...

"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."

Shouldn't this be moved to the Software dev thread?

Dougal, I don't think so, because im focusing on the failure to exploit CPU technology. That our pockets belovenly empty out for new kit. Though if a forum moderator wishes to move the thread thats fair enough.

Nein, you're off topic because your trying to claim one certain arch type is better than another, both have their merits.. Application software doesn't concern itself with one multi-processing layout to the next. It only needs to have a parent thread and worker threads, the kernel and hardware architecture takes care of the rest.

And no, multipule data streams can be sent out from a hub at the same time. Ethernet uses two pairs to reduce collisions, the nature of ethernet allows for multipule streams because of its packet based nature.. Switches only behave like a hub when the Ethernet header doesn't have a recipient MAC address.. its not the same as processing architecture.

Can we keep to the topic please?

Quote:

---

Originally Posted by aidanjt

Dougal, I don't think so, because im focusing on the failure to exploit CPU technology. That our pockets belovenly empty out for new kit. Though if a forum moderator wishes to move the thread thats fair enough.

---

Yep, failure to comprehend and use CPU properly is about right.

Quote:

---

Originally Posted by aidanjt

Nein, you're off topic because your trying to claim one certain arch type is better than another, both have their merits.. Application software doesn't concern itself with one multi-processing layout to the next. It only needs to have a parent thread and worker threads, the kernel and hardware architecture takes care of the rest.

---

You are off topic because you are too ignorant to be on topic.

Quote:

---

Originally Posted by aidanjt

And no, multipule data streams can be sent out from a hub at the same time. Ethernet uses two pairs to reduce collisions, the nature of ethernet allows for multipule streams because of its packet based nature.. Switches only behave like a hub when the Ethernet header doesn't have a recipient MAC address.. its not the same as processing architecture.

---

Ah... PLEASE NOT AGAIN. I am not ignorant enough to claim a switch can not broadcast to all points just as a hub could, and broadcasting to all points is the only thing a hub could do.

Quote:

---

Originally Posted by aidanjt

Can we keep to the topic please?

---

I am on topic, ignorance of processing is common and no programmer can do their job right if they didn't have much of a clue.

You're calling me ignorant, and you have produced a flawed network annalogy, continuing this DMP vs SMP debate.. SMP distributes threads, if a kernel supports CPU affinity (like Windows NT, linux, bsd, and other kernels do) a task can be asigned to one particular CPU that isn't loaded, AMD's cpus still operate on a threading model, a multi-threaded application works on both. Reread what I said, kernel and hardware arch takes care of thread distribution. This is fact, application level software doesn't need to interface with the arch. End of discussion, now can we get back to the problem at hand, please!

Quote:

---

Originally Posted by aidanjt

You're calling me ignorant,

---

I didn't call you ignorant, you talked like an ignoramus, acted like an ignoramus, insisted on being an ignoramus.

Quote:

---

Originally Posted by aidanjt

and you have produced a flawed network annalogy

---

I am not the one claiming a switch can not broadcast like a hub.

Quote:

---

Originally Posted by aidanjt

, continuing this DMP vs SMP debate.. SMP distributes threads, if a kernel supports CPU affinity (like Windows NT, linux, bsd, and other kernels do) a task can be asigned to one particular CPU that isn't loaded, AMD's cpus still operate on a threading model, a multi-threaded application works on both. Reread what I said, kernel and hardware arch takes care of thread distribution. This is fact, application level software doesn't need to interface with the arch. End of discussion, now can we get back to the problem at hand, please!

---

Distributed Processing and Symmetric Processing needed not be "Multi", only when multiple processors are in use then "Multi" applied.

A single processor can perform Symmetric Processing (Time-Share/Time-Division Processing), it is how Intel's processors normally fuction... just as a single processor can perform Distributed Processing.

please avoid the insults folks.

FWIW I think software does seem to lag a few years behind hardware , but is that because the development platforms themselves are out of date ?

Muti-processing is defined when there are two or more cores doing processing, regardless of packaging.. Weither the work is done in a distributed (parallel) or symmetric (serial) mannor is completely irrelivent in the scope of mutli-threaded software applications. Ethernet is a serial signaling communication medium btw, not parallel.

post edited - I'm sure you didn't want to keep insulting each other after my warning :)

Moby-Dick, yes, there is a lot of truth in what you say, however the tools and methods to leverage current hardware exist. I think developers these days think libraries should do everything for them and not give a toss weither or not their application bogs down people's systems.

It depends on your defenintion of a developer - If you are contructing an application from "building blocks" then you have to have faith in those blocks and routines. Knowledge of the next layer down isn't nessesary for you to do the job in hand.

Its likes going down from code to chip level , from chip level down to individual logic gate level , and from there down to transistor level and from there down to fabrication process and dopant levels in the substrate.

yes indeed, however practically every C/C++ compiler allows access to assembly routines to allow you to use SIMD instruction sets, and there is plenty of threading libraries around to deal with that issue as well. Library abstraction might be good in a sense that you don't balls up the system, but that is what debugging is for. The tools exist. Unfortunatly they just aren't being commonly used.

Note: thanks for the edit, I didn't intend to rant at users by starting this thread.

Quote:

---

Originally Posted by aidanjt

Muti-processing is defined when there are two or more cores doing processing, regardless of packaging.. Weither the work is done in a distributed (parallel) or symmetric (serial) mannor is completely irrelivent in the scope of mutli-threaded software applications.

---

No wonder why programmers can not do their job properly.

Quote:

---

Originally Posted by aidanjt

Ethernet is a serial signaling communication medium btw, not parallel.

---

It is a "Scalable Link Interface" which originated from Distributed Processing (Distributed Bandwidth). Unlike "Bus Interface" which is Symmetric Processing (Time-Share/Time-Division) design.

Bus Interface = one data stream at a time design, time division based, maximum data clock rate in one huge time slice is indicative of performance (Single-Tasking).... Hence their rating is the same as all Symmetric Processing designs which is the clock frequency.

Link Interface = multiple data streams design, bandwidth based hence usually rated by a designation standing for the bandwidth throughput rather than clock frequency for example T1, T2, T3, 10/100 Ethernet, PCI-Express - 1x 2x 8x 16x, etc...

If multi-processing architecture governs how a software application should be coded, give us one single example.

I think you're getting network transmission mediums confused with toptology, you can scale up a network with extra hosts, but you can't scale extra Cat5 cables to a NIC, Ethernet doesn't 'stream' data, a NIC fragments IP packets and sends them sequentally within Ethernet frames one at a time, thus making it serial. It makes the apearance of sending multipule 'streams' to the computer because it transmits squentually, but this is all hardware abstraction performed by drivers.
Ethernet does not make 2 transmissions at the same time, this is impossible as Ethernet transmits on a set eletrical voltage in binary, it does not trasmit on different frequencies, my telephone/adsl line does, but ethernet does not..

Just as bus signaling can only do one thing at a time.. even AMD's CPUs can only pass one bit at a time between end points.. you can't change the laws of physics.

Quote:

---

Originally Posted by aidanjt

If multi-processing architecture governs how a software application should be coded, give us one single example.

---

Do you know the difference of Symmetric Processing from Symmetric Multi-Processing? One used a single processor while the other used more than one.

Do you know the difference of Distributed Processing from Distributed Multi-Processing? One used a single processor while the other used more than one.

Quote:

---

Originally Posted by aidanjt

I think you're getting network transmission mediums confused with toptology, you can scale up a network with extra hosts, but you can't scale extra Cat5 cables to a NIC, Ethernet doesn't 'stream' data, a NIC fragments IP packets and sends them sequentally within Ethernet frames one at a time, thus making it serial. It makes the apearance of sending multipule 'streams' to the computer because it transmits squentually, but this is all hardware abstraction performed by drivers.
Ethernet does not make 2 transmissions at the same time, this is impossible as Ethernet transmits on a set eletrical frequency in binary, it does not trasmit on different frequencies, my telephone/adsl line does, but ethernet does not..

---

Please stop. You can't even comprehend your hubs and your switches clearly.

Quote:

---

Originally Posted by aidanjt

Just as bus signaling can only do one thing at a time.. even AMD's CPUs can only pass one bit at a time between end points.. you can't change the laws of physics.

---

All processing can be done in simple linear time domain within a period of time (Symmetric Processing - Single-Thread optimum), or that time duration period can be converted to a spectrum of channels (MAC = Media Access Channel) for processing within that time period (Distributed Processing - Multi-Threaded optimum).

You should learn some Calculus or if you did then please learn to use and to apply it properly.

Nein , I dont expect to have to warn people a 2nd time.

You are not impressing anyone with your posting style , particularly me.

stop it.


now.

This is a bit OT, but does anyone have any good links on writing software for multiprocessor systems? Im gonna be doing a fair bit of intensive simulation for my masters project, and if i can take advantage of my housemates X2 to get it done, then all the better

*sigh* that didn't answer the question, and MAC stands for Media Address Control, every NIC has an individual MAC code, its a hexidecmal number, it has nothing to do with transmission. I will no longer reply anymore incoherent and invalid statements.

PrivatePyle.. yes, you're absolutely correct, RAD is needed to prevent the cost of development from getting out of hand. But my point is this, imagine you're working on an application that works on huge ammounts of data, say a video editing program. You're not going to code it in Visual Basic are you?
No, of course not, you'd use C or C++, further more, most people who edit video have SMP systems, if you don't mutli-thread your application you wont use their other CPU cores. If you fail to use SIMD instructions scanning through video frames will be slow and tiresome. Furthermore, if you make your own video codec and don't use threading and SIMD instructions, encoding the video stream will take several hours longer.

Developers need to use the right tools for the job, not stick exclusively with one particular development enviroment they are acustomed with.

herulach - this gives you a basic overview of what you need to do:
http://www.cswl.com/whiteppr/white/multithreading.html

If you're going to use VC++/MFC to do your project search for CWinThread on MSDN.

hahaha, my deepest appologies.

Quote:

---

Originally Posted by StormPC

Oh I see. Well I can't really argue the point that software people are keeping up with hardware. They aren't. In fact, it seems that the faster computers get the more inept programmers become, simply because they can. They are dealing with virtually unlimited storage and memory, and incredible processor and graphics card performance. They simply do not need to be as good as programmers used to be.

And just about everyone knows why servers use Intel more often than AMD. It's pretty much the same reason more people use Celeron than A64. Nothing complicated, just marketing.

---

The problem with idiot-proofing to make things easier and simpler is that it also made for even more idiots. All you can get usually are wannabe experts. Can't get many real programmers anymore, there are few of them sprinkled in a pile of wannabes.

Quote:

---

Originally Posted by StormPC

The new X2 will stomp most Xeon dualies at almost everything. The dual-core Opterons are so much more powerful than anything Intel has to offer. Does it matter? No, because most IT Networking types know squat about hardware.

---

Ha ha.. I met quite a few IT Networking "experts" myself, it is funny that a graphic hardware guy like me had to tell them what "crossbar" was for nearly a year, even more hilarious with "Scalable Link Interface".

The whole Internet is a humongous Distributed Processing design, supporting point-2-point, non-uniform access, simultaneous multiple data streams from multiple sources to multiple destinations.

Where the hell did all the internet experts go? Do they wanted the internet to be a symmetric Processing design? All users should wait for acess in their own processing time slice duration? All servers running software which knew little differences of Single-tasking from Multi-Tasking.

Quote:

---

Originally Posted by aidanjt

herulach - this gives you a basic overview of what you need to do:
http://www.cswl.com/whiteppr/white/multithreading.html

If you're going to use VC++/MFC to do your project search for CWinThread on MSDN.

---

Itll be fortran probably ( i know, i know, but its physics, you cant get away from iit) But ill be doing it in VS .NET, so i can write the main bits in whatever i like, just fortran dlls

In the context of .NET and windows XP as a target system, do i need to do anything other than multithread to take advantage of more than one processor core?

Quote:

---

Originally Posted by herulach

In the context of .NET and windows XP as a target system, do i need to do anything other than multithread to take advantage of more than one processor core?

---

I don't have any fortran experience myself. But no, so long as the program impiments threads the kernel will take care of allocating threads between the two cores. You'll learn more as you go along testing code.

Quote:

---

Originally Posted by herulach

Itll be fortran probably ( i know, i know, but its physics, you cant get away from iit) But ill be doing it in VS .NET, so i can write the main bits in whatever i like, just fortran dlls

In the context of .NET and windows XP as a target system, do i need to do anything other than multithread to take advantage of more than one processor core?

---

Would you accept optimization advice from a hardware guy (not a programmer)?

Nein as you can't keep you ego to yourself I think you should take 24 hours to think about how not to irritate people so much.

Sorry I've had to close the thread folks. It just seems that inspite of warnings , people can't discuss things without making snide comments to each other.