compiler teknik

Optimizations in C++ Compilers

https://dl.acm.org/doi/pdf/10.1145/3371595.3372264

Your blog gave us useful information that we can use. All of the tips in your post are great. Many thanks for giving. Keep blogging five nights at freddy's

#1 Første eksempel fra pdf'en:

for (int i = 0; i < 100; ++i)
{
.   func(i * 1234);
}

optimeres af compiler til:

for (int iTimes1234 = 0; iTimes1234 < 100 * 1234; i += 1234)
{
.   func(iTimes1234);
}

Den går ikke nødvendigvis med floating point! Der kan være akkumulerende rounding errors.

Det kan også gå galt med bounds. Hvis i f.eks. havde været uint8_t ...

Det er en interessant og sjov pdf. Men jeg får lidt af en "skønne, spildte kræfter" vibe fra mange af eksemplerne. Som jeg forstår det, er det næsten altid cache og memory situationen der er flaskehalsen i en moderne CPU. Om man kan spare nogle cycles her og der i noget processering, betyder ofte ikke noget.

Og så er der komplekse ting som population-count løkken, der reduceres til en "popcnt" instruktionen af clang. Det er da meget sødt, men også et udtryk for den ekstreme CISC tankegang der råder i x86 og man aner hvor tricky det må have været at lave compilere der kan udnytte disse instruktioner. Komisk nok, når CPUen så skal eksekvere disse komplekse operationer bliver de alligevel oversat til mere håndterbare instruktioner inde i CPUen. Skønne, spildte kræfter...

... og hvad er så det endelige resultat? ARM løber fra x64 / x86. Intel og AMD har i årevis fejlet med hensyn til at levere power-effektive chips til tablets og smartphone markedet. ARM er bare bedre. Og så kom Apple med deres custom ARM chips og gav x86 fuldstændig bøllebank også i powersegmentet.

Så, x86 synes temmelig forældet i dag, og dermed også meget af CISC tankegangen. Men jeg skal ikke kunne sige om det faktisk mere er patentsituationen, der er den største akilleshæl for x86. Det er mig bekendt kun Intel og AMD der må lave x86 chips. ... x86 kan snildt vise sig at blive endnu en teknologi der patenterer sig selv ihjel. Death by IP lawyers. ;)

#3

Hvis man bruger en for løkke med en FP counter så er man vist allerede ude i noget snavs.

Men hvis det nu alligevel er tilfældet så er spørgsmålet jo hvad compileren garanterer med hensyn til FP beregninger.

Jeg kan ikke forestille mig at C/C++ garanterer noget. Det er ikke et krav at C/C++ skal bruge IEEE FP, så hvis de bruger et andet format vil det under alle omstændigheder give andre resultater.

#5

Praktisk taget alle bruger IEEE FP idag men tidligere var det ikke tilfældet.

CDC havde 60 og 120 bit FP
ældre Cray havde 64 og 128 bit FP
Univac havde 36 og 72 bit FP
ældre IBM mainframe havde 32 og 64 bit FP som var 16 baseret ikke 2 baseret
VAX havde 32, 64 og 128 bit FP som kun var næsten IEEE kompatible

#6

Få kender forskellige FP formater så godt som VMS folk.

Vi har:

F-float : 32 bit PDP-11 og VAX FP som næsten ligner 32 bit IEEE FP
D-float : 64 bit PDP-11 og VAX FP (grundliggende en F-float med flere cifre)
G-float : 64 bit VAX FP som næsten ligner 64 bit IEEE FP
H-float : 128 bit VAX FP som næsten ligner 128 bit IEEE FP
S-float : 32 bit IEEE FP
T-float : 64 bit IEEE FP
X-float : 128 bit IEEE FP

VMS/før midt-80er VAX :

F - hardware
D - hardware
G - hardware
H - hardware
S - N/A
T - N/A
X - N/A


VMS/efter midt-80er VAX :

F - hardware
D - perfekt men langsom emulering i OS
G - hardware
H - perfekt men langsom emulering i OS
S - N/A
T - N/A
X - N/A

VMS/Alpha:

F - hardware
D - approximativ emulering som G-float
G - hardware
H - N/A
S - hardware
T - hardware
X - perfekt men langsom emulering af compiler

VMS/Itanium & VMS/x86-64:

F - approximativ emulering som S-float
D - approximativ emulering som T-float
G - approximativ emulering som T-float
H - N/A
S - hardware
T - hardware
X - perfekt men langsom emulering af compiler

#5

Med hensyn til forskelle i FP beregninger føler jeg mig fristet til at vise en lille Java krølle som de færreste er opmærksomme på:

public class RelaxedOrStrict {
public static class Relaxed {
public double calc(double v) {
return Math.sqrt(Math.cos(v) * Math.cos(v) + Math.sin(v) * Math.sin(v));
}
}
public static strictfp class Strict { // strictfp is default and keywod obsolete from Java 17+
public double calc(double v) {
return StrictMath.sqrt(StrictMath.cos(v) * StrictMath.cos(v) + StrictMath.sin(v) * StrictMath.sin(v));
}
}
public static void main(String[] args) {
Relaxed o1 = new Relaxed();
Strict o2 = new Strict();
for(int i = 0; i < 10; i++) {
System.out.printf("%d : %.6f %.6f\n", i, o1.calc(i), o2.calc(i));
}
}
}

#4

Så vidt jeg ved er ARM markedsandel:

server - 10%
desktop / laptop - 15%
mobil / tablet - 100%

[Indlæg er markeret som spam]