What architecture you are using?

[Xordan]

Originally posted by neme5i5
\"So it would be correct to state that em64t/ia32e is an implementation of amd64.\"

Yes, exactly what I said.

You\'re reaching. I said nothing about the technology. Which in this case is amd64 (x86_64 as gcc calls it).

EM64T is buggy in 64bit, and AMD64 runs like dogs.

No, you definately mentioned the technology. But w/e, we both agree that AMD processors perform better than Intels in most cases, although not as bad as you made out. You can really only see the difference in a benchmark, and it certainaly doesn\'t crash all the time. I\'m just pointing out that you can\'t blame one bit of technology. It\'s what the rest of the processor does with that technology which effects how the processor performs overall, not how that technology performs.  If Intel had a onboard memory controller and something similar or the same as hypertransport then maybe the performance would be similar in all cases.

[neme5i5]

Runs like dogs. You open the gate, and they scream FREE as the run around the block pissing on poles! Also I said, runs like stalions.

I said nothing about the technology. My comment was on my chips here. I like how you slip your position around to avoid admitting your statments were obviously wrong. In the future if you\'re unclear about something plz ask.

Since you seem to want to know so bad. As for the technology. ANYTHING based on any successor to the i386 (i486 i586 i686 x86 x86_64 amd64 em64t ia32e) is pure dung. I don\'t care if it has gotten 64bits.

I liked IA64 (VLIW/EPIC) before it was implimented. It\'s still got some promise if they can ever realize it. (HP\'s book is a fun read) Alphas are the best, hands down. I like POWER (power optimised with enhanced risc) as a fine grained 64bit chip. (also the PPC970) Mips isn\'t bad either. I like high powered chips, and lots of GP registers.

[Xordan]

Originally posted by neme5i5
Runs like dogs.

Where I\'m from that means it runs like crap I wasn\'t unsure at all, we just meant complete opposites. And I was assuming we were talking about technology, as that\'s what was posted. Obviously another misunderstanding there.

Anyway....

IA64 - Very nice imo, although it hasn\'t really gone anywhere. Lack of native IA32 support let it down (although it can run IA32 now if I recall using a IA32 module.), and I don\'t think it will go anywhere now due to lack of general consumer need. It had its chance and didn\'t make it.

I\'m not sure about Alpha (Lack of experience there.), but PPC is a definate yes for a good processor. The best supercomputers run on PPC (See BlueGene/L).

As for your dislike of i386 processors... well definatly the amount of registers was a big \'bad\' for x86, but it seems to have pulled through because it was needed for program compatibility. And AFAIK, amd64 isn\'t based on i386 (correct me if I\'m wrong there), but a new design with backwards compatibility. If someone can come out with something much better which is compatible with x86(_64) which will become mainstream then go for it.

What do you think of Cray btw?

[neme5i5]

TMK IA64 is the very first VLIW processor. That is what made it cool. FYI it was never designed for consumer use.

(1) Sadly, it\'s why I use x86 as well. (2) Yes, you\'re wrong. ...again. (3) You miss the point x86 its self is dung. Even sparc (ugh) is better. Here\'s another reason to embrace only free software. It makes mass arch migrations trivial.

I almost bought a Cray vector machine from a recycler.

[Xordan]

TMK IA64 is the very first VLIW processor. That is what made it cool. FYI it was never designed for consumer use.

It was designed for server or scientific useage which then would be expanded into consumer usage. Intel wanted to make it the mainstream 64-bit processor but didn\'t manage it. Read this in some court case legal document for a lawsuit between AMD and Intel.

Yes, you\'re wrong. ...again.

Wasn\'t wrong the first time. To a third party anyway....
So why is there a degrade in 32-bit performance on amd64? Surely it would perform the same or better than 64-bit if it was based around a 32-bit design?

(3) You miss the point x86 its self is dung

Maybe, but then it\'s cheap compared to alpha. The price for performance of the x86 design is much less than alpha, which keeps alpha sales down. Alpha may have a great design compared to x86, but it isn\'t practical for the general consumer environment. And it\'s practicality which matters, not how well something is designed.

[neme5i5]

(IA64) You\'re right, it would have gone there in time. Like IBM\'s PowerPC line.

Your always free to believe what ever you want. You chose to ignore relavent commentary all along the way that would have betrayed your chosen view. Reality is perceptual.

\"... I was assuming we were...\"

As you said to me assumptions make you look foolish.

(performance) they added registers. Big performance boost for 64bit code. (32bit design) nope. Think of any amd64 (Athlon64 Opteron) running 32bit, as a old Athlon with a die shrink, and an integrated memory controller + Hyper Transport. Depends on what market you\'re in. Consumer hardware is not well suited to scientific applications. Alphas ruled there, as does Itanic today.

[Xordan]

(performance) they added registers. Big performance boost for 64bit code. (32bit design) nope. Think of any amd64 (Athlon64 Opteron) running 32bit, as a old Athlon with a die shrink, and an integrated memory controller + Hyper Transport.

hmm, but it runs 32-bit code worse than its 32-bit sempron counterpart does. The extra registers shouldn\'t account for an actual performance degrade on 32-bit code.

[neme5i5]

Read what I said, and what I did not.

(BTW, parting note: Allot of amd64 chips require registered RAM (even in 32bit) great for servers like mine , but bad for over all perfomance. Read with a careful eye on what metrics can influence your results. Chip model, what kind of RAM, remember PC333 was faster than PC400. People seem to have forgotten all of this when the Opteron was released)

Look it\'s been fun, really. I have even more fun arguing with a member of my team over the Pentium M. I\'m getting bored teaching you about semiconductor theory/design. I suggest you go read up on it some more.

Good luck, and have fun.

[Leeloo]

Originally posted by neme5i5
TMK IA64 is the very first VLIW processor. That is what made it cool. FYI it was never designed for consumer use.

That\'s just marketing. It\'s not the first, nor VLIW.

It\'s a RISC processor with explicit parrallel instructions (EPIC), where as VLIW goes the opposite way of RISC. VLIW is a russian invention, and I read a quote somewhere from the russians that invented it that Intel doesn\'t understand what VLIW is. And their (the russians who invented it) processor was working before Intel even tried to copy the idea.

IA64 is just PA-RISC on stereoids. It\'s even supposed to be backwards compatible, so if you want to run HP/UX, go ahead. You might need a mainboard that HP/UX knows about though.

[neme5i5]

Thank you for adding to my knowledge, I didn\'t know that. Have any names, or links for me to read about it?

http://www.cs.clemson.edu/~mark/epic.html
http://www.cs.clemson.edu/~mark/architects.html

Some one should break this news to David K Every.

http://www.mackido.com/Hardware/EPICisRISC.html

[Leeloo]

Unfortunately I don\'t have any links.

I read the last of your links though, and as he explains, IA64 is RISC. What is missing, and what Intel apparently missed is that VLIW goes the opposite way from RISC. Well, not completely missed, because I belive they did talk about the fact that they were going the opposite way of RISC back when IA64 was still vaporware.

You have them ordered RISC - CISC - VLIW, with CISC in the middle. IA64 and PA-RISC being Risc, x64 is CISC and that russian thing is VLIW. Risc is about making the CPU simple (simple instructions are faster), CISC makes it complex (complex instructions do more work per instruction), and VLIW is supposed to be on the opposite side of CISC, but details are lacking Well, if even Intel don\'t understand it, how would I?

The explicit parralel thing is called EPIC, and there is nothing new in that. Microcode always worked something like that, even the examples given in my old Tannenbaum book from 1995 (that\'s before IA64 as far as I know). It\'s just another thing that has been moved from the chip to the compiler, making it even further out on the RISC end.

[neme5i5]

Oh I see where your argument is going. Scheduling is usually done in software, like the new one we got in 2.6. VLIW is moving this on the hardware.

OTOH I would still consider VLIW RISC. Let me explain why. Part of what makes CISC is the instructions are of variable length. This is really all that is left that differentiates CISC from RISC architechtures. I want to add something to your iconography first.

RISC CISC VLIW

The new processors we call RISC are in fact more complicated than CISC every will be. So let\'s say we take the good points of both RISC & CISC, and we make a modern RISC (MRISC) w/ OoO execution, superscaler, DSP, SIMD, and other like technologies. They really fly in the face of the old RISC philosophy.

Now from that we add scheduling to the chip, and we now have where VLIW was going. Can you see my argument?

[Leeloo]

Originally posted by neme5i5
Oh I see where your argument is going. Scheduling is usually done in software, like the new one we got in 2.6. VLIW is moving this on the hardware.

No, that\'s wrong. The EPIC (still nor VLIW, Intel doesn\'t know what VLIW is) idea is that pipelining, like in the P4, where several instructions can be executing at once (instructions of the SAME thread/process, this is not hyperthreading), is done differently. On a P4, the CPU needs all kinds of locking to prevent one instruction from using a value before the previous instruction is done computing that value. On EPIC this job is moved to the compiler, which will group instuctions together, telling the CPU \"these can be executed at the same time without problems\". Much faster, because the CPU doesn\'t have to wait for the value to be calculated, it knows that none of the other instructions executing at the same time will try to use that value.

OTOH I would still consider VLIW RISC. Let me explain why. Part of what makes CISC is the instructions are of variable length. This is really all that is left that differentiates CISC from RISC architechtures.

Some CISC architechtures have variable length instructions, but this is no requirement. The difference between RISC and CISC is microcode, a piece of code embedded inside the CPU. This code actually interprets the instruction set on CISC processors. RISC processors don\'t have microcode.

EPIC is RISC. VLIW is something different.

I want to add something to your iconography first.

RISC CISC VLIW

The new processors we call RISC are in fact more complicated than CISC every will be. So let\'s say we take the good points of both RISC & CISC, and we make a modern RISC (MRISC) w/ OoO execution, superscaler, DSP, SIMD, and other like technologies. They really fly in the face of the old RISC philosophy.

The RISC philosophy was to take out anything that can\'t be done directly in hardware, and leave it to the compiler instead of having microcode. Microcode is really just software, although etched into the CPU. Software is slow, hardware is fast. Getting rid of microcode will speed up everything that can be done by the hardware, because it doesn\'t need to be interpreted first. And leaving the rest to the compiler will not slow anything down, because it\'s still software at the same level.

[neme5i5]

I think you\'re confused. Not only does RISC not have microcode, neither does anybody else who makes CISC based chips. The only CISC to use microcode is from Intel. All CISC implimentations use variable length instructions. One RISC characteristic is non-variable instruction length which speeds up execution. An example of VLIW implimentation is Transmeta\'s Crusoe. (w/o the codemorphing software which is NOT microcode)

url:http://www.transmeta.com/crusoe/vliw.html

I wasn\'t talking at all about EPIC anymore. RISC as a philosophy is no longer being used. Even the POWER5 while being called RISC is more like my argument for calling it \"Modern RISC\", and in that light moving scheduling into the instruction set is the next step on that path.

I was talking about VLIW, and from what I read scheduling was put into the instuction set. (hardware) Also the whole RISC philosophy was lets use multiplication as an example. In RISC you would have no instruction for multiply, instead the programmer would need to do multiple loops of adds to achieve this result. In CISC you would just use the multiply instruction. Now \"Modern RISC\" chips have evolved so far out of this that they are adding SIMD instructions. If you follow this out even further with OoO execution, adding instruction for scheduling is not hard to imagine. Therefore VLIW is RISC, but not in the old context since not even POWER5 is RISC in the old context.

BTW scheduling != hyperthreading && hyperthreading == subset of scheduling

[Leeloo]

Originally posted by neme5i5
I think you\'re confused. Not only does RISC not have microcode, neither does anybody else who makes CISC based chips.

Then they wouldn\'t be CISC.

The only CISC to use microcode is from Intel. All CISC implimentations use variable length instructions.

This wouldn\'t make sense, as fixed-length would be faster, depending on how long the instrucitions need to be. but with current 32 and 64-bit CPUs, there should be bits enough to have a fixed length instruction set without having to fetch multiple words.

The only reason that x86 is variable-length is that it\'s an 4/8/16 bit design, and when you fetch only 8 bit at a time, it\'s better only to fetch the number of bytes necessary. On a 64-bit CPU this wouldn\'t make sense, no matter if it\'s RISC or CISC.

One RISC characteristic is non-variable instruction length which speeds up execution. An example of VLIW implimentation is Transmeta\'s Crusoe. (w/o the codemorphing software which is NOT microcode)

url:http://www.transmeta.com/crusoe/vliw.html

I don\'t have much knowledge about the transmeta processors, and definitely not enough to know if they understood VLIW, unlike Intel.[/QUOTE]

I wasn\'t talking at all about EPIC anymore. RISC as a philosophy is no longer being used.

Just about everything is RISC nowadays, except x86.

I was talking about VLIW, and from what I read scheduling was put into the instuction set. (hardware)

That wouldn\'t make sense at all. Switching the scheduler would imply replacing the chip then. Windows has one scheduler, which is good for some things, and sucks for others, FreeBSD has a completely different scheduler, and Linux 2.6 has several to choose from.

Also the whole RISC philosophy was lets use multiplication as an example. In RISC you would have no instruction for multiply, instead the programmer would need to do multiple loops of adds to achieve this result.

Depends on which chip you\'re talking about. I think either MIPS or Sparc had multiplication in hardware, although I don\'t remember which.

Now \"Modern RISC\" chips have evolved so far out of this that they are adding SIMD instructions. If you follow this out even further with OoO execution, adding instruction for scheduling is not hard to imagine. Therefore VLIW is RISC, but not in the old context since not even POWER5 is RISC in the old context.

You don\'t understand RISC, and I don\'t think you understand VLIW either (but since I don\'t, I can\'t really judge on that). If you do understand VLIW though, you should explain to Intel why IA64 has nothing to do with VLIW.