TIL rounding denormals to zero is what -ffast-math actually does.
I think the linking with the flush-to-zero code nonsense has been moved to a separate flag in recent GCCs.
Intel details Skymont
31–40 of 64 posts
Re: Intel details Skymont
#32Could these processors help Intel move further into AI inference?
They already have the Gaudi chip for AI, Skymont is a different kind
Re: Intel details Skymont
#33How do these modern Atoms compare to the Apple ARM chips? Does Apple make something comparable in terms of power/performance?
Re: Intel details Skymont
#34TIL rounding denormals to zero is what -ffast-math actually does.
-ffast-mast does a whole bunch of things, which I wish people's didn't so commonly combine. For example, I think the things it does which are sensible for most people are: * Rounding subnormals to zero * Disabling signed zeroes * Disables support for 'trapping' (throwing SIGFPE) Then there are the 'middle' things, which annoy some people: * Allow associative operations, and things like sqrt(x y)=sqrt(x) sqrt(y), exp(…
For me, the most important part is -fno-math-errno which allows the compiler to ignore that libm functions are allowed to set errno. This is perfectly safe (unless you rely on that rarely known side effect) and is usually the one flag I explicitly set.
Re: Intel details Skymont
#35Slightly offtopic. What would you suggest as an introductory text on modern CPU architectures?
Computer Architecture by Hennessy and Patterson is the classic introductory text.
It's dated, but Inside the Machine by Jon Stokes is also a good read if you're after something a bit lighter.
Re: Intel details Skymont
#36Earlier quoted context omitted.
There seems to be a very common misconception about branch prediction, that its only job is to predict the direction of the branch. In reality, the problem is so much deeper. The instruction fetch stage simply can't see the branch at all. Not just conditional branches, but unconditional jumps, calls and even returns too. Even a simple 5 stage "classic RISC" pipeline takes a full two cycles to load the instruction fro…
ok that makes much more sense how; thanks! follow up question: if the branch is predicted to not be taken, why does the predictor have to use resources to record its location and the destination?
Intel are probably using a TAGE style predator along the lines of ITTAGE or COTTAGE from http://www.irisa.fr/caps/people/seznec/JILP-COTTAGE.pdf
These predictors change their prediction (both direction and destination) based on the history of the last few hundred branches and if they were taken or not-taken. So the predictor needs to know where those branches were, even if they aren't taken.
Indirect TAGE predictors are very powerful. They can correctly predict jump tables and virtual function calls.
In general, branch predictors don't utilise their tables very efficiently. Cheap and fast lookups are way more important than minimising size.
Re: Intel details Skymont
#37TIL rounding denormals to zero is what -ffast-math actually does.
I also learned from experience that -ffast-math only enables the FTZ/DAZ optimization on the main thread, at least on Linux/X86. I don’t know if its universal or this has changed since I debugged it ~5-6 years ago, but that proved to be a bit hard to get to the bottom of since I immediately suspected the big CPU spike when the volume was set very low was caused by denormals, yet we were using the —ffast-math gcc flag…
With clang on my intel mac it doesn't work at all, the only solution is to set those flags using _mm_setcsr().
Re: Intel details Skymont
#38Slightly offtopic. What would you suggest as an introductory text on modern CPU architectures?
Computer Architecture by Hennessy and Patterson is the classic introductory text. It's dated, but Inside the Machine by Jon Stokes is also a good read if you're after something a bit lighter.
Thank you!
Re: Intel details Skymont
#39Earlier quoted context omitted.
-ffast-mast does a whole bunch of things, which I wish people's didn't so commonly combine. For example, I think the things it does which are sensible for most people are: * Rounding subnormals to zero * Disabling signed zeroes * Disables support for 'trapping' (throwing SIGFPE) Then there are the 'middle' things, which annoy some people: * Allow associative operations, and things like sqrt(x y)=sqrt(x) sqrt(y), exp(…
For me, the most important part is -fno-math-errno which allows the compiler to ignore that libm functions are allowed to set errno. This is perfectly safe (unless you rely on that rarely known side effect) and is usually the one flag I explicitly set.
And the primary benefit of doing that is so the compiler can inline math functions like sqrt() as a tiny number of instructions (on modern CPUs) instead of having to call the standard C function, which is much slower.
Re: Intel details Skymont
#40Earlier quoted context omitted.
> With E cores like this, who needs P cores? Because, presumably, the P-cores are even beefier. Intel and AMD are still trying to gain time on the slow march to ARM (particularly Apple) catching up. Both of their long term strategies seem to differ (AMD edging back into ARM itself, Intel being a little more close lipped), but they can't lose their one major edge (raw performance) or potentially more users switch to a…
Is ARM really that special? Why do you believe this is the case?
ARM is simply the ISA the industry is pivoting to and where most forward investment is going.
I don't know where I implied it was special.