Correct solution for dep_chains_2 lab?

[0legmak]

My solution has a decent speed-up on local hardware but fails some official tests. I also tried copy-pasting the solution from the "golden" branch (I guess it contains lab solutions from the author of this course) and it also failed official tests. Does someone have a solution that passes these tests?

My solution: 969eb17
Copy-pasted golden solution: f6b4f6a

My local benchmark results

CPU	main	golden	private/0legmak
Lynnfield	50.0ms	62.1ms	41.5ms
Tiger Lake-U	23.0ms	18.2ms	13.2ms

[dendibakh]

Hi @0legmak, could it be due to the default constructor in rngForValidation?

The baseline solution should work cc0c08c

[0legmak]

Hi Denis! According to my understanding, the rngForValidation code should only affect compilation and correctness tests, not performance. Am I wrong here?

[0legmak]

Tried to submit an exact copy of the solution from golden branch and it failed tests: e54b01b

[dendibakh]

Hmmm, OK, I will look into that.

[dendibakh]

@0legmak, I just tried applying the solution from the golden branch, and it validates OK. Please try it again on clean sources.

[0legmak]

Here is how I test:

1. Create a new branch from golden branch:
   git checkout origin/golden
git checkout -b golden_0legmak
2. Rebase it on top of main branch to have all recent changes:
   git rebase origin/main
3. Push branch into repository:
   git push -u origin golden_0legmak

Then add a meaningless commit with "[CheckAll]" message to run all labs, and after that one more commit to run just DepChains2 lab. Here are results: https://github.com/dendibakh/perf-ninja/commits/golden_0legmak/
Lab failed on AlderLake and Zen on both runs and CoffeeLake on one run.

[dendibakh]

Ah, ok. I thought you meant the correctness tests are failing. But you're talking about performance tests. :) Now I see...

[dendibakh]

Sorry, I didn't understand your concern as I thought you were talking about correctness, not performance.

I think the reason we don't see speedups on older platforms, e.g. CoffeeLake and Zen3 is that they are 4-wide machines and cannot overlap execution of multiple dependency chains. Alderlake (Golden Cove) is 6-wide microarchitecture, thus more available pipeline slots every cycle. Apple M1 is 8-wide, that's why the speedup is more pronounced on that platform.

BTW, I have this comment for CoffeeLake in buildbot/runCI.py:
# (It seems it doesn't help Coffelake) Labs["core_bound"]["dep_chains_2"] = LabParams(threshold=10.0)
FIXME: CI should not run this benchmark on CoffeeLake. :)
Maybe I should add the same for Zen3.

[0legmak]

Note that the golden solution also fails automatic benchmarks on AlderLake. Also notice that my solution gets more than 10% speed up even on very old platform when running locally (results in starting post), but fails the automatic benchmarks on Zen and CoffeeLake and barely makes it with 12% on AlderLake.

[dendibakh]

Ok, can you explain please what is the secret sauce of your solution? Why it has more speed up?

[0legmak]

This is a good question, I don't know the answer to it. But I am more curious about why I don't see similar speed up when running automatic benchmarks. I mean if I get +40% speed up on TigerLake, but there is just +12% on AlderLake?

[dendibakh]

Yeah, I don't have a good explanation for that. :)
Tiger Lake is based on Willow Cove, which is a 5-wide uarch. According to my reasoning above it should see lower speedups than AlderLake. Maybe this code hits a glass jaw in the Willow Cove uarch. Hard to tell without comprehensive perf analysis.
All my benchmarks are "peaky", i.e. they have a single hot loop, thus a small tweak in generated code or the layout of assembly instructions has a large impact on performance. Generally speaking, this is bad, but I have to live with it. :)