First Tunisia, then Tahoe?

As a slightly off-topic but important sidenote, I thought it would be appropriate to let everyone know how AMD wanted this review to happen, and how certain folks within AMD were champions for the right cause and made it actually happen.

AMD knew it wouldn't be able to trounce Core 2 with Phenom, especially not at 2.3GHz, so it wanted to control the benchmarking that was done on Phenom. For the first time in as far as I can remember, AMD wanted all benchmarking on Phenom to be done at a location in Tahoe, of course on AMD's dime. AMD would fly us out there, we would spend a couple of days with a pre-configured system and we'd head home to write our stories.

Now I championed for this sort of early-access to Phenom months ago. I've visited AMD alone three times this year primarily to talk about Phenom, and each time I left without being able to report so much as a single benchmark to you all (everyone remembers those articles right?). I tried and tried to get AMD to part with some early Phenom data, because they were losing the confidence of their fan base and that's a sad thing to see for a company that really took care of this community when we needed it most.

After Tahoe AMD would eventually sample Phenom parts so we could test in our own labs, but there was no word on exactly when that would be. Chances are you would've seen a handful of numbers here today if we had gone to Tahoe with a full review of the chip hitting sometime in December.

Needless to say, I wasn't happy. I refused to go to Tahoe.

Don't get me wrong, a free trip to Tahoe is a wonderful thing, but Phenom deserved better. It deserved dedicated testing, it deserved a thorough review, not a quick glance over a couple of days. And I had a feeling that you all would agree. The time for AMD-sanctioned testing expired months ago, if Phenom was launching this week, we were going to have a proper review of it.

These days, AMD seems to be learning a little too much from the ATI way of doing things. If AMD had its way, today's Phenom review would have been done from beautful Lake Tahoe, on a system that AMD built, running at a frequency that isn't launching. Now there's nothing wrong with allowing us to preview Phenom under closed conditions, after all, Intel does it, but that's simply not acceptable for a review of a product that's four days away from being in stores. You all want to see a thorough review of Phenom, not some half-assed preview, definitely not after waiting this long for it.

An AMD rep, familiar with the Tahoe trip, asked me, somewhat surprised, "what, Intel doesn't work like this?".

Sorry to say, Intel doesn't. Today Intel let us preview the Core 2 Extreme QX9770 processor, do you want to know how they did it? The FedEx guy dropped off a chip. No flights to Tahoe, no hotel rooms, no expenses at all. Don't get me wrong, I felt like an idiot turning down a free trip to Tahoe, but it was for AMD's own good. We've all seen the financials, these aren't times to be wasting money on silly trips around the country, it costs less than $30 to ship a CPU and that's all we need.

I get the point of Tahoe, it's to control the benchmarking, making sure we wouldn't be comparing a 2.4GHz Phenom to a 3.0GHz Penryn, but honestly folks - would we really do that to begin with? And I get the idea to wine and dine the press, with hopes of more pleasant reviews with better relationships - but this isn't a product to toy with. We're here to do our jobs and that is to review the product that will carry AMD for the next twelve months, and honestly we can't do that from some lodge somewhere away from our testbeds.

This isn't the first time AMD has heard of this from me, and there are many within AMD who feel the same way. The reason you're finding this rant in here today is because I am concerned for the future of the company. Competition is a good thing, we need to keep it around, but AMD needs to learn from its competitors. Intel and NVIDIA don't try things like this, business is always first with them, frivolous pleasures come next.

To AMD: if you want to be Intel, start acting like it.

Intel Responds with...really? Socket-AM2+, Not So Positive?
Comments Locked

124 Comments

View All Comments

  • Proteusza - Monday, November 19, 2007 - link

    Actually, there is every possibility that he is right.

    First off, how much do you know about instruction sets and compilers? I'm going to assume nothing. If you do know something, then consider this for the edification of other readers.

    Compilers take code written in one language and produce an output in another. Specifically, compilers take code written in a language that can be easily understood by humans (ie C++) and output code that a machine can understand (machine code, or bytecode in the case of a JVM).

    Now, the problem with enhanced instruction sets, like SSE4, and SSE4.1 and SSE4a, is that they require compiler support. Imagine an instruction set as a vocabulary. And compilers are the programs that produce books, using a specified vocabulary. Now, the simple truth is that Intel makes extra effort to get its vocabulary into use. Thus, Cinebench was most likely compiled with Intel's latest vocabulary, and not AMD's.

    So, part of the K10 update was that it allowed SSE operations to be completed much faster, and I'm presuming this requires the use of its new instruction set. If so, that means that Cinebench was basically running in K8 mode.

    Not so far fetched, just means AMD has to make sure people update their code. The instruction set issue is another reason why RISC CPU's are generally simpler and faster.
  • JumpingJack - Monday, November 19, 2007 - link

    Look... it is code, that is all ... AMD and Intel are both designing to the same code base, run it on one... then run it on the other... which is faster?

    Architectural jargon of IMC and victim L3 cache, and x-bit look up ... if it doesn't work it doesn't work.
  • Kiijibari - Monday, November 19, 2007 - link

    Lol .. just code ... imagine a guy talking in a south west Chinese dialect to you. You do not understand anything ? Well .. it is just a language ... ;-)

    No offense intended: Please do some read up on compliers and programming languages .. it is interesting :)

    cheers

    Kiiji
  • Brunnis - Monday, November 19, 2007 - link

    Acutally, there shouldn't be any code modifications needed to make use of the new SSE functionality. The difference is internal to the CPU, meaning that it now processes SSE instructions without splitting them. The instructions used are the same as before.

    That said, there may be untapped potential in the CPU that can be uncovered by the use of a different compiler (due to other reasons). Though, as far as I know, Intel compilers often produce faster code even for AMD CPUs...

    About the "architectural advantage" Anand mentioned: Of course the Core 2 has an architectural advantage. It's pretty obvious from the fact that it performs faster, clock-for-clock, in almost all cases while having much higher frequency potential. Not even AMD's integrated memory controller can raise the computational efficiency of their CPU enough to really challenge Intel. AMD may have a more elegant external design and interface to the rest of the system (native quad, HyperTransport, integrated memory controller), but Intel obviously has the more refined internal design. Sadly for AMD, a computational advantage seems to weigh heavier than a neat system/core interface in this case.
  • Kiijibari - Monday, November 19, 2007 - link

    quote:

    Acutally, there shouldn't be any code modifications needed to make use of the new SSE functionality. The difference is internal to the CPU, meaning that it now processes SSE instructions without splitting them. The instructions used are the same as before.
    Yes I know what you mean, the SSE instructions are the same, they are just executed faster (in 1 clock compared to 2 clocks before). That is correct, however I wonder how much code is out there that is compiled with the old Intel compilers until 9.X.

    The problem with these compilers were, that they did not executed the SSE2 codepath on AMD chips, even if the CPU would have been capable of executing it. Instead a slower FPU code is used for AMD K8s.

    The newest Intel 10 Compilers have now new compiler flags that can generate SSE2 code for non-intel CPUs, however I did not have seen benches of these so far.

    Even the M$ Compiler had some nasty SSE disable "features":
    http://einstein.phys.uwm.edu/forum_thread.php?id=6...">http://einstein.phys.uwm.edu/forum_thread.php?id=6...

    All in all, I guess there are a lot of programs out there that disable SSE on AMD CPUs :( Therefore a plain compile test of several open-sorce prgorams with gcc / Sun / Pathscale compilers would be nice. Intel CPUs could be benched with Intel compiler, too, any CPU should gets it best code.

    cheers

    Kiiji
  • Kiijibari - Monday, November 19, 2007 - link

    Yet another wise guy knowing nothing ...

    Lets imagine an English native speaker ... would he understand Spanish ? No, not much ... but maybe his fried, who learned Spanish in school is better in speaking Spanish, nevertheless, he wont be as good as a native Spanish speaker ...

    Who would be the guy with the "superior, best language capabilities" now? The Spanish, the English speaking guy, or his friend ?

    Think about it a little bit I am curious about your reply ^^

    cheers

    Kiiji
  • MrKaz - Monday, November 19, 2007 - link

    “AMD couldn't simply get enough quantities of the Phenom at 2.4GHz to have a sizable launch this year (not to mention a late discovery of a TLB error in the chips),…”

    I’m very interested in the bug you talked Anand.
    Could you say if you know how it affects the CPU:
    -Performance?
    -Clock speed?
    -Slow northbridge clocks?
    Or the bug no longer exists in these CPUs?


    Complete disappointment.
    At least AMD release the 790 motherboards so I can at least put my old CPU on that system with two Ati 3850 cards… ;)
  • Spoelie - Monday, November 19, 2007 - link

    The bug freezes the system at high workloads. It shouldn't have any performance impact.

    I'm extremely disappointed with phenom, I was planning to get the entire spider platform for my yearly upgrade cycle, but that seems to be a bad idea.
  • fitten - Monday, November 19, 2007 - link

    quote:

    The bug freezes the system at high workloads. It shouldn't have any performance impact.


    I would think that transitioning from a running, working system into a brick (not running and not working) would be a fairly significant performance impact ;)
  • Viditor - Monday, November 19, 2007 - link

    quote:

    I'm extremely disappointed with phenom, I was planning to get the entire spider platform for my yearly upgrade cycle, but that seems to be a bad idea


    I'm waiting for the review on Quad-Crossfire first...
    I figure I can get 4 x 3850s for about the same price as an 8800 Ultra. The question is, is it worth it?
    If XfireX is good, then I will pull the trigger on 4 x 3850s (or 3870s if I can get them before Xmas), a 790FX mobo, and probably a Phenom 9500...
    Then I'll upgrade the Phenom in March when the B3s finally come out.

Log in

Don't have an account? Sign up now