Fudzilla: Bulldozer performance figures are in

[StrangerGuy]

YABDBenchmark leak:

http://translate.google.com/transla...md-fx-8150-vermeintliche-benchmarks-geleaked/

 

[classy]

YABDBenchmark leak:

http://translate.google.com/transla...md-fx-8150-vermeintliche-benchmarks-geleaked/

Man will people read the many threads, these benchmarks have been posted numerous times, they are fake. The guy told everyone he faked them. They are fake.

 

[Edrick]

Man will people read the many threads, these benchmarks have been posted numerous times, they are fake. The guy told everyone he faked them. They are fake.

In the absence of any real information, people will believe anything they read, even if most know it is fake.

 

[podspi]

@looncraz: The X6 no longer clocks all cores the same. In fact, in order to get Turbo at least 3 cores have to be at 800mhz. I ran a few simple benchmarks a while back (Geekbench) and can confirm that Turbo works in singlethreaded benchmarks, even with Windows bouncing the threads around. I believe with Turbo AMD has decreased the time it takes to move between p-states. (Both up and down). I agree with you that I am afraid of the performance penalty when moving between modules, though. Hopefully (probably) with Windows 8 Microsoft is going to add the ability for Windows to recognize the p-state of various cores and schedule a little more intelligently, as well as other things like making it module-aware. IIRC, the Win scheduler is already hyperthreading aware, so this should be possible.

 

[alexruiz]

4. X264 is THE BEST encoder available. When looking at quality/speed it wins everytime, hands down. It has the ability to compete in speed with most of the faster encoders out there (what do you think all of its settings are for?).

I am curious as to what other ones you have used. Names appreciated. The reviews websites more often than not have no clue about encoders. And yes, this website is also one of them.

If you remember the Pentium 4 launch, one website (Tom's) focused his encoding tests on a virtually unknown program at the time (FlaskMPEG) to encode from DVD to MPEG4/DivX. In a matter of days, ALL the websites were using flask also... That same website used another little know program, TMPGEnc for MPEG2 encoding. TMPGEnc was very heavily SSE2 optimized. The P4 was an MPEG2 encoding monster in those tests. Guess what, then everyone else was also using TMPGEnc, and everyone was claiming that for encoding, the P4 was king.

Well, it happens that none of the reviews websites had a clue about encoders. TMPGenc was, even with SSE2 in a P4, one of the slowest encoders. Quality was ok, but it was slow. In a K7/K8 it was dog slow... but other encoders like Mainconcept or Canopus procoder were faster tha TMPGEnc, and ran equally fast on a P4 or K7/K8. Furthermore, the benchmark in MPEG2 encoders, CCE (Cinemacraft encoder) was much faster than TMPGEnc, and ran faster on a K7/K8.

Some of us who at the time were heavy in video encoding were bringing these findings to light (xVid also ran faster on a K7) here on the forums, placing emphasis that some programs ran better on AMd, while others did better on Intel, but little changed. The perception was that the P4 was the CPU to get for encoding duties...

I am curious if the situation is similar now. One website uses x264 and then, everyone else and their cousins run to use the same...


Alex

 

[Cogman]

I am curious as to what other ones you have used. Names appreciated. The reviews websites more often than not have no clue about encoders. And yes, this website is also one of them.

If you remember the Pentium 4 launch, one website (Tom's) focused his encoding tests on a virtually unknown program at the time (FlaskMPEG) to encode from DVD to MPEG4/DivX. In a matter of days, ALL the websites were using flask also... That same website used another little know program, TMPGEnc for MPEG2 encoding. TMPGEnc was very heavily SSE2 optimized. The P4 was an MPEG2 encoding monster in those tests. Guess what, then everyone else was also using TMPGEnc, and everyone was claiming that for encoding, the P4 was king.

Well, it happens that none of the reviews websites had a clue about encoders. TMPGenc was, even with SSE2 in a P4, one of the slowest encoders. Quality was ok, but it was slow. In a K7/K8 it was dog slow... but other encoders like Mainconcept or Canopus procoder were faster tha TMPGEnc, and ran equally fast on a P4 or K7/K8. Furthermore, the benchmark in MPEG2 encoders, CCE (Cinemacraft encoder) was much faster than TMPGEnc, and ran faster on a K7/K8.

Some of us who at the time were heavy in video encoding were bringing these findings to light (xVid also ran faster on a K7) here on the forums, placing emphasis that some programs ran better on AMd, while others did better on Intel, but little changed. The perception was that the P4 was the CPU to get for encoding duties...

I am curious if the situation is similar now. One website uses x264 and then, everyone else and their cousins run to use the same...


Alex

I, personally, have only ever used freely available encoders (x264, Xvid, etc). However, I have seen several, fairly reliable, reviews about quality comparisons between multiple H.264 encoders, MainConcept, Elecard, and DivX to name a few.

http://compression.ru/video/codec_comparison/h264_2011/mpeg-4_avc_h264_video_codecs_comparison.pdf

Should be a pretty good read if you really care about the quality of output from your encoder. Just realize that x264 has a myriad of settings. You can quite easily get it to spit out anywhere from 200fps to .2fps depending on what settings you use.

 

[sm625]

I practically tore my hair out trying to figure out why my 2600k would do strange things with turbo on a single thread. I ended up setting all my affinity's manually, and was able to eek out 5% better superpi scores doing that. But with BD the issue could be bigger than 5%. Hell for all we know these chips are capped at 1400MHz and the people doing the benchmarks might not even know it.

I assume anyone benchmarking BD would disable turbo and all power saving features and clock the cores at a constant speed. No 800MHz or 1400MHz crap at all. And they would make sure the benchmarks from that mode of operation match the benchmarks with CnQ and turbo enabled. This of course assumes the people doing the benchmarks are both competent and honorable, not hacks doing it for a free 2600k or whatnot.

 

[Cogman]

I practically tore my hair out trying to figure out why my 2600k would do strange things with turbo on a single thread. I ended up setting all my affinity's manually, and was able to eek out 5% better superpi scores doing that. But with BD the issue could be bigger than 5%. Hell for all we know these chips are capped at 1400MHz and the people doing the benchmarks might not even know it.

I assume anyone benchmarking BD would disable turbo and all power saving features and clock the cores at a constant speed. No 800MHz or 1400MHz crap at all. And they would make sure the benchmarks from that mode of operation match the benchmarks with CnQ and turbo enabled. This of course assumes the people doing the benchmarks are both competent and honorable, not hacks doing it for a free 2600k or whatnot.

Leaving standard features on is a valuable tool for benchmarking. Do you think that the average consumer is going to go through the trouble of tweaking and optimizing their settings towards a single program? Most likely not.

Heck, even enthusiasts aren't likely to go through and turn on/off everything to get a the best performance for their given program.

 

[Imouto]

Agree with Cogman, x264 is the best h264 encoder hands down. And it's open source and free.

 

[Tuna-Fish]

I am curious if the situation is similar now. One website uses x264 and then, everyone else and their cousins run to use the same...

No, there is a very good reason why everyone with any sense is using x264. Check out the table 9 on page 52 on cogman's link -- x264 is basically in a category all by itself when it comes to high-quality encoding.

 

[RussianSensation]

Things are getting more interesting every day:

Core i7-2700K 3.5ghz to cost $340-350, report suggests
http://techreport.com/discussions.x/21692

 

[Edrick]

Things are getting more interesting every day:

Core i7-2700K 3.5ghz to cost $340-350, report suggests
http://techreport.com/discussions.x/21692

I have no clue as to why Intel is releasing this CPU at this price at this time.

 

[Idontcare]

I have no clue as to why Intel is releasing this CPU at this price at this time.

"ASP Enrichment".

The only people who will be paying $350 for a 2700K are the same people who were going to buy a 2600K for $315 if the 2700K did not exist.

If 1 out of 10 prospective 2600K buyers opt to "upsize" their CPU to the 2700K that means an extra $35 for Intel (that's >10% more, huge gross margin increase).

So 9/10 2600K buyers stick with the 2600K, no loss to Intel there, and 1/10 pay more for the privilege of owning the 2700K.

And there's also the PR aspect.

If BD 8150 lands between 2500K and 2600K in benches then that can be spun as "BD is within spitting distance of besting Intel's flagship"...but if Intel's flagship is the 2700K then the 8150 may still fall between the 2500K and 2600K but the story then becomes "BD falls to a distant third place, not even coming close to challenging Intel's dominating performance lead".

But the pricing suggests this isn't about PR, its just your standard ASP enrichment activity that every company engages in, even outside the technology sector.

 

[RussianSensation]

But the pricing suggests this isn't about PR, its just your standard ASP enrichment activity that every company engages in, even outside the technology sector.

That's a good point. When Core i7 920 was selling for $284 or so, the 930 and 940 versions were selling for a lot more $, despite all of them topping out at about the same 4.2ghz area in overclocked states.

Core i7 960 was $562 around March 2010. The same CPU now sells for $199 at MicroCenter. Talking about depreciation! :biggrin:

 

[john3850]

This 2700 is also being held back do to the BD.
What if intel bins the 2600K for the faster i7-2700K.
Now if the 2700k can oc 300-400mhz more that sounds good.

 

[StrangerGuy]

That's a good point. When Core i7 920 was selling for $284 or so, the 930 and 940 versions were selling for a lot more $, despite all of them topping out at about the same 4.2ghz area in overclocked states.

Core i7 960 was $562 around March 2010. The same CPU now sells for $199 at MicroCenter. Talking about depreciation! :biggrin:

More interesting was this:

http://www.microcenter.com/single_pr...uct_id=0367847

i5 760 = $150.

Phenom II? What was that again?

 

[LOL_Wut_Axel]

This 2700 is also being held back do to the BD.
What if intel bins the 2600K for the faster i7-2700K.
Now if the 2700k can oc 300-400mhz more that sounds good.

Not that much better, but looking at history it should be about 200MHz better. That's how it is most of the time when the newer, more mature samples come out like the Core i7 930 that OCed better than the 920 and 940, and the i5 760 that OCed better than the 750.

Also, regarding the prices above: the i5-2400 costs the same in MicroCenter and comes in retail form, not to mention it can reach 3.8GHz. The i5 760 can get 4-4.2GHz, but given the 11% higher IPC of Sandy Bridge it's a better choice overall, especially since it's not on a dead platform. Also, SB is a lot more power efficient, especially since 3.8GHz on the 2400 is at stock voltage.

 

[john3850]

No cheap hex cores
No more fast1155 upgrades
No decent upgrade in x1366
No cheap unlocked sb-e

 

[alexruiz]

I, personally, have only ever used freely available encoders (x264, Xvid, etc). However, I have seen several, fairly reliable, reviews about quality comparisons between multiple H.264 encoders, MainConcept, Elecard, and DivX to name a few.

http://compression.ru/video/codec_comparison/h264_2011/mpeg-4_avc_h264_video_codecs_comparison.pdf

Should be a pretty good read if you really care about the quality of output from your encoder. Just realize that x264 has a myriad of settings. You can quite easily get it to spit out anywhere from 200fps to .2fps depending on what settings you use.

Good read, thanks!
If you know one or more of the authors, a correction is needed. They called everything a codec, when is reality some of the stuff used was also different "container". ASP and H264 are different containers

 

[Imouto]

No, h264 and ASP are both codecs. If you're talking about .h264 extension is just a stream.

mp4, mkv or avi for example are containers.

 

[Cogman]

Good read, thanks!
If you know one or more of the authors, a correction is needed. They called everything a codec, when is reality some of the stuff used was also different "container". ASP and H264 are different containers

ASP and H264 are NOT different containers. They are video compression standards. Containers are things like an MP4s, MKVs, and AVIs.

While programs such as x264 are not strictly codecs per say (they don't provide decoding) it is not far fetched to call them such.

 

[Cogman]

No, h264 and ASP are both codecs. If you're talking about .h264 extension is just a stream.

mp4, mkv or avi for example are containers.

Technically, H264 and ASP are not codecs, but rather video compression standards (ok, you could call them codec standards as well). codecs are the actual programs that do the compression/decompression.

 

[Imouto]

Yeah, technically. For any outsider they're codecs.

 

[JFAMD]

Now, Windows will be shuffling threads around onto the least-used core which may be in the same module as the most-used core resulting in a 10% downgrade in performance for BOTH cores - and possibly an extra "penalty" from the loss of thermal efficiency and, thereby, turbo-boost.

This could easily cost 20% performance loss from the ideal. One certain issue will be the iterative nature of thread scheduling:

Normal:
Thread 1->core 0
Thread 2->core 1
Thread 3->core 2
Thread 4->core 3

Best On Bulldozer:
Thread 1->core 0/1
Thread 2->core 2/2
Thread 3->core 4/5
Thread 4->core 6/7

Indeed, it would be best if Windows was aware of the least loaded module and used that one instead of the least loaded core, but that would have a much lesser effect and the added scheduling complexity may mean it is not worthwhile.

Losing 20% or so in performance simply due to this is easily understandable - which is why Microsoft decided that CPUs needed drivers too - and likely why AMD's/Microsoft's software team may be holding up release and holding back performance...

--The loon

Actually, I think that you are a.) overestimating the impact of sharing resources and b.) undersestimating the impact of Turbo CORE.

If you load 4 threads on 2 modules there is a small impact from sharing, probably between 0 and ~10%, depending on the workload. However, there are also potential benefits of sharing if the two threads are accessing the same data as it is in the shared cache lines...

However, with all 4 threads loaded on 2 modules, the other two can be power gated down and you a.) stay resident in the first Turbo CORE state longer and b. can boost into the second Turbo CORE state.

It really is going to come down to the actual workload, but I think the idea of getting all of the resources for one thread is overblown because the areas that are shared are areas that are already over-provisioned in the processor, so the upside from having extra resources is pretty low. For instance, what good is having 10 lanes on a highway at 2AM when there is no traffic?

 

[BlueBlazer]

YABDBenchmark leak:

http://translate.google.com/transla...md-fx-8150-vermeintliche-benchmarks-geleaked/

Due to his infamous reputation (for posting and sending fake benchmarks), we will have a very difficult time believing him anymore, even if he now shows a few similar results with reliable leak sources (also which he could have taken from the very same leaks themselves). :hmm:

Things are getting more interesting every day:

Core i7-2700K 3.5ghz to cost $340-350, report suggests
http://techreport.com/discussions.x/21692

Indeed. They could be putting one (or two more) on top as well. This may relegate CPUs below Core i7 2600K to 3rd (or 4th placing). :hmm:

This 2700 is also being held back do to the BD.
What if intel bins the 2600K for the faster i7-2700K.
Now if the 2700k can oc 300-400mhz more that sounds good.

There are higher bins, which are used for Sandy Bridge-based Xeons like ES-1290, though these are premium priced SKUs.