Sorry, I think that's too much :p:Quote:
Originally Posted by bowman
Curious from what exactly ? Maybe I can try to describe it ... ;)
Printable View
Sorry, I think that's too much :p:Quote:
Originally Posted by bowman
Curious from what exactly ? Maybe I can try to describe it ... ;)
Well, nothing specific actually, just wanted to see how they implemented new stuff like SMT, IMC, QPI.Quote:
Originally Posted by JCornell
I realize that it's a bit early to expect all the software to work properly, but do the temps recorded seem to be correct? I'm not sure exactly what your benching setup is (aka what cooler you use), but temps of 50C or so while at idle are kinda high. Addition of the IMC, etc. would sensibly increase the temperature of the chip, especially as speeds increase. If this seems correct, then water-cooling will become even more necessary for decent overclocks on these chips.
http://www.digitimes.com/mobos/a20080724PD205.html
Thought this may be of interest.
Yes, Intel has already stated as such....http://techreport.com/discussions.x/14950Quote:
Originally Posted by Shadowmage
The difference is that AMD uses FIFO buffers between the L3 cache and and the other cores to absorb the clock skew... this causes the high latency observed with the Barcelona L3 cache.Quote:
The processor runs all of its internal components—the CPU cores, memory controller, and I/O—in a decoupled fashion, so one can tune their respective frequencies and voltages independently. This isn't a new idea, Kumar stressed, but Intel's implementation is new in that it uses a synchronous interface between those components. Most past implementations have asynchronous interfaces, he claimed, which result in both higher latency and indeterminism—"if you test five different systems, you will get five different results."
It seems GTN boards have a mux on the SMBus SPD, that's why HWiNFO32 and CPU-Z read only 1 channel's memory modules.. Should be controllable via ICH10, but no idea which pins..
QX6850 @3.66 GQuote:
Originally Posted by JCornell
The score in HWiNFO32 is so high, because it's multithreaded and uses all available CPUs (cores and HT units) so it assumes an application is capable of well using all resources.
You might try to run HWiNFO32 benchmark in single-thread mode and compare the results. Then you get the pure single-threaded performance gain.
Anyway, don't expect too much from this B0 early sample. There are still many errata inside...
Quote:
Originally Posted by JumpingJack
I will re-run it... I bumped down to 3.33 Ghz just now. I just finished putting the rig together -- notice speedstep was on in CPUID.Quote:
Originally Posted by Mumak
Dman Asus, buggy BIOS and all ... I only dinked with multipliers, if I set multipler to anything but auto, the speedstep diable option disappears. Setting it to auto and disabling speedstep, then upping multiplier re-enables speed step.
EDIT: Yeah, Nehalem looks too large from JC's run. It scales correctly at 3.33 Ghz to expected.
http://www.youtube.com/watch?v=OMnwpbQ4AHw
This might be of interest too..
Basically, Pat says his keynote is going to make you :banana::banana::banana::banana: your pants and you suck if you miss it. Ha. I agree, though. :yepp:
Quote:
We're gonna disclose the next level of details around the microarchitecture, some of the way cool technologies that we've kept a secret 'till now, and finally, some of the productization plans for Nehalem coming to the marketplace.
To compare: QX6700 @ 3466 (13 x 266 MHz) ; 800 MHz CL4.4.4.12 T2 DDR2 ; RaptorX 150 GB
Quote:
Intel brings forward Nehalem launch
Originally scheduled to launch in November or December this year, Intel's Nehalem-based Bloomfield processors will now launch in September along with X58 chipsets, sources at motherboard makers have revealed.
However, the sources pointed out that CPUs and motherboards will not officially appear in the channel until early October.
Since Bloomfield CPUs are not socket compatible with previous Intel platforms, the accelerated launch is not expected to cause competition between the company's own products, although the same cannot be said for AMD's scheduled AM3-based CPU launch, noted the sources.
DigiTimes
:up:
Hot damn! time to start saving my pennies ;)Quote:
Originally Posted by mascaras
Bloomfield 2.93Hz @HWINFO32 Multithread
http://i245.photobucket.com/albums/g...halem/HW_B.jpg
...
Nice result compared to Hornet's system (2.93Ghz vs. 3Ghz).
Maybe a new Everest beta can run on your platform?
http://www.lavalys.com/beta/everestu...vcal8ksjdc.zip
Already try it over and over again everytime Everest released the newest version, Gainestown/Bloomfield platform all blue screen :rofl:Quote:
Originally Posted by Ruroni
@ JCornell
can you do the HWInfo32 benchmark single threaded?
Thanks
Chris
A couple people have now mentioned that B0 is "old silicon", and they are waiting for B1, etc.Quote:
Originally Posted by Mumak
Anyone know when B1 will tip up in the hands of our "early reviewers" :) ?
Is the only-using-1-memory-channel issue a B0 problem, or a motherboard thing, and does B1 fix it if the former?
There won't be a B1, but a different one..Quote:
Originally Posted by terrace215
C0? C1? I guess it must've qual'd at this point if they are bringing the launch into Sept/early Oct.Quote:
Originally Posted by Mumak
Hmm...6sec in Wprime32 @ 2GHz is a little bit weaker then a Skulltrail at 4Ghz :D
^LOL
:D:D:D
xTreme
I'm also curious if the memory channel issue is CPU or board related... any insights JC?
-Chris.
i dont know how reliable hw32 info is in this department, just look that the compare table, all values are rather strange...
Everything is relative in the benchmark area. There are too many factors that influence the performance and in fact you cannot say: CPU1 is 30% faster than CPU2. You must consider how a particular benchmark is build, what kind of code it contains and how it's compiled.
Let's say you have a benchmark for CPU integer operations compiled with Visual Studio 6, optimizations for P6. Since every CPU generation brings new instruction sets and new kind of optimizations, such code cannot tell you a real performace increase for a new generation. You also need to consider what kind of instructions are present, memory operands, branches, loops, how are the instructions and operands aligned. Very important is the compiler and optimization option. You can perfectly optimize code let's say for the Conroe family, but other families (e.g. Nehalem or K10) might require different optimizations in order to perform even better. So what's the best option? Different code for each family :brick:
I personally don't trust any benchmark because it simply cannot give you real numbers. The only usable comparisons are real world applications.
Quote:
Originally Posted by Hornet331