Linked by Thom Holwerda on Tue 24th Jan 2006 16:58 UTC
Hardware, Embedded Systems Yesterday, we reported on an article about the demise of the Alpha. That article was the first part in a series about the future of processor design. Today, part II has been published: "In terms of the architecture itself, AMD's Athlon 64 platform, at the stage it is at right now, does not offer that much of a performance advantage, and AMD should not be resting on its laurels. This is because on the desktop, interconnects as such play less of a role. It's on servers and multi-processing systems that you can take advantage of scaling, and that's where interconnects such as HyperTransport have a role. But when you talk about a single-chip desktop system, whether it's one, two or four cores, the efficiency of the chipset still plays a very important role."
Thread beginning with comment 89212
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[2]: Arrogant Article
by edwdig on Wed 25th Jan 2006 08:36 UTC in reply to "RE: Arrogant Article"
edwdig
Member since:
2005-08-22

I disagree: x86 is bad, and little crufty is understating: compare SSE vs Altivec for example.

SSE wasn't that great, but SSE2 and SSE3 are pretty good. AltiVec seems to be slightly faster, but SSE3 is more flexible in both operations and datatypes.

From ease-of-use point of view: its use of low-endian makes hard to read hex dump of memory, low number of register, not-orthogonal ISA...

Big endian makes it easier to stare at a random memory dump and figure out what's going on. Little endian makes code simplier as it makes it simplier to do things like treating an int as a short or a char. It's not something you'd directly notice unless you program in assembly, but it does tend to result in smaller code.

x86 instruction density can be matched by RISCs as ARM's Thumb2 have shown (Thumb had a performance impact, I don't know if it's still the case with Thumb2).

I don't know anything about Thumb2, but Thumb certainly sucked. The only time it made any sense was if your hardware couldn't provide a 32 bit memory interface, and even then you were still better off using ARM for certain things.

Reply Parent Score: 1

RE[3]: Arrogant Article
by renox on Wed 25th Jan 2006 12:37 in reply to "RE[2]: Arrogant Article"
renox Member since:
2005-07-06

Does SSE3 has a multiply-accumulate operation?
I remember that it was missing in previous version.

Little endian simplifies some assembly language trick, big endian simplifies other assembly language trick, I'm not sure that there is really a benefit of little endian for the assembly language programming here, but human read in big endian and this is a big difference.

What do you say that Thumb sucked? Because of the performance impact?
Anyway I've not said Thumb but Thumb2 where you can mix 32 and 16 bit instructions.

Reply Parent Score: 1

RE[4]: Arrogant Article
by nimble on Wed 25th Jan 2006 13:34 in reply to "RE[3]: Arrogant Article"
nimble Member since:
2005-07-06

Little endian simplifies some assembly language trick, big endian simplifies other assembly language trick, I'm not sure that there is really a benefit of little endian for the assembly language programming here, but human read in big endian and this is a big difference.

OMG, I can't believe people are still beating that particular dead horse.

The differences between the two approaches are so small that the choice is really only a matter of taste, and that's of course why we ended up with the industry split down the middle on that one.

The supposed advantages of either approach are laughable compared to the huge disadvantage of having to deal with both of them in heterogenous settings.

Reply Parent Score: 1

RE[4]: Arrogant Article
by nimble on Wed 25th Jan 2006 15:37 in reply to "RE[3]: Arrogant Article"
nimble Member since:
2005-07-06

Does SSE3 has a multiply-accumulate operation?

No, because x86 does not allow for three-operand instructions. There is a multiply-add instruction for two 16-bit integer vectors, but that's not the same.

Therefore multiply-accumulate requires separate multiply and add instructions. Whether that actually has a performance impact depends on what execution units there are and how the operations are scheduled. Anyone got experience with that?

Reply Parent Score: 1