 | Lars Fosdal on Security alarm provider Woonve… |
 | Thomas Mueller on Question got closed in May 202… |
 | Thaddy de Koning on Formulier voor bewindvoerders… |
| Thaddy de Koning on Formulier voor bewindvoerders… |
| Thaddy de Koning on Formulier voor bewindvoerders… |
Posted by jpluimers on 2025/11/25
[Wayback/Archive] Online x86 and x64 Intel Instruction Assembler
The source starts in these two files:
Posted in Assembly Language, Conference Topics, Conferences, Development, Event, Software Development, x64, x86 | Leave a Comment »
Posted by jpluimers on 2025/03/13
From a while back, but still interesting:
Especially the first link explains the algorithm very well and is similar to links referred to from the Stack Overflow question as it is based on counting ones (and leading ones are basically leading zeros but bit-inverted).
It also explains a cool thing for leading zeros: modern CPU have instructions which .NET Core.
Posted in .NET, AArch64/arm64, Algorithms, ARM, Assembly Language, C, C#, C++, Delphi, Development, Software Development, x64, x86 | Tagged: csharp, dotnet, dotnetcore | Leave a Comment »
Posted by jpluimers on 2025/01/14
For my link archive: below a series of articles my Raymond Chen on “The AArch64 processor (aka arm64)” in the order of appearance from a few years back and still very relevant today.
It is part of a few more series on processors that (were) supported by Windows. A good reference to find which version supported which processor architecture is the tables in List of Microsoft Windows versions – Wikipedia.
Posted in AArch64/arm64, ARM, Assembly Language, Development, History, MIPS R4000, PowerPC, Software Development, The Old New Thing, Windows Development, x64, x86 | Leave a Comment »
Posted by jpluimers on 2024/09/18
A few years back the way Intel Microcode updates were distributed deciphered so it became possible to extract and research the microcode of some processor models.
Repository: [Wayback/Archive] chip-red-pill/MicrocodeDecryptor
Posted in Assembly Language, Development, Software Development, x64, x86 | Leave a Comment »
Posted by jpluimers on 2024/06/18
It is more than a decade old but still the best reference around [Wayback/Archive] -= pnx.tf =- has [Wayback] x86_opcode_structure_and_instruction_overview.pdf
I found it via [Wayback/Archive] Alice Climent-Pommeret on Twitter: “I’ve just discovered this amazing document showing super clearly the relation between the opcode and the instruction 🤯 …”
Posted in Assembly Language, Development, Software Development, x64, x86 | Leave a Comment »
Posted by jpluimers on 2024/06/13
This is from a long time ago [Wayback/Archive] Does Delphi support all MMX/SSE instructions? – Stack Overflow:
Delphi 2007 supports the MMX and SSE instruction sets. Certainly, Delphi 2010 and XE support up to the SSE4.2 instruction sets (but so far no support for AVX).
The [Wayback] Delphi 2005 Language Guide explained a bit, but no more recent PDF is available and the [Wayback/Archive] Embarcadero/IDERA Documentation Wiki is very much outdated on this information as per [Wayback/Archive] Talk:Assembler Syntax – RAD Studio:
Re: “Instruction Opcodes” The information on available instruction sets is outdated. D2010 and Fulcrum support the SIMD instruction sets all the way up to SSE4.2 (i.e., SSE, SSE2, SSE3, SSSE3, SSE4.1 and SSE4.2).
–jeroen
Posted in Assembly Language, Delphi, Development, Software Development, x64, x86 | Leave a Comment »
Posted by jpluimers on 2023/02/14
If I ever need to go deep into optimisation again, there is lots I can still learn from [Wayback/Archive] Software optimization resources. C++ and assembly. Windows, Linux, BSD, Mac OS X
Thanks [Archive] Kris on Twitter: “@Kharkerlake @unixtippse Agner Fog ist eigentlich ein Anthropologe, aber er reversed interne Strukturen von Intel CPUs, und …, speziell 3. The microarchitecture of Intel, AMD and VIA CPUs: An optimization guide for assembly programmers and compiler makers ist die HPC Bibel.” / Twitter!
Must watch video with Agner about Warlike and Peaceful Societies below the signature.
–jeroen
Posted in Assembly Language, C++, Development, Software Development, x64, x86 | Leave a Comment »
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
0or0.1is 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 »
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.
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 %).
why doesn’t radfft support AVX on PC?
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.
Posted in Assembly Language, Development, Software Development, x64, x86 | Leave a Comment »
Posted by jpluimers on 2019/02/28
Geek pr0n at [WayBack] performance – Why is this C++ code faster than my hand-written assembly for testing the Collatz conjecture? – Stack Overflow
Via: [WayBack] Very nice #Geekpr0n “Why is C++ faster than my hand-written assembly code?” The comments are of high quality i… – Jan Wildeboer – Google+
–jeroen
Posted in Assembly Language, C, C++, Development, Software Development, x64, x86 | Leave a Comment »
The Wiert Corner - irregular stream of stuff 