Yonah results on OC!

Well i just ran the same pi tests on my 920d @ 4200
the 1m pi is very close to the 2ghz yonah
(i could post the pics if any wants)

920d @ 4200

1 x 1m pi 30.6
2 x 1m pi 31.1

yonah @ 2ghz

1 x 1m pi 30.4
2 x 1m pi 34.7

on the 8mb test the fsb/ram helps even more

920d @ 4200

1 x 8m pi 5m 37
2 x 8mpi 5m 49

yohan @ 2ghz

1 x 8m pi 5m 53
2 x 8m pi 7m 02

remeber this is a stock 2ghz yonah in a laptop i am not sure if it was dual channle 533 or 667 but it was running at 5-5-5-15 againts a 920d @ 4200 with 300fsb and dual channle ram @ 400 4-3-3-4 so the yonah is miles behind on the ram bandwidth.
once i get it back i will know better and will do a fresh install and make sure it has dual channle ram.
i could set the ram on the 920D to 533 and 667 5-5-5-15 to see if thats makes a differance. (in fact i will do)

Edit:
with the fsb @ 300 and ram @ 300 5-5-5-15

1 x 1m 31.6
2 x 1m 32.1

1 x 8m 5m 58
2 x 8m 6m 32

the differance between 1x 8m and 2x 8m has jumped from 12s to 34s but still not over 60s like the yonah.
lets hope the aopen will run higher than 266fsb with clockgen to get the memory bandwidth where it needs to be for the yonah realy show what it can do.

The reason for the 1min jump in times from 1x - 2xSpi is because of its shared cache and smartcache tech as somebody stated earlier. yonah cpu has all the information in one cache and sorts to the needed cpus while the 920 series and current AMD dualcores have placed 2 seperate caches so each cpu has its own dedicated cache, so it finds data for the required core faster.

Or something along those lines :slap:

Quote:

---

Originally Posted by Schneider

The reason for the 1min jump in times from 1x - 2xSpi is because of its shared cache and smartcache tech as somebody stated earlier. yonah cpu has all the information in one cache and sorts to the needed cpus while the 920 series and current AMD dualcores have placed 2 seperate caches so each cpu has its own dedicated cache, so it finds data for the required core faster.

Or something along those lines :slap:

---

interesting
but for example in 3d benchmark or in game this shared cache could be a lot slower than 2 separated cache?:confused:

thanks

Quote:

---

Originally Posted by Schneider

The reason for the 1min jump in times from 1x - 2xSpi is because of its shared cache and smartcache tech as somebody stated earlier. yonah cpu has all the information in one cache and sorts to the needed cpus while the 920 series and current AMD dualcores have placed 2 seperate caches so each cpu has its own dedicated cache, so it finds data for the required core faster.

---

This is not correct. The speed of search in L2 does not depend on a quantity of the running versions of Pi. It is always equal to 14 cycles. Real reason in the fact that one Pi obtains entire 2M cache, whereas two of pi enjoyed only half of cache. In 940 and AMD they always obtain only half of cache. The problem is that 1M Pi cannot completely be accomodated into 1M cache because of different Windows background processes which requires certain quantity of memory (i.e., they are in L2).

I still feel the 166fsb is the bottleneck starving the cpu when they are both running but only way to prove it is to run higher fsb/ram with lower multi so cpu is same speed.
just have to wait and see.

one thing i did think if the cache is shared when runing 2 instances of pi the 2nd thread could it use the results calculated and stored from the thread that calculates it first.

Quote:

---

Originally Posted by leejsmith

one thing i did think if the cache is shared when runing 2 instances of pi the 2nd thread could it use the results calculated and stored from the thread that calculates it first.

---

No way. Each thread has it's own memory area and can't access memory over it's boundares.

I guess data in the cache would be tagged to the process id that requested it.

Quote:

---

Originally Posted by kl0012

No way. Each thread has it's own memory area and can't access memory over it's boundares.

---

Quote:

---

Originally Posted by leejsmith

I guess data in the cache would be tagged to the process id that requested it.

---

No. Data in the cache tagged to the real memory location - not to the proccess ID. SuperPi is not designed as multithreaded software, so it can't access memory of another thread.

look :

http://www.forumdeluxx.de/forum/showthread.php?t=209283

its german side! ;)

Nice but the board has 265 max. (using jumper), not 199.

http://www.forumdeluxx.de/forum/show...6&postcount=81

Quote:

---

Originally Posted by Chri$ch

http://www.forumdeluxx.de/forum/show...6&postcount=81

---

Low FSB hurts that Super pi time. :stick:
That super pi timing is a bit high. 20-21s should be more reasonable at higher FSB with the same clock speed.
Previous Super pi time we saw on Yonah at 2780MHz and 920MHz FSB was 21sec.
Those times still beat crap out of A64. You will need about 3500-36000 MHz on an A64 FX to achieve those times. :slapass: