Haswell Preview Benchmark

[henryzz]

As far as I can work out latency for the 2133 CL9 is 8.44 ns and for the 2400 CL11 is 9.17 ns. For 2400 CL10 it is 8.33 which is actually better than the 2133 memory.
Could someone who has fast memory do a prime95 benchmark with two different memory latencies?

[kladner]

Originally Posted by db597

Assuming an affordable price difference (hmm.. I'll just skip 1 lunch), would you guys go for 2133 CL9 or 2400 CL11? Trying to decide between them, both GSkill RipRaws X. So far, the P95 discussion seems focused on bandwidth and I don't hear about timings being mentioned. Does the more relaxed timing only a small secondary concern?

I suppose the best performance would be a 2400 CL10... but that cost is in another league (another 30%+ more).

I had the impression, possibly mistaken, that latency was an issue for multi-threaded P95.

One of the better discussions I've read of DDR operation and trade-offs is here, on Anandtech.

[ewmayer]

Intel to Supply Apple with Special High-End Haswell Processors for MacBook Pro | Mac Rumors

Let the CUDA vs OpenCL flamewars rage...

[firejuggler]

another haswell news : fanless ones
http://anandtech.com/show/7168/haswe...ater-this-year
15 & 28 W tdp ( for laptop and tablet apparantly)

[ldesnogu]

Both this Apple and "4.5W" SDP news are somehow related: this is heavy binning of chips. No need to say this means low volumes and high prices.

[Prime95]

On Sunday, I installed prime95 version 28.1 and resumed my LL testing. Iteration times dropped about 1 ms. -- from about 15.5 ms. to 14.5 ms. Wonderful.

Three days later I've suffered three unexplained spontaneous reboots. In the month of LL testing prior to 28.1 there were no unexplained reboots.

I've tried upping the CPU and memory voltages a smidge. We'll see if that solves the problem.

[TheMawn]

George: Does Linux has some sort of Event Viewer equivalent? The more computer inclined folk might be able to pinpoint the cause...

Were you monitoring thermals at the time?

[ewmayer]

Originally Posted by ewmayer

But I ran into some truly bizarre timings with my new avx mersenne-dwt carry macros yesterday - need to look into those first. Briefly, the "genuine avx" macro runs horribly slow relative to the sse2 one (which in avx builds is simply the original sse2 carry macro adapted to take account of the differing data layout between sse2/avx). My initial thought was that this might be due to the avx macro using a small number of unaligned (16-byte aligned but not 32) ymm-register loads, but when I replaced those with a pair of aligned xmm loads and a "combine xmm data" operation ...[code snip snipped]... the result was even worse. I confirmed that the original vmovups was not the problem by fiddling with the data layout to allow all aligned loads - tiny, insignificant improvement.

Took a close look at the offending code here again the past several days and finally found the problem - briefly, I constructed the AVX-based Mersenne-mod carry macros by fusing the fancy-indexing footwork of the legacy SSE2 mersenne-mod-DWT carry macros and the AVX data-permute aspects of the AVX-based Fermat-mod carry macros - the result ran incredibly, awfully, unbelievably slowly in the initial implementation, which came online just before Haswell hit the market. I have traced the problem back to the mixing of legacy SSE instructions (using xmm-form registers) in the indexing-computation portions of the code with AVX instructions used for weights and carries in the new AVX code. The solution was to simply prepend a "v" to the legacy SSE instructions and (for ones where the VEX form of the instruction adds a third operand) to duplicate the original SRC+DEST operand (rightmost in AT&T/GCC-syntax inline ASM, leftmost in Intel ASM syntax) in order to satisfy the 3-operand syntax.

Here are some references:

o Intel's own "Avoiding AVX-SSE Transition Penalties" PDF:

Here is the money snippet:

When using Intel® AVX instructions, it is important to know that mixing 256-bit Intel® AVX instructions with legacy (non VEX-encoded) Intel® SSE instructions may result in penalties that could impact performance. 256-bit Intel® AVX instructions operate on the 256-bit YMM registers which are 256-bit extensions of the existing 128-bit XMM registers. 128-bit Intel® AVX instructions operate on the lower 128 bits of the YMM registers and zero the upper 128 bits. However, legacy Intel® SSE instructions operate on the XMM registers and have no knowledge of the upper 128 bits of the YMM registers. Because of this, the hardware saves the contents of the upper 128 bits of the YMM registers when transitioning from 256-bit Intel® AVX to legacy Intel® SSE, and then restores these values when transitioning back from Intel® SSE to Intel® AVX (256-bit or 128-bit). The save and restore operations both cause a penalty that amounts to several tens of clock cycles for each operation.

o Agner Fog's "early in the AVX life cycle" commentary here.

Using the bastard hybrid AVX-FFT/SSE2-carry I deployed out of sheer desperation, runtime for Mersenne-mod was ~1.35x that of Fermat-mod at typical current LL-wavefront runlengths. With the mixed-SSE/AVX problem resolved, the "true AVX" Mersenne-mod per-iteration time is ~1.15x that of Fermat-mod.

To convey a sense of just how severe the timing penalties resulting from such SSE/AVX instruction mixing can be, the performance *penalty* component alone from using the mixed SSE/AVX carry macros here was greater than the entire *runtime* needed for either the "pure-AVX-FFT/SSE2-carry" hybrid in or the "true AVX 4 all" code.

[db597]

Originally Posted by Prime95

Three days later I've suffered three unexplained spontaneous reboots. In the month of LL testing prior to 28.1 there were no unexplained reboots. I've tried upping the CPU and memory voltages a smidge. We'll see if that solves the problem.

Sounds similar to when you first added AVX in 27.x... my previously rock stable build started to randomly reboot. There would be no errors detected by P95, but it would spontaneously reboot. I upped CPU VCore to no avail. Turns out it was voltages relating to memory that needed a boost (VCCSA, VCCIO and the DRAM voltage itself).

[Prime95]

Originally Posted by db597

I upped CPU VCore to no avail. Turns out it was voltages relating to memory that needed a boost (VCCSA, VCCIO and the DRAM voltage itself).

I upped the VCore and DRAM voltage one notch. It rebooted spontaneously this morning. I'm bumping it two notches more.

[kracker]

I'm thinking of upgrading a older core2 duo to a i3 haswell or ivy bridge... How much more performance is there from IB AVX to haswell? Do you think I should wait for Haswell or just bag a Ivy Bridge now?