A64 vs Core 2: 64-Bit Performance

[XmagusX]

So unless you either finally show us a benchmark that clearly shows that there is a processor out there that outperforms the top-end Core 2 processor consistently in x64 benchmarks and is publically available, or an Intel document that says "While we could easily have made the x64 of the Core 2 more powerful, even with our limited resources, we decided not to for marketing reasons", I have a hard time believing you.

I am done with this thread, since it's getting to the point that this forum was in ~3-4 months ago, where people were arguing about how unreleased product A was going to outperform unreleased product B based on the rumors about both products' features. I am not in the mood to keep asking for proof when all people are providing is speculation with a complete disregard for facts.

*Chuckles* You're funny. It really doesn't take more than a few moments thought and perhaps a couple drops of common sense. Intel wants to make money off of Itanium. They cannot do this if Core2 outperforms Itanium in 64bit at a lower cost, as no one would have any reason whatsoever to buy Itanium at that point. In this way, Core2 is handicapped by needing to be a poorer performer than Itanium in 64 bit otherwise Intel loses an entire product line. AMD, on the other hand, has no such hampering since their chips are all based on the same technology, so the better they can make AMD64 perform, the better it is for all of their product lines.

Next logical question: does this mean that AMD will eventually come out with chips that will smash Core2 to little itty bitty bits? Answer: no one !!!!ing knows. But for the moment, Intels are faster. Which, again, was the entire point of this thread, if I recall correctly.

Additionally, an astute observer might notice this pattern: Intel chips trump AMDs, but AMD slowly becomes a more and more real competitor to Intel, producing chips of comparable speed at lower cost; Intel lowers the cost of their chips to compete; AMD comes up with a chip that trumps Intel; Intel drops the prices of their chips to compete; Intel comes up with a chip that trumps AMD; AMD drops the prices of their chips to compete ... etc, etc, ad nauseum, ad infinitum. So what can we probably expect? Chips designed by AMD to outperform Core2 and a subsequent price drop on Intel chips. My only problem with this is that there aren't more companies vying for the top spot to drive prices down and speeds up faster. I blame our bicameral electoral system for infecting people with the notion that having more than two choices is a bad thing. The weenies.

So the question then becomes do you want to wait for those chips, buy current performance king, or buy the recently dethroned king on the cheap? And that's a question everyone will have to answer for themselves, as each of us has different priorities when it comes to building our new system.

 

[LstBrunnenG]

*Chuckles* You're funny. It really doesn't take more than a few moments thought and perhaps a couple drops of common sense. Intel wants to make money off of Itanium. They cannot do this if Core2 outperforms Itanium in 64bit at a lower cost, as no one would have any reason whatsoever to buy Itanium at that point. In this way, Core2 is handicapped by needing to be a poorer performer than Itanium in 64 bit otherwise Intel loses an entire product line. AMD, on the other hand, has no such hampering since their chips are all based on the same technology, so the better they can make AMD64 perform, the better it is for all of their product lines.

I see your logic, but the only "proof" I've seen of this are scattered musings from The Inquirer. Seeing as they sit around and make fun of Itanium all day like it's their job, I'd hardly consider them a reliable or unbiased source. I mean, nobody posting in this thread works at Intel. For all we know, Intel could be dropping the Itanium line tomorrow.

Next logical question: does this mean that AMD will eventually come out with chips that will smash Core2 to little itty bitty bits? Answer: no one !!!!ing knows. But for the moment, Intels are faster. Which, again, was the entire point of this thread, if I recall correctly.

Which is exactly why it's true that while this is an interesting topic to discuss, we don't need a flame war over it.

We both can agree that EMT64 is crippled compared to AMD64, and we both agree that it was a buisness decision.

My problem with your argument lies with this statement. If Intel has crippled Conroe's EMT64, it's been crippled relative to Itanium, not any current implementation of AMD64. To borrow Mangus's analogy, you're basically saying that the 6800nu is crippled relative to the Voodoo5. It's crippled relative to 6800 ultra, but it owns the Voodoo with half its RAM tied behind its back.

 

[XmagusX]

I see your logic, but the only "proof" I've seen of this are scattered musings from The Inquirer. Seeing as they sit around and make fun of Itanium all day like it's their job, I'd hardly consider them a reliable or unbiased source. I mean, nobody posting in this thread works at Intel. For all we know, Intel could be dropping the Itanium line tomorrow.

True enough, and as I stated, my point was and is based on the supposition that Intel wants to make money off of Itanium. If that ceases to be the case and Intel devotes all their resources to making Core2 (or Conroe's rumored successor, "Woodlands") their all-encompassing überchip, then I would agree that at that point Core2 would cease to be crippled. On that note, I would like to point out that one can only be crippled relative to one's own self. As per dictionary.com,
tr.v. crip·pled, crip·pling, crip·ples

1. To cause to lose the use of a limb or limbs.
2. To disable, damage, or impair the functioning of: a strike that crippled the factory.

Agreeing that the chips have no limbs to lose, that means that if they are crippled, their functionality must be somehow impaired. As there is an economic advantage to keeping Core2 chips from outperforming Itaniums (again, based on the supposition that Intel wants to make money of that product line), Core2 is crippled. AMD64 has no such internal competitor, and therefore is not crippled. Not relative to one another, relative only to themselves. The current Intels nonetheless spank the current AMDs despite their being crippled in this way.

To borrow Mangus's analogy, you're basically saying that the 6800nu is crippled relative to the Voodoo5. It's crippled relative to 6800 ultra, but it owns the Voodoo with half its RAM tied behind its back.

Again, I agree; something can't be crippled relative to another thing, only to it's self. In my analogy, the 6800nu is crippled, the Voodoo5 is not. The Voodoo5 is nonetheless outperformed despite its not being crippled. To suggest that EMT64 is crippled relative to AMD64 is folly. It's simply the case that EMT64 is crippled whereas AMD64 is not. It means that AMD64 has a better chance of catching up than it would were EMT64 not crippled by Itanium, and that's pretty much it. It doesn't mean that AMD64 will catch up, just that it has a better shot than it would otherwise.

And to this day I have no clue why people like putting the letter "n" in my nick. Heh.

 

[drizzt81]

*Chuckles* You're funny. It really doesn't take more than a few moments thought and perhaps a couple drops of common sense. Intel wants to make money off of Itanium. They cannot do this if Core2 outperforms Itanium in 64bit at a lower cost, as no one would have any reason whatsoever to buy Itanium at that point. In this way, Core2 is handicapped by needing to be a poorer performer than Itanium in 64 bit otherwise Intel loses an entire product line. AMD, on the other hand, has no such hampering since their chips are all based on the same technology, so the better they can make AMD64 perform, the better it is for all of their product lines.

Assuming that I believe the whole "Intel had excess resources" idea. If that truly was the case, why not use these idle assets on Itanium instead? In the end, if you argue that Intel had the means to make Core 2 an Itanium killer, then they arguably had the resources to make Itanium that much better than what Core 2 ended up being.

So, let's follow your idea of "we'll cripple Core 2 for Itanium." What do companies that buy Itanium care about? Benchmarks!
From Spec.org:
Dell Worstation with Core 2 SPECfp_base2000 = 2872
Itanium 2 Machine SPECfp_base2000 = 3098

Appears awefully close for Core 2 to be crippled, does it not? In fact, Core 2 beats the itanium at quite a few tests.

 

[LstBrunnenG]

To suggest that EMT64 is crippled relative to AMD64 is folly. It's simply the case that EMT64 is crippled whereas AMD64 is not. It means that AMD64 has a better chance of catching up than it would were EMT64 not crippled by Itanium, and that's pretty much it. It doesn't mean that AMD64 will catch up, just that it has a better shot than it would otherwise.

Exactly. That's why it irks me to hear teh f@ns say "EMT64 is crippled on conroe! It can't run 64-bit code worth crap! Go AMD!" Point 1. is in serious doubt, and point 2. does not follow from point 1. and happens to be completely false. And it's all used as an excuse to get to point 3. by any means necessary.

 

[The DarkBlade]

Does anyone have numbers for 64-bit between A64 and C2D in a Linux system? That's far more interesting to me. I suspect the A64 would be faster. Before you label me a !!!!!!, I just dumped my A64 for a C2D....

 

[savantu]

Only one with reading problems can claim K8>Conroe regarding the gain from 32->64.

Normal people can quickly see :

-Conroe has a bigger gain in 6 tests
-K8 has a bigger gain in 5 ( 6 with ScienceMark )
-in 5 tests they are equal

In other words : there is no difference in what they gain in average from 32 to 64bit.Only in some scenarios you'll find one making a leap over the other , but overall they are balanced.

What's the fuss ?

 

[Vette5885]

OK... I see what you're arguing....but why? What is your goal?

We know what has been summarized OVER and OVER and OVER again.

[slow]--^v^v^---------------------------------------[AMD32]-------[AMD64]----------------[Conroe32]--[Conroe64]-----[FAST]

So what if AMD64 over AMD32 has a bigger improvement than Conroe64 over Conroe32? Conroe is still faster.

Isn't it possible that Conroe32 is SOOOO good at 32-bit that it is almost as fast as the current generation of 64-bit?

Plus, both chips are designed differently. AMD is better than Intel at certain functions (and vise versa). Well, isn't it possible for AMD64 functions to be better than Intel64 functions (and vise versa)? AND if it is possible, who cares?

 

[coldpower27]

Plus, both chips are designed differently. AMD is better than Intel at certain functions (and vise versa). Well, isn't it possible for AMD64 functions to be better than Intel64 functions (and vise versa)? AND if it is possible, who cares?

The problem with this is that somehow that if indeed the K8 has a better X86-64 implementation then Core Architecture it somehow makes it a better product then Core 2.

The problem with this as we have explained multiple times in this thread, is that even with the added imrpovements of 64 bit performance Windsor is still behind Conroe in performance, the margin is reduced a tad, but Core 2 still reigns supreme nonetheless.

As well we can also argue for desktop application the majority share still remains 32Bit performance, we can wait for Intel's Nehalem and AMD's 45nm K8L Quad Cores before this becomes a real issue.

 

[savantu]

...
So what if AMD64 over AMD32 has a bigger improvement than Conroe64 over Conroe32?

The point is simple : the above isn't true.

 

[Scali2]

What amazes me is that I posted this thing here, and on various other forums: http://www.hardforum.com/showthread.php?t=1149750

But I've not found any results from Athlons or Opterons in 64-bit anywhere.
I did run it on a Pentium D and a Core2 Duo, and the Pentium D got a considerable gain in 64-bit, Core2 Duo was marginally faster.

I wonder if all these people on all these forums just don't run a 64-bit OS on their Athlons or Opterons, or if they were embaressed to post their 64-bit results.

 

[duby229]

It wouldnt build for me in X64 XP

Though, I run a 64bit Linux system, as my main rig. If you ever decide to port it to Linux, I'll be glad to test it for you.

 

[Scali2]

It wouldnt build for me in X64 XP

That excuse is just not good enough.
I assume you bothered to read the whole thread and read the remark about the VC++ redist required for OpenMP?
That's the only known 'problem', I've not had anyone report a problem after they bothered to install the VC++ redist (ofcourse you need the *proper* one, there's one for x86 and one for x64).
Would be very suspicious if it didn't work on your Athlon specifically.

 

[duby229]

I'm not going to spend that much time corrupting my install, so that I can run your biased benchmarks.

Like I said, if you ever decide to port it to Linux I'll be happy to test it for you. Otherwise I'm just not interested enough to pursue it...

Is that excuse good enough?

 

[Scali2]

No, that's an insult.
First of all you're not 'corrupting' your install by installing Microsoft's VC++ runtime distribution (my software doesn't need an installation, it can be executed straight from the rar-file).
Secondly, it's not a benchmark.
Thirdly, it's actually written on an Athlon XP 1800+. If it is biased at all, it is biased towards an Athlon XP, because that was my main machine at the time of optimizing this code.
If you think it's biased, prove it. Provide a disassembly with an analysis of what parts would be biased and why.

Lastly, I don't see a reason why I should port it to linux.

Anyone else with an Athlon or Opteron willing to run it in XP x64?
Gotta be someone out there who's able to run it and not afraid to post results. I need to know.

 

[duby229]

Twist and wiggle....

 

[Donnie27]

No, that's an insult.
First of all you're not 'corrupting' your install by installing Microsoft's VC++ runtime distribution (my software doesn't need an installation, it can be executed straight from the rar-file).
Secondly, it's not a benchmark.
Thirdly, it's actually written on an Athlon XP 1800+. If it is biased at all, it is biased towards an Athlon XP, because that was my main machine at the time of optimizing this code.
If you think it's biased, prove it. Provide a disassembly with an analysis of what parts would be biased and why.

Lastly, I don't see a reason why I should port it to linux.

Anyone else with an Athlon or Opteron willing to run it in XP x64?
Gotta be someone out there who's able to run it and not afraid to post results. I need to know.

Rubs grubby hands together, I have a 3500+, want me to test it?

 

[Scali2]

Rubs grubby hands together, I have a 3500+, want me to test it?

If you have XP x64 or Vista x64, sure.
I really like to know how AMD performs in 64-bit mode, and I'd need 32-bit numbers from the same machine to compare, ofcourse (running the 32-bit binary in the x64-OS should be good enough to get a clear idea).

 

[Donnie27]

If you have XP x64 or Vista x64, sure.
I really like to know how AMD performs in 64-bit mode, and I'd need 32-bit numbers from the same machine to compare, ofcourse (running the 32-bit binary in the x64-OS should be good enough to get a clear idea).

Sorry, I don't have XP64

 

[drizzt81]

Lastly, I don't see a reason why I should port it to linux.

A possible reason would be your previous statement that implies that you'd like to get some results from an A64 based system in a native x64 environment.

What amazes me is that I posted this thing here, and on various other forums: http://www.hardforum.com/showthread.php?t=1149750

But I've not found any results from Athlons or Opterons in 64-bit anywhere.

There's the reason you should port it to Linux. I'd run it on my Opty 165 (Debian Etch x64) for you as well, but I am not going to bother installing XP x64 and the OpenMP libraries in a VM just to run one benchmark.

 

[Moofasa~]

Doesn't work out of the box with Vista x64, and I'm too lazy to install anything else to make it work. Sorry.

 

[merlingt1]

I just ran it on my C2D @ 3.4GHz on X64 using the default GPU settings with my lowly 7600GT and got the following

Min: 359
Max: 518
Average: 430 (but it is very hard to tell because it is bouncing all over the place)

I wish it had an FPS logging feature. Also it is only using about 75% of both cores.

 

[Scali2]

A possible reason would be your previous statement that implies that you'd like to get some results from an A64 based system in a native x64 environment.

Except it already runs in Windows x64.

There's the reason you should port it to Linux. I'd run it on my Opty 165 (Debian Etch x64) for you as well, but I am not going to bother installing XP x64 and the OpenMP libraries in a VM just to run one benchmark.

Trust me, porting to linux is a whole lot more work.
Besides, the code is being used in Windows, not linux. I don't need linux for anything, but I do need a Windows version.

 

[Scali2]

Doesn't work out of the box with Vista x64, and I'm too lazy to install anything else to make it work. Sorry.

You mean you don't want to prove to everyone in this thread that AMD indeed gets a good performance boost in 64-bit, and puts Core2's crippled 64-bit mode to shame?
Too bad, this would be a wonderful opportunity.

 

[duby229]

You mean you don't want to prove to everyone in this thread that AMD indeed gets a good performance boost in 64-bit, and puts Core2's crippled 64-bit mode to shame?
Too bad, this would be a wonderful opportunity.

I dont think your "application" is capable of doing that. Claiming that it can is just plain wrong. Like in a moral sense, its wrong.

 

[LstBrunnenG]

Enough, both of you. I don't want to see this thread locked because you two can't get over yourselves.

As of right now, the numbers say that Conroe trounces K8 in 64-bit as well as 32-bit, albeit by a smaller margin in 64-bit mode. What does this bickering contribute?

 

[Scali2]

Well, I just want someone to *finally* give me Athlon64/Opteron results on my code.
I like to have a complete overview of how my code performs on various architectures, and work around any limitations if necessary.
duby may not believe this, but I am completely unbiased, and I don't want any brand to perform better than the other, I just want my code to run as fast as possible on as many architectures as possible.
And then I want to know which architecture gives me the best absolute performance in this algorithm, so I know which hardware I can recommend for this task.
Getting this routine to run as fast as possible is the goal, the brand of the CPU that does this is not important, at least, not to me.

 

[Scali2]

I dont think your "application" is capable of doing that. Claiming that it can is just plain wrong. Like in a moral sense, its wrong.

I have no idea what my application is capable of on an Athlon64, nobody has ever told me any results.
However, since the code gives huge improvements on Pentium D, and reasonable improvements on C2D, I'll assume the Athlon64 will get some kind of improvement in 64-bit aswell.

In the case it doesn't, we have to figure out why and see if the code can work around it.
But until I get results, I won't know anything.

 

[Scali2]

Anyone? Geez, come on!

 

[Martyr]

why the amd has big gains, the intel doesnt, and why this proves the intel is the better chip.



all it takes is a change of perspective. lets say 64 bit is the standard, mkay?

then the amd take a big performance hit, and the intel takes a small performance hit. what would we say if this is the case? we would say the amd has poorly implemented 32 bit instructions, and the intel has well implemented 32 bit instructions.





put that in your crack pipe and smoke it

 

[coldpower27]

why the amd has big gains, the intel doesnt, and why this proves the intel is the better chip.



all it takes is a change of perspective. lets say 64 bit is the standard, mkay?

then the amd take a big performance hit, and the intel takes a small performance hit. what would we say if this is the case? we would say the amd has poorly implemented 32 bit instructions, and the intel has well implemented 32 bit instructions.



put that in your crack pipe and smoke it

This has been discussed a million times over.

AMD MAY have better implemented 64Bit Extensions, but this is not anywhere close enough to normalize the lead Core 2 has on Athlon 64. Instead of leading substantially in 64Bit Mode, Intel leads largely in 64Bit Mode. The fact of the matter is, Intel still leads anyway.

By the time 64Bit applications become the norm, Athlon 64's and likely even Core 2 will be old processors, so it will be pretty moot.

 

[Scali2]

Well, as it turns out, I just got some results from an Opteron on my application, and it indeed wasn't faster in 64-bit than 32-bit. See here: http://www.hardforum.com/showthread.php?t=1149750

 

[duby229]

Well, as it turns out, I just got some results from an Opteron on my application, and it indeed wasn't faster in 64-bit than 32-bit. See here: http://www.hardforum.com/showthread.php?t=1149750

Anybody who is surprised raise your hand.....

 

[Scali2]

I take such accusations very personally.
You are directly insulting my integrity as a person.
I suggest you either come up with some solid proof, or keep your mouth shut.

You can't just go around and insult people personally when their hard work doesn't jive with what you want to see in your little biased world.

 

[LstBrunnenG]

Okay. I'll bite. What's your side of this, Duby? You saying he used the -suckonAMD compiler switch?

 

[Scali2]

Apparently I also used the -rockonPentium switch.
Now I'm sure there must have been a good reason to make this basically obsolute architecture look good... but I can't recall it. Can you refresh my memory, duby?

 

[duby229]

Okay. I'll bite. What's your side of this, Duby? You saying he used the -suckonAMD compiler switch?

This is what scali said in response to someone else.... This suggests that he thinks his application is the end all be all of performance monitoring. Take his results and it'll give you an absolute value of truth....

You mean you don't want to prove to everyone in this thread that AMD indeed gets a good performance boost in 64-bit, and puts Core2's crippled 64-bit mode to shame?
Too bad, this would be a wonderful opportunity.

Then this is what he said a few minutes ago about the results from a result he got from an AMD system in 64bit mode.....

Well, as it turns out, I just got some results from an Opteron on my application, and it indeed wasn't faster in 64-bit than 32-bit. See here: http://www.hardforum.com/showthread.php?t=1149750

As I said earlier, I dont think Scali's program is capable of proving anything, outside of his coding. If his program doesnt scale in 64bits, then that is strictly the limit of his program. Claiming otherwise is foolish.

 

[Scali2]

As I said earlier, I dont think Scali's program is capable of proving anything, outside of his coding. If his program doesnt scale in 64bits, then that is strictly the limit of his program.

This goes for all applications, so I don't see why you should use that as an argument against mine in particular. I think everyone here pretty much already knows that every application you benchmark only gives results for that particular application (and ofcourse all other applications with a similar design).
However, if all applications show a similar pattern, what do you say then?

Other than that, my program scales fine in 64-bit, especially on Pentiums. It's just the AMD that's the odd one out. Now how do you explain that?

 

[duby229]

This goes for all applications, so I don't see why you should use that as an argument against mine in particular. I think everyone here pretty much already knows that every application you benchmark only gives results for that particular application (and ofcourse all other applications with a similar design).
However, if all applications show a similar pattern, what do you say then?

Other than that, my program scales fine in 64-bit, especially on Pentiums. It's just the AMD that's the odd one out. Now how do you explain that?

Easy, your program.

I'm not dissing you coding skills in any way... But you yourself have said that it was never tested on an AMD64 system. Which makes it plainly clear that it wasnt designed with an AMD64 system in mind.

As such making the point that it doesnt scale on AMD64, and then prodding someone for not testing it on AMD64 is ignorant at best.

 

[Donnie27]

why the amd has big gains, the intel doesnt, and why this proves the intel is the better chip.

all it takes is a change of perspective. lets say 64 bit is the standard, mkay?

then the amd take a big performance hit, and the intel takes a small performance hit. what would we say if this is the case? we would say the amd has poorly implemented 32 bit instructions, and the intel has well implemented 32 bit instructions.

put that in your crack pipe and smoke it

As Tech Report put it. AMD64 gains more than some cases and don't in others. Even when it gains, it's still slower. In some cases instead of being 20% slower it's now 17% slower. Cinebench and ScienceMark kept their shoot out from being a total slaughter. The Intel Chips is the better chip since it launched, just as the X2 was better than the P4, big deal.

Poorly implemented? Holding back for Itanium and etc.. is just a bunch of Horse Scheisse IMHO. Proof you say? Using the AMD gains more theory, so far the absolute best implementation of X86-64 goes to; Drum roll please?, the Lowly P4D. It gained more that both the Athlon64 and C2D. The Irony of Ironies is that it still gets spanked even after those gains LOL!

So this not wanting to accept AMD's currently getting spanked is kind of lame. Doesn't mean AMD sucks because their fast processors aren't as fast as Intel's fast processors geeeeessh!