Why those particular integer multiplies?
fgiesen.wordpress.com
Why those particular integer multiplies?
1–10 of 39 posts
Re: Why those particular integer multiplies?
#2> PMADDUBSW produces a word result which, in turns out, does not quite work. The problem is that multiplying unsigned by signed bytes means the individual product terms are in range [-128*255, 128*255] = [-32640,32640]. Our result is supposed to be a signed word, which means its value range is [-32768,32767]. If the two individual products are either near the negative or positive end of the possible output range, the sum overflows.
can someone explain this to me? isn't 32640 < 32767? how's this an overflow?
Re: Why those particular integer multiplies?
#3> PMADDUBSW produces a word result which, in turns out, does not quite work. The problem is that multiplying unsigned by signed bytes means the individual product terms are in range [-128*255, 128*255] = [-32640,32640]. Our result is supposed to be a signed word, which means its value range is [-32768,32767]. If the two individual products are either near the negative or positive end of the possible output range, the…
The output of the instruction is, for each 16-bit lane, the sum of two products of one i8 and one u8.
32640 * 2 > 32767
As an aside, the quoted section of the article seems to have an error. The maximum value of an i8 is 127 and the maximum value of one of these products is 32385.
Re: Why those particular integer multiplies?
#4Maybe it’s me in the morning, but for some reason it was a very hard read for the text about cpu instructions. Feels like it loads you with details for ages.
Re: Why those particular integer multiplies?
#5How can software run on different CPUs when they support different operations?
When you download "debian-live-12.7.0-amd64-kde.iso", all the programs in the repos support all current Intel and AMD CPUs, right? Do they just target the lowest common denominator of operations? Or do they somehow adapt to the operations supported by the user's CPU?
Do dynamic languages (Javascript, Python, PHP...) get a speed boost because they can compile just in time and use all the features of the user's CPU?
Re: Why those particular integer multiplies?
#6Found a bug in the article.
Maximum for signed bytes is +127, not +128. Minimum is correct, it's -128.
Re: Why those particular integer multiplies?
#7How can software run on different CPUs when they support different operations? When you download "debian-live-12.7.0-amd64-kde.iso", all the programs in the repos support all current Intel and AMD CPUs, right? Do they just target the lowest common denominator of operations? Or do they somehow adapt to the operations supported by the user's CPU? Do dynamic languages (Javascript, Python, PHP...) get a speed boost becau…
> Do they just target the lowest common denominator of operations? Or do they somehow adapt to the operations supported by the user's CPU?
Mostly the former. Some highly optimized bits of software do the latter—they are built with multiple code paths optimized for different hardware capabilities, and select which one to use at runtime.
> Do dynamic languages (Javascript, Python, PHP...) get a speed boost because they can compile just in time and use all the features of the user's CPU?
Hypothetically yes, but in practice no for the languages you mentioned because they don't map well to things like SIMD. Some JIT-based numerical computing systems as well as JIT-based ML compilers do reap those benefits.
Re: Why those particular integer multiplies?
#8How can software run on different CPUs when they support different operations? When you download "debian-live-12.7.0-amd64-kde.iso", all the programs in the repos support all current Intel and AMD CPUs, right? Do they just target the lowest common denominator of operations? Or do they somehow adapt to the operations supported by the user's CPU? Do dynamic languages (Javascript, Python, PHP...) get a speed boost becau…
SSE2 is a requirement for x86-64, which gives at least a reasonable(128bit wide SIMD) baseline.
SSE4 is from 2008, so making it a requirement isn't unreasonable.
Even AVX2 is from 2013, so some apps require it nowadays.
It is extremely difficult for a compiler to convert scalar code to SIMD automatically, even static C++ compilers really suck at it.
A dynamic compiler for javascript would have no real hope of any meaningful gains.
Re: Why those particular integer multiplies?
#9How can software run on different CPUs when they support different operations? When you download "debian-live-12.7.0-amd64-kde.iso", all the programs in the repos support all current Intel and AMD CPUs, right? Do they just target the lowest common denominator of operations? Or do they somehow adapt to the operations supported by the user's CPU? Do dynamic languages (Javascript, Python, PHP...) get a speed boost becau…
> Do they just target the lowest common denominator of operations? Or do they somehow adapt to the operations supported by the user's CPU?
Mostly the former, some specialized software does the latter. The lowest common denominator is called the baseline, and it differs over time and between distributions. Debian for example still supports x86-64-v1 (the original 64-bit extension to x86), but RHEL 10 will require x86-64-v3, which includes SSE4 and AVX2 support.
Re: Why those particular integer multiplies?
#10How can software run on different CPUs when they support different operations? When you download "debian-live-12.7.0-amd64-kde.iso", all the programs in the repos support all current Intel and AMD CPUs, right? Do they just target the lowest common denominator of operations? Or do they somehow adapt to the operations supported by the user's CPU? Do dynamic languages (Javascript, Python, PHP...) get a speed boost becau…
Others gave you the general answer, but in OPs line of work they just manually rewrite and tune all of the core algorithms a dozen times for different CPU architectures and dispatch to the most suitable one at runtime. I don't have a link to hand but IIRC they go a step beyond dispatching based on CPU features, and dispatch different code paths for CPUs with the same features but significantly different instruction costs.
RADs codecs are expensive but that's the expertise you're paying for.