Intel details Skymont
chipsandcheese.com
Intel details Skymont
1–10 of 64 posts
Re: Intel details Skymont
#2It looks like the next generation of *mont cores will be as big and capable as Skylakes. With E cores like this, who needs P cores?
Also, Intel was definitely onto something with the split decoders IMO. The x86 instruction set hurts to decode 8-wide in a single thread, but most code is branchy and loopy, so you only hurt in this configuration if loops are really big. Tight loops come from the uop cache, and branchy code gets 3-way decoding.
Re: Intel details Skymont
#3So Skymont is the architecture of the Efficiency core of Lunar lake:
https://www.anandtech.com/show/21425/intel-lunar-lake-archit...
It's so new that the Wikipedia page hasn't been written yet, it still redirects to the old usage of the codename as the previous name of Cannon Lake. Or it should redirect to a Lunar Lake page:
https://en.wikipedia.org/?title=Skymont_(microarchitecture)&...
Re: Intel details Skymont
#4TIL rounding denormals to zero is what -ffast-math actually does.
Re: Intel details Skymont
#5TIL rounding denormals to zero is what -ffast-math actually does.
Not sure if I should be relieved or concerned that even Ted Unangst doesn't know what -ffast-math actually does.
(For the record, it does a whole lot of terrible things: https://stackoverflow.com/questions/7420665/what-does-gccs-f... )
Re: Intel details Skymont
#6TIL rounding denormals to zero is what -ffast-math actually does.
There's more. It also enables some limited (unsafe) rearrangement of your floating point expressions, as well as a few other settings inside the floating point system. Flushing denorms to 0 is only part of it.
It also will do things like using an approximate reciprocal square root instruction plus a refinement iteration instead of fsqrt then fdiv.
Re: Intel details Skymont
#7It looks like the next generation of *mont cores will be as big and capable as Skylakes. With E cores like this, who needs P cores? Also, Intel was definitely onto something with the split decoders IMO. The x86 instruction set hurts to decode 8-wide in a single thread, but most code is branchy and loopy, so you only hurt in this configuration if loops are really big. Tight loops come from the uop cache, and branchy c…
> 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 an x86-excluded (and, more importantly, third-party excluded) platform (Mac).
Re: Intel details Skymont
#8It looks like the next generation of *mont cores will be as big and capable as Skylakes. With E cores like this, who needs P cores? Also, Intel was definitely onto something with the split decoders IMO. The x86 instruction set hurts to decode 8-wide in a single thread, but most code is branchy and loopy, so you only hurt in this configuration if loops are really big. Tight loops come from the uop cache, and branchy c…
> 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?
Re: Intel details Skymont
#9TIL 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(xy)=sqrt(x)sqrt(y), exp(x)*exp(y)=exp(x+y)
However, it also (which I often find break code) assumes no operation will make a NaN or an Infinity -- these last two don't really help, and also break code in confusing ways. This being gcc, they don't just change things like std::isnan or std::isinf into an 'abort' (which would make sense, in -ffast-math they don't make sense), they just return nonsense instead.
Re: Intel details Skymont
#10Earlier 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?
The ISA is much less important than many people seem to think. The RISC vs CISC debate is beyond outdated at this point because no modern architecture actually works strictly like either under the hood. Organizations who did x86 architectures historically had much more emphasis on performance while organizations who did ARM had more emphasis on low power devices. The lingering engineering consequences of that history and the experience of the organizations doing design are orders of magnitude more relevant than the difference in actual ISA.