Hacker News Reader

Comment by dragontamer | Hacker News Reader

We're all processor geeks around here, right?

AMD Ryzen is a good architecture at a good price. But compared to Intel, there are two important differences IMO:

1. pext / pdep are emulated -- It takes many cycles for pext and pdep instructions to be executed, while Intel can execute them once per clock. This is a crazy awesome instruction for any low level programmer, and its a shame it isn't possible to utilize it on AMD Zen processors.

2. Zen is a bit slower with 256-bit AVX Instructions.

----------

Bonuses:

1. Zen offers more cores per dollar

2. Zen offers two AES-encryption units per core. This means you can run two AES-instructions per clock tick. Dunno why AMD does this, but its kinda cool in some obscure cases I've coded.

View on HN

Zen 2 is adding 256 bit registers for 256 bit AVX instead of doing it in 2 passes with 128 bit registers.

If AMD can release a 16 core native AVX threadripper without thermal throttling that would be awesome. The same could be said with Intel and AVX-512. Hopefully this year we will see one or the other.

I hope AVX-512 is studied for its lessons on how not to do an ISA. I have very few technical complaints about it, but the following were a deal breaker

1. Limiting it to a subset of chips, and initially not releasing it for client chips at all. Creating ISAs for a small part of the market is the best way to ensure it does not see any use.

2. Reasoning about AVX512 performance is ridiculously difficult for most workloads because of the clock penalty. Unless you have cases where you are all AVX512 all the time, you will likely see performance drops.

I suspect the dual AES units are a side effect of Zen having two 128-bit SIMD units. The AES instructions use the SIMD registers so naturally the AES implementation is integrated into the SIMD unit. Presumably it was easier to duplicate the AES engine along with the rest of the SIMD unit than to split it out.

pext/pdep are awesome, but I imagine you'd never notice the difference in real world usage. You'd have to use a program often where those instructions are on the critical path and comprise a significant percentage of execution time. The chances of that are slim to none. You may well notice the extra cores though, to a point, depending what you do.

I was writing a program similar to the 4-coloring problem. I represented colors as 2-bits (color 0, 1, 2, and 3).

I also created a bitmask representation of relations, which would represent 1-variable in 4-bits, 2-variables in 16-bits, 3-variables in 64-bits, and 4-variables in 256 bits.

Ex: Texas / Oklahoma / Arizona relation would be a 64-bit number ("true" means a color-set is in the relation. "False" means the color-set is not in the relation), and extracting or packing the data into these three variables would be a pdep or pext operation.

Extracting data (pext) would be a "select" operation. While PDEP + OR would be a "update" operation over the relation. I've written a join for fun, but I haven't gotten much further than that. First, because pdep / pext were slow on my machine. Second, because I figured out an alternative solution to my particular problem.

---------

I think the pext / pdep instructions have HUGE implications to 4-coloring problem, 3-SAT, Constraint Solvers, etc. etc. More researchers probably should look into those two instructions.

Just look at Binary Decision Diagrams, and other such combinatorial data structures, and you can definitely see the potential uses of PEXT / PDEP all over the place.

https://en.wikipedia.org/wiki/Binary_decision_diagram

Wouldn't this sort of thing be also very common in applying bit map masks to bit arrays in frameworks like numpy?

I can't say that I've used numpy before. But this function looks similar to pext / pdep:

https://docs.scipy.org/doc/numpy-1.15.0/reference/generated/...

I will agree with dragon tamer that for some real-world codes PEXT/PDEP sits right in the middle of the hot path. It isn't just the clock cycle savings either, for some logic it can substantially simplify the code path. There's a lot of neat wizardry that can be done by composing sequences of those two instructions (mixed with other basic integer ops).

I don't use them often, but there are cases where I would not want to try to write code without them.

A while back, I was working on a fun little video game side project which used BMI2 instructions to compute Morton codes on the critical path.

Voxels were stored in a buffer sorted in Morton order. The idea was to balance performance improvements realized by increased spatial locality against the cost of computing the Morton codes. The trade-off was only worthwhile on Intel because of the use of pdep/pext in optimized encode/decode functions.

I imagine something similar would probably apply to texture lookups in a software 3D renderer.

> I imagine something similar would probably apply to texture lookups in a software 3D renderer.

Except that for a 3D rasterizer you'd probably be better off calculating Morton code for 8 pixels at once in a SIMD register and then using vpgatherdd to fetch 8 ARGB pixel values "in parallel" (in theory, in practice AVX2 gather might not be any faster than scalar loads).

https://www.felixcloutier.com/x86/vpgatherdd:vpgatherqd

Hobby code: I slowly developing a Gin rummy [1] engine. Card sets are represented by 64 bit integers and all operations (findig melds, sets, etc...) are implemented with bitwise operators.

I have used pext/pdep for the iterator implementation (iterate over all subset of a card set, or all combination of n cards).

(e.g. To iterate over all 10 card combination brute-force and filter and print out all the ones which can be knocked (evaluating 15_820_024_220 hands) takes 70 seconds - one threaded - on my 7th gen intel i3.)

[1] https://en.wikipedia.org/wiki/Gin_rummy

Do any compilers use the pext/pdep instruction?

PEXT / PDEP are not instructions that would compile automatically in anything I'm aware of.

Its a new fundamental bitwise operator. Some other programmers have called it a "bitwise gather (pext) or bitwise scatter (pdep)" (EDIT: Had it backwards the first time). Its a very powerful way to think about bits that Intel just invented in those instructions.

If you have any data-structure that is bitwise, I can almost guarantee you that PEXT or PDEP will be useful in some operation. These instructions have been used to calculate bishop / rook moves in less than five operations.

https://www.chessprogramming.org/BMI2#PEXTBitboards

And yes, remember that bishops and rooks can be blocked by other pieces. So given all the pieces on a chessboard, and the location of the bishop in question, calculate all possible locations the bishop can move (after accounting for "being blocked").

Don't omptimizers already do quite a lot of analysis to output what you mean rather than what you say? I can think of quite a lot of bitwise shift/and and shift/or patterns that should be automatically convertible to single-instruction pext/pdep's

Not a processor geek per se, but do appreciate some insights into a bit of these details. Aside, I'm really happy to see AMD being competitive across most products and even better bang for the buck at a lot of price points. Waiting on Zen 2 architecture to upgrade my desktop (will be over 5yo at that point)... depending on initial release or Threadripper version.

I can't even figure out what those instructions do - there is no way they get heavy use in common software any time soon.

Reply on news.ycombinator.com