AMD accuses BAPCo and Intel of cheating with Sysmark benchmarks

[ivan134]

it's has to be priced above the 4690K around the 4790K which is 339.99 USD maybe even above that reaching close to the 5820K that the only way i see it. but if they do it which i highly doubt good,but they are taking a lost on it which isn't good for them.

Mental gymnastics lvels over 9000.

[Morgan MLGman]

How are they going to get haswell level 6 core & actual 6 core not that BS they did with FX & 8 core cpu priced below skylake without taking a lost, because the CEO said they're are tired of being know as the cheaper solution & AMD is not in a place to be taking losses. Now intel can which would put AMD in a bad spot. 

They moved from the architecture with the modules to the one Intel uses. If they're going to offer 6 and 8 cores at a competitive price provided it really has IPC of Haswell or a little higher, I see no reason they fail. But they need to deliver first and price those CPUs reasonably and carefully.

[Marinatall_Ironside]

They moved from the architecture with the modules to the one Intel uses. If they're going to offer 6 and 8 cores at a competitive price provided it really has IPC of Haswell or a little higher, I see no reason they fail. But they need to deliver first and price those CPUs reasonably and carefully.

Yeah since AMD is now using SMT over their previous CMT solution, which the latter has proven to be an inferior multithreading solution compared to SMT (AKA HyperThreading)

[Morgan MLGman]

Yeah since AMD is now using SMT over their previous CMT solution, which the latter has proven to be an inferior multithreading solution compared to SMT (AKA HyperThreading)

I couldn't recall the names, that's what I meant though. Well, CMT was good at multithreading, where it failed spectacularly was single-threaded power, the architecture has some critical flaws (although it's not as bad as people make it to be, you can game perfectly fine on an FX CPU, I already proved that and can do it anytime)

[Marinatall_Ironside]

I couldn't recall the names, that's what I meant though. Well, CMT was good at multithreading, where it failed spectacularly was single-threaded power, the architecture has some critical flaws (although it's not as bad as people make it to be, you can game perfectly fine on an FX CPU, I already proved that and can do it anytime)

True.

[Demonking]

Mental gymnastics lvels over 9000.

How ? unless you know a way they can sell these below current haswell CPU's & make a profit don't reply to me again. 

 

They moved from the architecture with the modules to the one Intel uses. If they're going to offer 6 and 8 cores at a competitive price provided it really has IPC of Haswell or a little higher, I see no reason they fail. But they need to deliver first and price those CPUs reasonably and carefully.

I find it hard that they can make a profit off them with lower prices than current haswell CPU that will still be for sell when Zen releases.

[Morgan MLGman]

I find it hard that they can make a profit off them with lower prices than current haswell CPU that will still be for sell when Zen releases.

I find it hard to believe that Haswell will still be in active production by the time Zen arrives.

Besides, provided they can supply the demand, they can make up for the low price with quantity, remember how the market works, it's business, they know what to do better than me or you

[Marinatall_Ironside]

...they know what to do better than me or you

Well better than any of us quite frankly. Unless people have taken one or two marketing classes.

[ivan134]

How ? unless you know a way they can sell these below current haswell CPU's & make a profit don't reply to me again. 

 

I find it hard that they can make a profit off them with lower prices than current haswell CPU that will still be for sell when Zen releases.

Deflection levels over 9000.

You gave a nonsensical response and are trying to shift the onus on me to explain the nonsense you just came up with. According to you a theoretical 6core/6thread CPU would cost the same as a 6core/12thread CPU because...............reasons.

[Morgan MLGman]

Well better than any of us quite frankly. Unless people have taken one or two marketing classes.

I'm quite familiar with the basics of how market and law work (went to a school that favored those things) and I have to tell you that people have no idea how deep marketing goes and how bad are they being manipulated by those companies

[HalGameGuru]

CMT was a fine and dandy tech, AMD's implementation was garbage. They cut corners and made some bad decisions, but CMT can and will be a fine tech for CPU's in the future.

 

 

 

 

[Sakkura]

& a 5820K is $389 USD without an igpu, so tell me how are they going to do that for less than the 5820K without taking a lost, because i don't see it. The last thing AMD needs to to be selling cpu's at a lost. Corners will have to be cut in order to get a 6 core haswell level IPC CPU  for less than a 4690K.

 

Haswell is 22nm. Now the process nodes aren't directly comparable, but AMD should get significantly higher areal density at 14nm.

 

Also, the 5820K is a cut-down SKU. The full-featured Haswell-E costs a thousand dollars.

[Demonking]

Deflection levels over 9000.

You gave a nonsensical response and are trying to shift the onus on me to explain the nonsense you just came up with. According to you a theoretical 6core/6thread CPU would cost the same as a 6core/12thread CPU because...............reasons.

Because they're not using the same methods they used with FX, that was a cheaper solution this isn't and will in fact cost more than the msrp of the 8350 which was $200. So excuse me for not expecting a $200 6 core cpu with the ipc of around haswell.

[Demonking]

I find it hard to believe that Haswell will still be in active production by the time Zen arrives.

Besides, provided they can supply the demand, they can make up for the low price with quantity, remember how the market works, it's business, they know what to do better than me or you

vendors will still have and at the very least the used market will, even within the 1st year of haswell you could still get ivy Cpu's on newegg.

[Sakkura]

Because they're not using the same methods they used with FX, that was a cheaper solution this isn't and will in fact cost more than the msrp of the 8350 which was $200. So excuse me for not expecting a $200 6 core cpu with the ipc of around haswell.

 

The FX-8350 has a die size of 315mm². Haswell (quad core with iGPU) is 177mm². Haswell-E (8-core) is 356mm². Given the smaller process node, AMD would be in a much improved situation. With a straight doubling of planar density, and assuming Zen cores (as well as IMC etc) are exactly the same size as Haswell cores, an 8-core (no iGPU) would be 178mm². Ie. they could, in theory, sell an 8-core version at prices comparable with a Core i7-4790K. A cut-down 6-core version at Core i5 pricing would then be reasonable.

 

But that's all very, very speculative.

[Tomsen]

Intel didn't push Maxon to use it. Go ahead and look back over the case. Maxon used it of their own recognizance. Intel made it perfectly clear in the documentation from the word go. That decision was BS, but it was bad press for Intel. Otellini and that entire C-Suite are gone. Intel is not the same company it was in 2004. Jesus people you ask to give Lisa Su a chance even though she herself cancelled the Beema tablets but you think Kirzanich is pulling the same illegal crap just because the company label is Intel? Get bent.

I have reliable data. I have all the exact clock latencies for Excavator courtesy of Agner Fog's documentation and AMD's x86 instruction manual. Assuming the 40% IPC gain is right (and they will fall short as they always do; let's be honest here), then the absolute best they could do is 3% better than Haswell. An integer linear program is a proven optimizing program. I can be 100% confident in my claims because the data and methods are solid. This is the difference between a scientist and a charlatan. I can actually do the work.

Nope. We know the counts, the width, the IPC gain claim, and much more. We also know exactly which instructions are supported. After that it's merely a matter of data input to QEMU to get a virtual CPU and running benchmarks on a virtual Windows 7 instance for the bulk of benches and Ubuntu 14.04 instance for Linpack.

Honestly it's not difficult, just tedious to automate.

Patrick, dont be that naive. Intel made nothing clear. They were trying to exploit a grey area. It is quite clear Intel have learned their lesson, they are not microsoft afterall, and not try to exploit grey areas and be open things. I doubt beema in tablet space would have failed. Not because of not been competitive in performance metric, but rather due to Intels contra revenue program.

No Patrick, that is by no means reliable data. IPC is no reliable number, as it is a product of both the microarchitecture and the executable/stimulations running. You have neither the microarchitecture detail or the executable to even try extrapolate on anything. You might be 100% confident in your "numbers", but don't be surprised if zen could be able to exceed haswell by atleast 4% in one way or another.

Tell me how much more we "know" patrick. Because at this point, we know almost nothing.

[patrickjp93]

Patrick, dont be that naive. Intel made nothing clear. They were trying to exploit a grey area. It is quite clear Intel have learned their lesson, they are not microsoft afterall, and not try to exploit grey areas and be open things. I doubt beema in tablet space would have failed. Not because of not been competitive in performance metric, but rather due to Intels contra revenue program.

No Patrick, that is by no means reliable data. IPC is no reliable number, as it is a product of both the microarchitecture and the executable/stimulations running. You have neither the microarchitecture detail or the executable to even try extrapolate on anything. You might be 100% confident in your "numbers", but don't be surprised if zen could be able to exceed haswell by atleast 4% in one way or another.

Tell me how much more we "know" patrick. Because at this point, we know almost nothing.

Oh FFS, IPC is a fixed number that is the average of the inverse of the instruction latencies across the ISA.

You have the microarch base of Excavator. After that it's tweaking numbers up and down and respecting theoretical limits and integrality. I'm talking about total IPC, not local IPC in a program, hence a wide array of benchmarks.

The executables are the existing benchmarks. The instructions are exactly the same between Zen and Broadwell anyway. No one's updated for any newer instructions.

[Tomsen]

Oh FFS, IPC is a fixed number that is the average of the inverse of the instruction latencies across the ISA.

You have the microarch base of Excavator. After that it's tweaking numbers up and down and respecting theoretical limits and integrality. I'm talking about total IPC, not local IPC in a program, hence a wide array of benchmarks.

The executables are the existing benchmarks. The instructions are exactly the same between Zen and Broadwell anyway. No one's updated for any newer instructions.

No, IPC is not a "fixed" number. IPC is workflow depended. No, you can't calculate the "total" or "local" IPC by doing the inverse of the average of the instruction latency. That doesn't even make any sense.

You have your base, but as I said, your numbers are by far not reliable enough to extrapolate anything on it.

You still haven't gotten the point? How do you know what AMD offered was "total" IPC and not "local" IPC? You don't. Even if so, you don't know how they obtained the numbers they did.

[patrickjp93]

No, IPC is not a "fixed" number. IPC is workflow depended. No, you can't calculate the "total" or "local" IPC by doing the inverse of the average of the instruction latency. That doesn't even make any sense.

You have your base, but as I said, your numbers are by far not reliable enough to extrapolate anything on it.

You still haven't gotten the point? How do you know what AMD offered was "total" IPC and not "local" IPC? You don't. Even if so, you don't know how they obtained the numbers they did.

IPC is instructions per cycle. It's the inverse of cycles per instruction, aka the instruction latency. The IPC of a processor is the average of the individual IPCs. It makes perfect sense. Part of my HPC class was IPC analysis.

I don't have to know how they derived their numbers. I can come up with the absolute best case scenario if that claim is true. That's the entire point of constraint satisfaction algorithms like integer linear programming. You're out of your league.

[Tomsen]

IPC is instructions per cycle. It's the inverse of cycles per instruction, aka the instruction latency. The IPC of a processor is the average of the individual IPCs. It makes perfect sense. Part of my HPC class was IPC analysis.

I don't have to know how they derived their numbers. I can come up with the absolute best case scenario if that claim is true. That's the entire point of constraint satisfaction algorithms like integer linear programming. You're out of your league.

IPC is the inverse of CPI for a given workflow, that is not what I'm arguing. I'm saying you can't calculate the average latency of an entire instruction set and extentions, then inverse it, and think you got a reliable "total" IPC. You also can't calculate the average latency of each individual instruction in a given executable, then inverse it, and think you can calculate the "local" IPC. That doesn't work, and doesn't make sense with modern processors that can execute multiple instructions concurrently, out-of-order and speculative execution.

Yes, you do. You can't come up with any reliable data from a simple marketing statement. Don't fool yourself, mister marketing-whisperer.

Patrick, I'm not going to argue any further with you regarding if your data is reliable or not. It isn't.

[patrickjp93]

IPC is the inverse of CPI for a given workflow, that is not what I'm arguing. I'm saying you can't calculate the average latency of an entire instruction set and extentions, then inverse it, and think you got a reliable "total" IPC. You also can't calculate the average latency of each individual instruction in a given executable, then inverse it, and think you can calculate the "local" IPC. That doesn't work, and doesn't make sense with modern processors that can execute multiple instructions concurrently, out-of-order and speculative execution.

Yes, you do. You can't come up with any reliable data from a simple marketing statement. Don't fool yourself, mister marketing-whisperer.

Patrick, I'm not going to argue any further with you regarding if your data is reliable or not. It isn't.

It is not limited to a given workload. A processor has its own overall IPC across all instructions. Yes you can. That is literally the starting point for bogomips. I spent two full semesters on this. You are wrong. My data is completely solid and so are the conclusions drawn from it. The absolute best Zen will do is 3% over Haswell per clock. It's not going to be any better than that, and in all likelihood it will be worse than that.

[Tomsen]

It is not limited to a given workload. A processor has its own overall IPC across all instructions. Yes you can. That is literally the starting point for bogomips. I spent two full semesters on this. You are wrong. My data is completely solid and so are the conclusions drawn from it. The absolute best Zen will do is 3% over Haswell per clock. It's not going to be any better than that, and in all likelihood it will be worse than that.

IPC is workload determined. There are no such thing as "total" IPC, because a processors performance vary with the workload. There are no determined ways to calculate one's "total"/"overall" IPC.

How is bogomips relevant in this discussion? It is completely irrelevant, as it is primarily affected by a single metric, and mostly unaffected by the rest.

How solid is your numbers, when AMD stated just yesterday:

"Zen"-based CPU development is on track to achieve greater than 40% IPC uplift from our previous generation

[patrickjp93]

IPC is workload determined. There are no such thing as "total" IPC, because a processors performance vary with the workload. There are no determined ways to calculate one's "total"/"overall" IPC.

How is bogomips relevant in this discussion? It is completely irrelevant, as it is primarily affected by a single metric, and mostly unaffected by the rest.

How solid is your numbers, when AMD stated just yesterday:

Which means 40% and change. In other words. IDC.

You can have a program-specific IPC as well as an overall one.

[Tomsen]

Which means 40% and change. In other words. IDC.

You can have a program-specific IPC as well as an overall one.

So, you don't care about how "solid" your data is.

One could define one's own method of calculating a processors "overall" IPC, but it would mean jack-shit as another method might yield totally different result. Which is why marketing like that terminology so much.

[JefferyD90]

Still don't understand why anyone puts any emphasis on benchmarks?  They are all like this.

 

I read this article as *Benchmarking software doesn't give real world performance metrics*...  And I have to think to myself, does anyone actually believe that in the beginning?

 

Edit: I am a AMD fan by nature, I feel like they push the industry forward more times than Intel does.  But, AMD is in the wrong here.  They should not have devoted ANY time and resources to benchmarks.  Its just the Ghz race all over again.  Quit focusing on benchmarks and just figure out ways to calculate programs better.  I don't care if my PC gets a score of .001 on a benchmark, as long as it does what I want it to do.