Pentium 4 SSE2 implementation

[NikosD]

Intel's approach for HEVC reminds me Intel's approach for SSE2.

When SSE2 was introduced for the first time in late 2000 with Pentium 4, Intel implemented the SIMD units to be 64bit wide, while the SSE2 instructions used 128 bit data (!) dropping the potential performance to half.

It was Core 2 architecture 6 years later (!) after P4 that implemented proper 128 bit SIMD units.

They wanted to build the new vector code approach early, but the benefits of that approach that would actually perform better, would be visible on a future CPU architecture.

The 8K HEVC 8bit HW support is pretty much useless right now, but remember there is no 8K content yet.

I'm not sure that in the future 8K will ever use 8bit or go directly to 10bit, though.

Intel builds early for the future again, preparing for the moment when the process shrinking or other architectural choices allow them to include 10 bit HEVC HW decoding in future iGPUs

Probably Kaby Lake includes 10bit HEVC but because it's in 14 nm process again, maybe they have to cut something else to fit 10 bit HEVC.

[mhourousha]

Intel's approach for HEVC reminds me Intel's approach for SSE2.

When SSE2 was introduced for the first time in late 2000 with Pentium 4, Intel implemented the SIMD units to be 64bit wide, while the SSE2 instructions used 128 bit data (!) dropping the potential performance to half.

It was Core 2 architecture 6 years later (!) after P4 that implemented proper 128 bit SIMD units.

SSE(not SSE2) already use 128bit XMM register，MMX use 64bit register(80bit X87 FPU register).so I don't get the point of 'Intel implemented the SIMD units to be 64bit wide'you said.

[NikosD]

Because you are confusing things inside CPU microarchitecture.

It's a different thing the instruction set and the registers from the execution SIMD units I wrote in my post.

[mhourousha]

Because you are confusing things inside CPU microarchitecture.
It's a different thing the instruction set and the registers from the execution SIMD units I wrote in my post.
I still couldn't get your point of '64bit wide'
Maybe your point is P4 doesn't have 'real 128bit register,so when you excute 128bit instrcution like ADDPD, the performance will drop significantly'？

[NikosD]

You don't read carefully.

I'm not talking about registers but execution units.

A 64 bit wide execution unit need double pass to execute a 128 bit wide instruction, so the theoretical performance drops to half.

But because I have already written all these above and because it's not the suitable thread for microarchitecture seminar, you must read again my posts and try google to understand better.

[mhourousha]

You don't read carefully.

I'm not talking about registers but execution units.

A 64 bit wide execution unit need double pass to execute a 128 bit wide instruction, so the theoretical performance drops to half.

But because I have already written all these above and because it's not the suitable thread for microarchitecture seminar, you must read again my posts and try google to understand better.
But most MMX instruction(64bit operands) an the corresponding SSE2 instruction(128bit operands)has same latency In Pentium4.

[foxyshadis]

When SSE2 was introduced for the first time in late 2000 with Pentium 4, Intel implemented the SIMD units to be 64bit wide, while the SSE2 instructions used 128 bit data (!) dropping the potential performance to half.

Not sure where you heard that, but that's definitely not true (http://www.ecs.umass.edu/ece/koren/ece568/papers/Pentium4.pdf). You're thinking of the first Pentium 3, Katami, and I believe Coppermine shared the same architecture, while Tulatin fixed it to full-width. That was one of the few places the P4 could be much faster than the P3, despite how woefully inadequate it was otherwise.

[NikosD]

Not sure where you heard that, but that's definitely not true (http://www.ecs.umass.edu/ece/koren/ece568/papers/Pentium4.pdf). You're thinking of the first Pentium 3, Katami, and I believe Coppermine shared the same architecture, while Tulatin fixed it to full-width. That was one of the few places the P4 could be much faster than the P3, despite how woefully inadequate it was otherwise.

You are going too much off-topic and you are definitely "provoking" me to break my rule of not commenting clearly off-topic and completely wrong assumptions, but because you are the moderator I have to reply to you.

From YOUR pdf that you called me to read and I read:

"The SIMD integer ALU execution hardware can process 64 SIMD integer bits per clock cycle.
This allows the unit to do a new 128-bit SSE2 packed integer add uop every two clock cycles.

A separate shuffle/unpack execution unit can also process 64 SIMD integer bits per clock cycle allowing it to do a
full 128-bit shuffle/unpack uop operation each two clock cycles.

MMX/SSE2 SIMD integer multiply instructions use the FP multiply hardware mentioned above to also do a 128-bit packed integer multiply uop every two clock cycles."

What I wrote above is knowledge of all the people who have an active interest in CPU microarchitecture or/and writing assembly code.

[NikosD]

I can see that the obsession of commenting me and try to prove me wrong has started to spread on more people...

It will not be that easy guys ;)

[nevcairiel]

Speaking as someone who does actually write ASM on occasion, and from a purely performance standpoint (empirical data, collected over the years), SSE2 is considered "slow" on AMD Athlon64 (and CPUs from the same generation, practically all AMD CPUs with SSE2, but without SSE4a), and Intel Pentium-M "banias", Pentium-M "dothan" and Core1 "Yonah"
On all other CPUs, it usually provides a speedup over MMX or SSE1 (as applicable)

So even if its only 64-bit execution units, it was still faster than MMX on the P4, which is the end-result that really matters. Maybe not as fast as it could've been, but who knows what they would've had to sacrifice instead. P4/NetBurst had a whole lot of issues with heat as it is.

[NikosD]

Speaking as someone who does actually write ASM on occasion, and from a purely performance standpoint (empirical data, collected over the years), SSE2 is considered "slow" on AMD Athlon64 (and CPUs from the same generation, practically all AMD CPUs with SSE2, but without SSE4a), and Intel Pentium-M "banias", Pentium-M "dothan" and Core1 "Yonah"
On all other CPUs, it usually provides a speedup over MMX or SSE1 (as applicable)


First of all I will sound a little bit strict, but there are no occasional developers writing assembly.

You are either at least 10 year assembly developer or you are nothing (regarding assembly) and better leave the compiler to do the job.

Though, because you mentioned it, as an occasional developer in assembly you shouldn't confuse SSE2 instructions with the execution of them.

SSE2 was never slow, because instructions (besides serious or non serious flaws in their design like MMX) can't be slow. It is most of the times the way that are executed fast or slow.

AMD64 before Barcelona core had 64 bit wide execution units, like all Intel CPUs before Core 2 architecture and that was the reason of slow performance.

AMD Barcelona core matched the SIMD speed of Core 2 clock-for-clock, using similar architecture and 128bit wide execution units.


So even if its only 64-bit execution units, it was still faster than MMX on the P4, which is the end-result that really matters. Maybe not as fast as it could've been, but who knows what they would've had to sacrifice instead. P4/NetBurst had a whole lot of issues with heat as it is.

You made another serious mistake here, for an occasional assembly developer.

MMX was one of the cases I described above with a somewhat serious flaw by design.

The 64 bit registers used by MMX, were not separate like the 128 bit registers of SSE (for SP floats) /SSE2 (integers and DP floats), but it used the FPU registers.

So, the execution of mixed code (with integers and FPU operations) was problematic dropping the performance a lot due to context switching (from integers to floating point and vice versa).

In order to see how slow the execution of SSE2 was on P4, you have to compare it with the 128 bit wide SSE2 execution of Core 2 architecture and not MMX of course.

[nevcairiel]

First of all I will sound a little bit strict, but there are no occasional developers writing assembly.

You are either at least 10 year assembly developer or you are nothing (regarding assembly) and better leave the compiler to do the job.

Nonsense. Compilers are terrible at SIMD, and even with only a bit of experience you can write specialized algorithms in SIMD instructions that are much faster than what the compiler would've generated.

A professional asm developer with 10 years of experience could probably write code thats still a bit faster, but beating a compiler at SIMD isn't hard.


You made another serious mistake here, for an occasional assembly developer.

MMX was one of the cases I described above with a somewhat serious flaw by design.

The 64 bit registers used by MMX, were not separate like the 128 bit registers of SSE (for SP floats) /SSE2 (integers and DP floats), but it used the FPU registers.

So, the execution of mixed code (with integers and FPU operations) was problematic dropping the performance a lot due to context switching (from integers to floating point and vice versa).


I'm well aware of how MMX works, but even if you account for that, its not that bad. Not every application uses floating point constantly, and SSE2 is integer operations, so if you compare MMX and SSE2, you are comparing integer operations. SSE1 is floating point, where this would be more of a concern (because if you use FP SIMD, you will also use the FP registers in the generic code).

Especially video processing rarely uses any floating point math, so you could write a processing algorithm without needing to context switch constantly, and this whole point becomes moot.

[NikosD]

Nonsense. Compilers are terrible at SIMD, and even with only a bit of experience you can write specialized algorithms in SIMD instructions that are much faster than what the compiler would've generated.

A professional asm developer with 10 years of experience could probably write code thats still a bit faster, but beating a compiler at SIMD isn't hard.


Nonsense.

Recent compilers even of the last 2 years are a lot better than ANY occasional assembly developer in SIMD code.

A professional assembly developer - after MONTHS of work - could beat them in SIMD coding.


I'm well aware of how MMX works, but even if you account for that, its not that bad. Not every application uses floating point constantly, and SSE2 is integer operations, so if you compare MMX and SSE2, you are comparing integer operations. SSE1 is floating point, where this would be more of a concern (because if you use FP SIMD, you will also use the FP registers in the generic code).

Especially video processing rarely uses any floating point math, so you could write a processing algorithm without needing to context switch constantly, and this whole point becomes moot.

First of all - as I wrote above and you didn't read it - SSE2 is not integer only. It's integer and DP floating point too.

Second, it is somewhat rare for code to be integer only.
So, in real world mixed code (even if it favors integers like image/video processing) the content switching will hit performance.

Every context switch counts, you don't need a constant contect switching to drop performance and this whole point becomes moot.

Anyway, the results of SIMD performace of P6 based CPUs (in integer SIMD using MMX and SSE2) and Core 2 is out there and everyone could see the results.

P6 based CPUs were slow at SSE2 SIMD because of 64 bit wide execution units and internal microarchitecture. Period.

That was my point from the beginning.

[nevcairiel]

Nonsense.

Recent compilers even of the last 2 years are a lot better than ANY occasional assembly developer in SIMD code.

A professional assembly developer - after MONTHS of work - could beat them in SIMD coding.

You clearly have never even investigated this topic. I shall leave you to your believes.
I should give you a LAV Video build with all the "bad" asm removed that I wrote in a couple days (and not months), and you can judge how well the compiler did instead.

[NikosD]

More than you think.

I shall leave you, too.