Printable View
Hey Hokie... Even EA6's winrar scores are a little weak.. ;)Quote:
Originally Posted by hokiealumnus
The X4 needs alot of finesse which in my opinion only makes it more fun!
Here's my Winrar score:
Clickable
http://i30.photobucket.com/albums/c3...715_Winrar.jpg
Just wanted you to know the ~1850 wasn't a fluke.. :up:
BTW: Achim, that is with an ULTRA USB Hub/Card Reader attatched, so far I haven't seen any ill effects from it..
Winrar loves 1066MHz ram. :) Nice score Dave!
203 was max.Quote:
Originally Posted by Titan7171
But it i can go higher if i set bootup HTT+HTT set to the same.
But i did not have to touch the BootupHTT with the dual core.
Yeah Daveburt, i've seen the usb issue only on the DFI/Sapphire board so far. :)Quote:
Originally Posted by Daveburt714
Anyone tried what the voltage limit of this board + 9950BE is? I'd be interested because it only has one 12V rail.
they make sse enabled super pi, just not EXACT time i.e. 30 sec for 1m pi as opposed to 30.458 for 1m piQuote:
Originally Posted by Particle
in my rig sse enable pi is 1 second better, i don't know if it's more than a sec, cuz like i said it does not give exact result.
If it made only a second of difference, I'd have to say whoever made the SSE version did an exceptionally :banana::banana::banana::banana:ty job.
I don't just say this as a speculating user. I say this as a programmer for the last decade.
That is a great score. Eclipses my puny little 1655. Very nicely done!Quote:
Originally Posted by Daveburt714
wow... well if ur such a good coder ... make it better than a second improvement. sse2 is the code.
http://www.xtremesystems.org/forums/...42&postcount=2
tell craig how crappy of a job he did. you are a jerk.
edit
http://i4memory.com/AMD64_tools/supe...er_pi_SSE3.zip
the sse3 version takes of 2 seconds off of the sse2. so that's 3 seconds. ran it right now with all my apps running.
1 or even 3 second(s) off of a 33 second run is pretty good, what did you expect 5? does not scale the way YOU are thinking
thats ashame I was hoping it would work for you btw Im set at 235 for 24/7 use not 240......240 is the highest 250 is a no go but Im still learning i updated to the 1.5 bos from the 1.4 and I like the 1.4 better i got a litlle bit less overclock with the 1.5.Quote:
Originally Posted by Final8ty
Jeez isn't that 1.55v a little too much for a 45nm chip (on page one?)
JM
i think it's cuz the sb600 thingy. maybe a long shot?
i doubt it i just went froma SB600 to a SB700 board and they both needed the same volts at the same speeds
And you say I am the jerk. :down: :shakes:Quote:
Originally Posted by i found nemo
If you want a good example of the kind of performance increase SSE-enabled apps provide, take a look at ffdshow. It's easily 20% quicker. 1 second off of a 33 second run is a 3% improvement. The workloads aren't identical and thus they aren't directly comparable, but you get the idea. Pfft. Ten years of MMX and SSE development hasn't brought us a 3% increase in performance for floating point workloads. You aren't even a programmer. How can you possibly think you're qualified to criticise my opinion in any kind of valid way? You just jump all over me about how I'm a terrible person for suggesting an SSE enabled program possibly isn't up to snuff.
If you just don't like me for some reason, that's fine, but please PM me about it instead.
so ... you think that a 33 second bench that gets 3 seconds off is slow ... it's an improvement still, wich was never sought out to be further developed because everyone ran non sse encoded for official results! :yepp:Quote:
Originally Posted by Particle
I'll give you that one. And the three seconds or so savings is more like I'd expect. :)
ok .... are you gunna encode sse 3 pi with milliseconds? you should..
just some random thoughts
the 45nm is ~3s quicker than the 65nm posted by someone on here, when there both in the 3.4ghz range, thats great to know that extra cache is working wonders. looks like 10% more power with the die change, this might be enough to make it equal or beat the intels on real thinking applications
dont know why, but i like 3dmark06 cpu bench, its an easy way to see about how much more powerful cpu to cpu comparisons are. that and cinebench, i think is where people should do much more comparisons instead of pi.
when it comes to cpu scaling in games, the reality is everyons computer is different, and they have adjustable settings to fix that. i just play with fog or shadows or max viewable distance until i find out which is the real bottleneck. i play Grid at 1920x1200 with max textures and lighting, but couldnt care less about how much smoke a burnout does, or how the shadows from trees look. so to me it looks just as good as everything being maxed out, cept 40-60fps. but benchmarks have a standard and i wonder how much higher people could score in 3dmark06 if they were running it to be less cpu dependent. i have a 2900xt and 5000+BE, so for me 11k pts on vista is great, but if i drop in a 4870x2 and get only 13k, does that mean i wasted 500$ for 15% more performance, or does it mean i should tweek it so that my 80$ cpu isnt holding me back any, and then compare how i should see up to 300% increase by swapping the cards.
*randomly streamed thoughts ended*
It was not real 1.55V, 1.55V show only CPU-Z...real vcore was about 1.4VQuote:
Originally Posted by Jim Morbid
Maybe focus a little less on 3DM2K6 and more on real life gaming experiences. My bet is that the 2900XT to 4870X2 upgrade will be much more than 3DM2K6 would let you think. Really.Quote:
Originally Posted by Manicdan
Agreed. 3DM06's results for my single vs. crossfire examination didn't reflect what I was seeing in real games like HL2, Crysis, Company Of Heroes, etc at all.
dont worry i dont dwell on it at all, i like using benchmarks to see the before and after of my overclocking. even if they arnt perfect they are much more reliable across reviews as they have standards. if i depended on a site to tell me what kind of fps i can expect when i go pick up the next big game, like fallout 3, i would just go to futuremark and compare to the 1000 people who have systems like me, instead of going to site after site looking for one that might be close and hope they did a good test.
back on topic, does this 45nm version seem to be WAY better than the 65nm by comparing these to screens
45nm
http://www.xtremesystems.org/forums/...7&postcount=16
65nm
http://www.xtremesystems.org/forums/...1&postcount=35
Dated 0821... so they had these chips sometime in May?
Perhaps they found some problems with the SB750 and these 45nm chips and that caused a further delay with the SB750 release?
AND: It would be VERY cool if they sent out 45nm ES samples to testers at the same times as the SB750 becomes available.
(Just some random thoughts... based on nothing but speculation.)
Check this out. (translated)
The early C0 stepping has 24W lower power consumption on full load than B2 at the same voltage. :)
Clearly, this Deneb sample is showing a definite improvement over the current Phenoms clock-for-clock, at least in SuperPi. The biggest question though, at least to me, is whether or not this additional performance (seems to be ~14% or so) is caused because of the additional cache or if there were other significant improvements made.
Unfortunately, because all the current Phenoms use the same amount of L3 cache, it makes a direct comparison of the effect of additional cache almost impossible. However, K10 is largely based on the pre-existing K8 architecture, and there were Athlon X2 varieties with 512kb/core and 1024kb/core cache sizes. The benefit from the additional cache could serve as an indication of what to expect from adding cache to Phenom.
Here's the first run with the 5000+ (512kb cache) @ 3.3GHz: (Originating thread)
http://img.techpowerup.org/080627/33...ith%20sp1m.png
Another run has an overclocked Athlon X2 6000+ (1024kb cache): (Originating thread)
http://img88.imageshack.us/img88/5223/spizg6.jpg
For a K8-based processor, going from 512kb to 1mb of cache results in a speedup of 1.118 seconds or about 4.3%. But, the difference in bus speed between the two is about 4.67%, which is also going to effect the result as well. Taking that into account, the difference in SuperPi times from 512kb additional cache on a K8 is probably less than 4%.
The additional cache didn't do much at all for the K8 architecture, so a similar effect should be seen on K10. While it's true that there's no Phenom models with varying levels of cache, there was the whole TLB bug issue. Although the BIOS workaround patch doesn't disable the L3 cache entirely, one of the effects was a large increase in memory latency:
http://www.techreport.com/r.x/phenom...9600-notlb.gifhttp://www.techreport.com/r.x/phenom...00-withtlb.gif
If the SuperPi dataset is filling Phenom's cache @ 2mb, then there has to be some main memory access involved. I've read that SuperPi is very sensitive to latencies, so this should be very obvious in the results.
http://www.techreport.com/articles.x/13741/2Quote:
Originally Posted by Tech Report
So if the 2mb of L3 cache isn't big enough for SuperPi, we should see a difference that is much greater than 10% from enabling the TLB patch:
http://img168.imageshack.us/img168/1839/superpi1us7.jpg
(Source)
The 9600BE only suffered a 3.9% performance penalty from the TLB patch, not even close to the 10% mark. To me this suggests that the additional cache would not have a huge effect on SuperPi at all, and certainly not the 14% increase that this test would suggest. If the speedup isn't due to the cache size, that means tweaks were made to other parts of the core or cache subsystem as well. So it's possible that Deneb could be a nice improvement over Agena, perhaps even in applications that aren't cache dependant.
Nice first post there resar!
Also Deneb features a 48-way set associative cache compared to Phenoms 32-way. Now what ever that means, maybe its faster?
But seeing that the faster lv1 and lv2 cache has even fewer n-way cache, it should be slower with higher n-way cache.
http://img2.zol.com.cn/product/21_45...g9YhvctxrY.png
http://img2.zol.com.cn/product/21_45...hgJ2qLz0IU.png