Results for other systems

[travisdowns]

As I mentioned on HN, I can run this on SKL, SKX and CNL (CannonLake) for you.

Are there any specific arguments or format you want the results in, or just capture the output of cult and include it in this issue?

[kobalicek]

Thanks! No arguments are necessary, but --output=somefile.json is a handy option.

BTW I have never tested this with AVX-512, I have no idea whether it would all work flawlessly, so fingers crossed :)

[travisdowns]

OK, I will run 2x with: --output=rounded.json and --output=raw.json --no-rounding and provide you those files.

FWIW on my SKL system I get some wrong results, like:

  bt r16, r16                           : Lat:  0.50 Rcp:  0.50
  bt r16, i8                            : Lat:  0.50 Rcp:  0.50
  bt r32, r32                           : Lat:  0.50 Rcp:  0.50
  bt r32, i8                            : Lat:  0.50 Rcp:  0.50
  bt r64, r64                           : Lat:  0.50 Rcp:  0.50
  bt r64, i8                            : Lat:  0.50 Rcp:  0.50

Where 0.5 lat is ... unlikely. I guess the problem is maybe CULT doesn't know that the first argument to bt is write only? That is, if you do bt eax, ecx you aren't testing latency (I don't know what asm is actually generated, it's just a guess).

[kobalicek]

Yeah, I think it's the opposite - bt reg, reg is read-only for registers, it only modifies the carry flag, so it's hard to make the asm that has dependencies without introducing other instructions in there. This is something I would like to fix in a future version.

BTW: you don't have to use --no-rounding, there is always small error that gets corrected by the rounding.

[travisdowns]

@kobalicek - oops, good point I forgot that bt is totally read only.

Here's another one I noticed:

 blendvpd xmm, xmm, xmm0               : Lat:  0.50 Rcp:  0.50

I also got a lot of 0.2 recip throughput results which should be wrong (max 4 ops/cycle), but it seemed to go away after I turned off turbo. Do I need to turn off turbo to get good results?

[kobalicek]

Yeah I'm also getting 0.2 reciprocal throughput on some instructions on Ryzen, but apparently Ryzen is capable of executing 5 instructions per cycle if they are in uop cache. However, if it says 0.2 it's probably true even on Intel although it's possible that I miscalculate the cycles wasted for each loop iteration, which is currently set to 1 cycle - hard to say whether that could cause reporting 0.2 instead of 0.25 in such cases.

[kobalicek]

I have opened #7 to track the latency issue

[travisdowns]

Yeah I'm also getting 0.2 reciprocal throughput on some instructions on Ryzen, but apparently Ryzen is capable of executing 5 instructions per cycle if they are in uop cache. However, if it says 0.2 it's probably true even on Intel although it's possible that I miscalculate the cycles wasted for each loop iteration, which is currently set to 1 cycle - hard to say whether that could cause reporting 0.2 instead of 0.25 in such cases.

Yes, on Ryzen that is expected.

It's definitely not 0.2 on Intel though, I've tested this stuff exhaustively down to the cycle using lots of different calibration and cycle measurement techniques and I have never seen any case you can do 5 ops/cycle.

As I mentioned it could be turbo effects - how are you doing the timing? Do you use a clock-based timing and then convert to cycles using a calibration based on a well-known timing, say a loop of dependent instructions?

[travisdowns]

My first CNL results look all wrong:

  add r8, r8                            : Lat:  0.66 Rcp:  0.20
  add r8, i8                            : Lat:  0.66 Rcp:  0.20
  add r16, r16                          : Lat:  0.66 Rcp:  0.20
  add r16, i16                          : Lat:  2.25 Rcp:  2.25
  add r32, r32                          : Lat:  0.66 Rcp:  0.20
  add r32, i32                          : Lat:  0.66 Rcp:  0.20
  add r64, r64                          : Lat:  0.66 Rcp:  0.20

I will try to turn off turbo.

Update: Looks OK with turbo off.

[kobalicek]

Hmm, I don't know how to fix this though. It seems the readings are incorrect in that case. It uses rdtscp when available, I followed Intel manual here.

[travisdowns]

Yes, but rdtscp measures wall-clock time, not cycles. So it will always be wrong (in cycles) if the chip has turbo.

[kobalicek]

I think the manual I followed was written when the turbo didn't exist :) Do you have any suggestion about improving it? The logic is in basebench.cpp if you wanna see the current code.

[travisdowns]

The "fix" is either to force the user to turbo off turbo, you can see how I do this programatically here:

https://github.com/travisdowns/uarch-bench/blob/master/uarch-bench.sh#L66

Or to do a calibration that allows you to convert from "nominal cycles" as read by rdtsc into CPU cycles, one way is shown here:

https://github.com/travisdowns/avx-turbo/blob/master/tsc-support.cpp

[travisdowns]

Yeah many moons ago, there was no frequency scaling (neither turbo nor anti-turbo, i.e., scaling below the nominal freq) so rdtsc and real cycles were always the same.

Then there was a brief period after Intel added fequency scaling where rdtsc still measured true CPU cycles, and thus no longer wall-clock time (that's the easy way to implement this counter in hardware, after all). But everyone hated that because rdtsc is mostly use for efficient gettimeofday or QueryPerformanceCounter and other calls which want real time, not some non-constant "cycles", so it was quickly changed to run in wall clock time and that's were we are today (that was like a decade ago though).

Turning off turbo is good because you get much more stable results since you don't have the forces frequency switch when another core spins up (then the current core has to slow down because modern chips have turbo multipliers that depend on how many cores are running), but there are also a lot of problems like even figuring out how to turn off turbo on all systems, user has to be root, etc.

[kobalicek]

It's kinda pity I don't have Intel hardware anymore at the moment. I would even experiment with this a bit, but it's impossible to make it right on the first time. But, I would research this a bit.

If I think of it I think this would never be 100% reliable tool, but if I can make it close enough I would be happy.

[travisdowns]

@kobalicek - my experience with uarch-bench indicates that the calibration approach is fairly robust. At most you sometimes get a wrong calibration due to a wrong assumption: e.g., when I ran on POWER9 I found out that dependent instructions always have a latency of at least 2, so the calculated frequency was half of the real frequency, but at least the error was obvious and you can correct it once you notice it.

Do you have AMD hardware, or something non-x86? I may be interested in some AMD numbers for some random microbenchmarks since I don't have easy access to AMD to test.