The Wiert Corner – irregular stream of stuff

Jeroen W. Pluimers on .NET, C#, Delphi, databases, and personal interests

  • My badges

  • Twitter Updates

  • My Flickr Stream

  • Pages

  • All categories

  • Enter your email address to subscribe to this blog and receive notifications of new posts by email.

    Join 2,806 other followers

Archive for the ‘Assembly Language’ Category

When floating point code suddenly becomes orders magnitudes slower (via C++ – Why does changing 0.1f to 0 slow down performance by 10x? – Stack Overflow)

Posted by jpluimers on 2022/01/26

When working with converging algorithms, sometimes floating code can become very slow. That is: orders of magnitude slower than you would expect.

A very interesting answer to [Wayback] c++ – Why does changing 0.1f to 0 slow down performance by 10x? – Stack Overflow.

I’ve only quoted a few bits, read the full question and answer for more background information.

Welcome to the world of denormalized floating-point! They can wreak havoc on performance!!!

Denormal (or subnormal) numbers are kind of a hack to get some extra values very close to zero out of the floating point representation. Operations on denormalized floating-point can be tens to hundreds of times slower than on normalized floating-point. This is because many processors can’t handle them directly and must trap and resolve them using microcode.

If you print out the numbers after 10,000 iterations, you will see that they have converged to different values depending on whether 0 or 0.1 is used.

Basically, the convergence uses some values closer to zero than a normal floating point representation dan store, so a trick is used called “denormal numbers or denormalized numbers (now often called subnormal numbers)” as described in Denormal number – Wikipedia:

In a normal floating-point value, there are no leading zeros in the significand; rather, leading zeros are removed by adjusting the exponent (for example, the number 0.0123 would be written as 1.23 × 10−2). Denormal numbers are numbers where this representation would result in an exponent that is below the smallest representable exponent (the exponent usually having a limited range). Such numbers are represented using leading zeros in the significand.

Since a denormal number is a boundary case, many processors do not optimise for this.

–jeroen

Posted in .NET, Algorithms, ARM, Assembly Language, C, C#, C++, Delphi, Development, Software Development, x64, x86 | Leave a Comment »

Moore’s law has almost ended: back to the future

Posted by jpluimers on 2021/09/29

[WayBack] We’re approaching the limits of computer power – we need new programmers now | John Naughton | Opinion | The Guardian

Ever-faster processors led to bloated software, but physical limits may force a return to the concise code of the past

So back to optimisation and maybe even assembly language.

Which brings back the days gone by.

–jeroen

Read the rest of this entry »

Posted in Algorithms, Assembly Language, Development, Software Development | Leave a Comment »

A Tale of Many Divisions – Naive Prime Factorization Across a Handful of Architectures

Posted by jpluimers on 2020/06/16

[WayBack] A Tale of Many Divisions – Naive Prime Factorization Across a Handful of Architectures

Source code: [WayBack] GitHub – blu/euclid: An extremely naive prime factorizer

Via: [WayBack] Blu looks at how a small piece of code with divisions surprisingly behave on various architecture: #Arm, #MIPS, and #x86. – Jean-Luc Aufranc – Google+

–jeroen

Posted in Assembly Language, C++, Development, Software Development | Leave a Comment »

Insentricity :: Kermit on the JAIR 8080 ::

Posted by jpluimers on 2019/05/22

Cool: [WayBackInsentricity :: Kermit on the JAIR 8080 ::

Repository: [WayBackFozzTexx/Kermit-CPM: Columbia University’s Kermit for CP/M

–jeroen

Posted in Assembly Language, Development, History, Software Development | Leave a Comment »

Some notes on loosing performance because of using AVX

Posted by jpluimers on 2019/03/20

It looks like AVX can be a curse most of the times. Below are some (many) links that lead me to this conclusion, based on a thread started by Kelly Sommers.

My conclusion

Running AVX instructions will affect the processor frequency, which means that non-AVX code will slow down, so you will only benefit when the gain of using AVX code outweighs the non-AVX loss on anything running on that processor in the same time frame.

In practice, this means you need to long term gain from AVX on many cores. If you don’t, then the performance penalty on all cores, including the initial AVX performance, will degrade, often a lot (dozens of %).

Tweets and pages linked by them

Kelly raised a bunch of interesting questions and remarks because of the above:

I collected the above links because of [WayBack] GitHub – maximmasiutin/FastMM4-AVX: FastMM4 fork with AVX support and multi-threaded enhancements (faster locking), where it is unclear which parts of the gains are because of AVX and which parts are because of other optimizations. It looks like that under heavy loads on data center like conditions, the total gain is about 30%. The loss for traditional processing there has not been measured, but from the above my estimate it is at least 20%.

Full tweets below.

Read the rest of this entry »

Posted in Assembly Language, Development, Software Development, x64, x86 | Leave a Comment »

 
%d bloggers like this: