Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

SIMD in the 90s: Programming Intel's Pentium MMX

pikuma.com

Post reply on HN
Print view View original

11–20 of 74 posts

Re: SIMD in the 90s: Programming Intel's Pentium MMX

#11

Post by chasil »

theandrewbailey wrote: post #7
Const-me wrote: post #2

I would add than SSE1 and SSE2 are now required parts of AMD64 instruction set. All 64-bit PC processors are required to support them both. For that reason, modern compilers are ignoring x87 FPU when building 64-bit binaries. Instead, they compile all float and double arithmetic into SSE1 and SSE2 instructions, respectively.

Take a look at the micro-architecture levels. x86-64-v1 contains all the instructions that the original AMD64 and compatible Intel CPUs supported. v2 is all the SSE levels, v3 is AVX and AVX2, v4 is AVX-512. https://en.wikipedia.org/wiki/X86-64#Microarchitecture_level...

The wiki says:

"Additional XMM (SSE) registers: Similarly, the number of 128-bit XMM registers (used for Streaming SIMD instructions) is also increased from 8 to 16...

"The original AMD64 architecture adopted Intel's SSE and SSE2 as core instructions."

https://en.wikipedia.org/wiki/X86-64

This wansn't v2?

Re: SIMD in the 90s: Programming Intel's Pentium MMX

#12

Post by ack_complete »

zir_blazer wrote: post #10
ack_complete wrote: post #5

I did extensive MMX and SSE2 optimization of audio and video codecs in the 2000s. MMX made a large difference, but it was a pain. MMX optimization practically required assembly language. The Pentium MMX was an in-order dual pipe CPU, and while compilers supported MMX intrinsics, their code generation for it was abysmal. Visual C++ 6, for instance, would emit code that was 2/3rds register-to-register moves, with value…

> Additionally, some CPUs at the time only had a 64-bit data path and had to split SSE2 ops, but because of their 4-1-1 decode template, could only decode one such instruction per cycle. I believe that only the first Pentium 3 core, Katmai, did this. > This caused some confusion with the 64-bit version of Windows since Microsoft tried to say that x87/MMX shouldn't be used in long mode, but after queries from video pr…

> I believe that only the first Pentium 3 core, Katmai, did this.

No, all Pentium 3s as well as the Pentium M. Pentium 4 notably didn't suffer from it, but it of course had many, many, MANY other performance issues.

> I have some faint memories of hearing somewhere that Long Mode didn't support x87. I wonder if it is related to this early info you mention and it being Microsoft specific.

It was VM86 mode that Long Mode didn't support, which was one of the rumored reasons for removing 16-bit NTVDM support (among many). x87 and MMX were always supported in long mode and notably some libraries like OpenBLAS still use x87 instructions. Windows does prohibit use of x87/MMX in kernel mode where the need is negligible.

Re: SIMD in the 90s: Programming Intel's Pentium MMX

#13

Post by justsomehnguy »

ack_complete wrote: post #5

I did extensive MMX and SSE2 optimization of audio and video codecs in the 2000s. MMX made a large difference, but it was a pain. MMX optimization practically required assembly language. The Pentium MMX was an in-order dual pipe CPU, and while compilers supported MMX intrinsics, their code generation for it was abysmal. Visual C++ 6, for instance, would emit code that was 2/3rds register-to-register moves, with value…

As someone on the other side... the difference was between 166 "regular" VS 133 MMX. And in less than two years it became irrelevant: '97 for MMX, '99 fo GeForce 256.

Re: SIMD in the 90s: Programming Intel's Pentium MMX

#14

Post by Nition »

theandrewbailey wrote: post #9

> Each MMX register is 64 bits wide. Internally, the MMX registers were aliases of the x87 floating-point registers. Due to the way the first Pentium 3 CPUs (Katmai) were built, they likewise aliased the x87 (and thus, MMX) registers to the XMM SSE registers, but this was hidden from programs. It wasn't until at least the Coppermine revision that they were separate registers again.

I remember hearing a rumour as a young teen that the Coppermine codename meant it actually had copper wiring and that's what made it faster somehow. Copper has lower resistance than aluminium and can therefore help chips run faster - it makes sense! But it was just a codename and the coppermine had aluminium interconnects.

My family got a PIII 533Mhz coppermine, in the early sideways Slot 1 configuration. Blazing fast at the time. Been a long time since I heard anyone say "coppermine".

CPU progress was wild in the 90s, where you could wait two years and your new CPU would be double the old one's speed at the same price point. Today it takes near a decade for CPU speed to double.

I also recall the first game that advertised its exciting use of the new MMX technology: POD.[1]

[1] https://en.wikipedia.org/wiki/POD_(video_game)

Re: SIMD in the 90s: Programming Intel's Pentium MMX

#15

Post by justsomehnguy »

ack_complete wrote: post #12
zir_blazer wrote: post #10

Earlier quoted context omitted.

> Additionally, some CPUs at the time only had a 64-bit data path and had to split SSE2 ops, but because of their 4-1-1 decode template, could only decode one such instruction per cycle. I believe that only the first Pentium 3 core, Katmai, did this. > This caused some confusion with the 64-bit version of Windows since Microsoft tried to say that x87/MMX shouldn't be used in long mode, but after queries from video pr…

> I believe that only the first Pentium 3 core, Katmai, did this. No, all Pentium 3s as well as the Pentium M. Pentium 4 notably didn't suffer from it, but it of course had many, many, MANY other performance issues. > I have some faint memories of hearing somewhere that Long Mode didn't support x87. I wonder if it is related to this early info you mention and it being Microsoft specific. It was VM86 mode that Long Mo…

> but it of course had many, many, MANY other performance issues.

The whole RAMBUS debacle... OTH DDR chipsets for Tualatin had shown what it was the end game for the P6 arch.

Re: SIMD in the 90s: Programming Intel's Pentium MMX

#16

Post by ack_complete »

justsomehnguy wrote: post #13
ack_complete wrote: post #5

I did extensive MMX and SSE2 optimization of audio and video codecs in the 2000s. MMX made a large difference, but it was a pain. MMX optimization practically required assembly language. The Pentium MMX was an in-order dual pipe CPU, and while compilers supported MMX intrinsics, their code generation for it was abysmal. Visual C++ 6, for instance, would emit code that was 2/3rds register-to-register moves, with value…

As someone on the other side... the difference was between 166 "regular" VS 133 MMX. And in less than two years it became irrelevant: '97 for MMX, '99 fo GeForce 256.

MMX in did not become irrelevant with the GeForce 256. Hardware video decoding was only in its infancy at the time and even the highest end GPUs only supported motion compensation acceleration for decoding only at best. Non-display image processing on the GPU was heavily bottlenecked by very slow read-back speeds from the GPU to the CPU across the AGP bus.

Re: SIMD in the 90s: Programming Intel's Pentium MMX

#17

Post by derf_ »

zir_blazer wrote: post #10
ack_complete wrote: post #5

I did extensive MMX and SSE2 optimization of audio and video codecs in the 2000s. MMX made a large difference, but it was a pain. MMX optimization practically required assembly language. The Pentium MMX was an in-order dual pipe CPU, and while compilers supported MMX intrinsics, their code generation for it was abysmal. Visual C++ 6, for instance, would emit code that was 2/3rds register-to-register moves, with value…

> Additionally, some CPUs at the time only had a 64-bit data path and had to split SSE2 ops, but because of their 4-1-1 decode template, could only decode one such instruction per cycle. I believe that only the first Pentium 3 core, Katmai, did this. > This caused some confusion with the 64-bit version of Windows since Microsoft tried to say that x87/MMX shouldn't be used in long mode, but after queries from video pr…

> I believe that only the first Pentium 3 core, Katmai, did this.

No, the Pentium M (Banias / Dothan) also needed multiple cycles for basic SSE2 ops (with a few exceptions like PUNPCKLQDQ or PMOVMSKB), a full four years after Katmai (source: I owned one, and wrote SIMD on it for codec libraries).

Re: SIMD in the 90s: Programming Intel's Pentium MMX

#18

Post by Lerc »

Nition wrote: post #14
theandrewbailey wrote: post #9

> Each MMX register is 64 bits wide. Internally, the MMX registers were aliases of the x87 floating-point registers. Due to the way the first Pentium 3 CPUs (Katmai) were built, they likewise aliased the x87 (and thus, MMX) registers to the XMM SSE registers, but this was hidden from programs. It wasn't until at least the Coppermine revision that they were separate registers again.

I remember hearing a rumour as a young teen that the Coppermine codename meant it actually had copper wiring and that's what made it faster somehow. Copper has lower resistance than aluminium and can therefore help chips run faster - it makes sense! But it was just a codename and the coppermine had aluminium interconnects. My family got a PIII 533Mhz coppermine, in the early sideways Slot 1 configuration. Blazing fas…

Copper interconnects might have been introduced around then, but I suspect the naming is more coincidental than anything.

I remember just after IBM got copper interconnects working, there was a stock market dive, I ranted to my partner about how crazy it is for a company to achieve a sought after goal and have its value decrease. The next day there was a news story about the entire market decline being stalled by the force of IBM buying back it's own shares. My partner told me I should rant less and invest more.

Re: SIMD in the 90s: Programming Intel's Pentium MMX

#19

Post by Nition »

Lerc wrote: post #18
Nition wrote: post #14

Earlier quoted context omitted.

I remember hearing a rumour as a young teen that the Coppermine codename meant it actually had copper wiring and that's what made it faster somehow. Copper has lower resistance than aluminium and can therefore help chips run faster - it makes sense! But it was just a codename and the coppermine had aluminium interconnects. My family got a PIII 533Mhz coppermine, in the early sideways Slot 1 configuration. Blazing fas…

Copper interconnects might have been introduced around then, but I suspect the naming is more coincidental than anything. I remember just after IBM got copper interconnects working, there was a stock market dive, I ranted to my partner about how crazy it is for a company to achieve a sought after goal and have its value decrease. The next day there was a news story about the entire market decline being stalled by the…

Haha, yeah the rumour came around at a time when there was real work going on with copper interconnects which just confused the situation, but the coppermine didn't use them.

Re: SIMD in the 90s: Programming Intel's Pentium MMX

#20

Post by justsomehnguy »

ack_complete wrote: post #16
justsomehnguy wrote: post #13

Earlier quoted context omitted.

As someone on the other side... the difference was between 166 "regular" VS 133 MMX. And in less than two years it became irrelevant: '97 for MMX, '99 fo GeForce 256.

MMX in did not become irrelevant with the GeForce 256. Hardware video decoding was only in its infancy at the time and even the highest end GPUs only supported motion compensation acceleration for decoding only at best. Non-display image processing on the GPU was heavily bottlenecked by very slow read-back speeds from the GPU to the CPU across the AGP bus.

Well, GPUs in a modern understanding didn't came till GF4/GF4MX, when you could get something for less than $50.. at this moment MMX wasn't anywhere because SSE was. At this point you had an overlay display for the DivX/XviD and your average CPU could display the realtime video.
Post reply on HN