C++ och dess framtid att programmera minnessäkert - Hur går utvecklingen?

Mer komplicerat att använda än Valgrind, men min erfarenhet minst lika bra på att hitta fel och väsentligt bättre rapport på vad som faktiskt gick fel är AdressSanitizer

https://clang.llvm.org/docs/AddressSanitizer.html

Typiskt overhead för Asan är ~halva hastigheten mot att köra som "vanligt".

Men inte heller det plockar alla felen ovan... Däremot plockar förslaget till "safe C++" dessa fel, fast krävs att man skriver om programmet i en lite annan syntax. Och i det läget är man lite tillbaka till: varför använda en blek kopia och inte originalet?

För "safe C++" är verkligen "hur kan vi ta så mycket som möjligt av Rust's borrow-checker och klämma in den i någon form av C++ syntax"?

Lite som Intels kommande APX där man kopierat ARM64 så långt som möjligt inom ramen för x86. Det blir en förbättring men kräver i stort sätt samma arbetsinsats som att byta till originalet (i både "safe C++" och APX krävs att programmet kompileras om, i "safe C++" krävs även att det modieras) och gör man inte det får man något som inte riktigt är lika bra...

Sitter man på Windows kan man inte köra Valgrind.

Minnesläckor är tyvärr inte så ovanliga i större program. Testning är ju bra, men dels är det inte alltid så lätt att upptäcka att man har en minnesläcka, och dels är det oftast praktiskt omöjligt att testa alla olika scenarion.

Det stämmer, men om problemet inte är Windows-specifikt kan man kanske bygga programmet (eller delar av det) för linux.

Är du säker på det? Det är som sagt inte helt enkelt att testa precis allt, och även om man lyckas verifierar man kanske inte att allt mindre återlämnas? Det är ju inte säkert att det uppstår andra problem än att minnesanvändningen (eventuellt långsamt) växer över tid.

Det där är väl dock tyvärr ett exempel på när en observation inte är ett bevis? Att applikationen kan köra längre tyder kanske på att det inte finns några akuta problem, men om man bara tappar lite minne i vissa situationer går det kanske under radarn? Det kan dock ändras om man börjar köra programmet på något annat sätt.

Man kan kalla det "lågbudget". Men är rätt övertygad att den enda man lurar är sig själv
"Det ska vara dyrt och dåligt så det syns att man har råd..."

Om vi kommer tillbaka till detta om säg 10-15 år gissar jag att även PLC-marknaden primärt kör på opensource då. Embedded är mer konservativ, men se vad som hänt med kommersiella embedded OS. De har i praktiken raderats ut av opensource.

Samma lär hända med RTOS, har redan varit väldigt stor utslagning där och att Linux (efter 20 års utveckling) fått in RT-Linux i kernel.org lär fortsätta trenden.

Huvudorsaken till att det under lång tid nästan var omöjligt att köpa RPi3/RPi4 under ett par år var bara delvis Corona/komponentbrist. Den riktigt stora orsaken var att dessa började sälja i volymer som RPi-gänget inte alls kunde drömma om.

För ja, de designade initialt RPi för utbildning och liknande. Men "industrin" lärde sig att plattformen fungerade lysande (många gånger minst lika bra som existerande och väsentligt dyrare plattformar) och prislappen är betydligt trevligare (vilket spelar roll när man gör stora serier).

Vilket har minst affärsrisk: något där du själv kontrollerar allt, d.v.s. du har källkoden och kretsdesign alt. du är helt i händerna på någon 3:e-part? Det senare har ett värde om man sparar pengar, vilket allt mer sällan är fallet här!

Både g++ och clang++ hittar just det problemet, men det är ett av flera stycken. Asan/Valgrind hittar inte just det, men de hittar två andra. Men det är ändå inte alla buggar ens om man kombinerar allt detta.

Samtidigt: ingen av dessa buggar bygger ens med Rust. Ingen av dessa är ens en bugg i ett GC-språk.

Det finns användningar för C++ och de kommer finnas under väldigt lång tid framåt. Med givet hur extremt lätt det är att göra fel (på sätt som i "moderna" språk endera inte är ett fel eller inte orsakar lika farliga buggar) bör nog ingen välja C++ i ett projekt som inte absolut måste köra C++ framåt.

Så för att gå tillbaka till trådstarten: den rekommendation som allt fler gör kring användning av C och C++ är helt korrekt.

Nu har vi kommit ganska långt från den ursprungliga frågan och jag måste fråga vad som är poängen med att veva denna "kopierat"-kommentar ytterligare en gång? Den känns inte riktigt motiverad i sammanhanget minnessäkerhet.

Vi har sett den ganska många gånger nu och här har du till och med tagit bort citationstecknen runt "kopierat". Du är väldigt tydlig i att du tycker att ARM64 är en bättre arkitektur än X86 (och där får jag hålla med dig). Men här undrar jag om det bara var en fyndig formulering som du ville kasta in en gång till eller om du på allvar försöker idiotförklara ingenjörerna på Intel och AMD? Jag vet inte om det är menat som en lustighet eller om du vill försöka påskina att det är först när ARM64 visat vägen som de förstår att X86 ISA lider av ganska stora problem.

X86 släpar på bagage från 8080/8085-tiden och det är inte på något sätt konstigt att en 40 år modernare arkitektur har gjort andra och bättre(!) val än vad som gjordes på 70-talet. Om vi backar till 2011 då Aarch64 kom hade väl inte ARM någon större marknad där bakåtkompatibilitet var viktigt? De kunde kosta på sig att i praktiken introducera en helt ny arkitektur där de behöll de bra delarna från 32-bits-ISA och fixade sakerna som fungerade mindre bra. När Intel 2001 försökte introducera en ny arkitektur (Itanium) blev det ingen succe. Itanium försökte lösa många av problemen X86 drogs med, men föll just på att det inte var en X86a och att kompilatortekniken inte var tillräckligt mogen för att kunna dra nytta av Itaniums potential (otur att VLIW var på modet just då).

Itaniums misslyckande har sannolikt färgat de val som Intel gjort för X86 och de har försökt leva med X86s tillkortakommanden genom att göra mer avancerad hårdvara. Tvåadressinstruktioner och begränsad registeruppsättning kan till stor del lösas med OOO och djupare reorder buffer, men nu har de väl nått vägs ände där och det är därför vi har fått se APX, X86S och FRED som alla handlar om att förnya/förbättra/förenkla X86.

APX är en "gör om, gör rätt"-uppstädning som borde gjorts för länge sedan, men som sannolikt inte kommit alls om den inte tvingats fram av effektivare konkurrenter. Att man från olika håll kommer fram till snarlika lösningar på vad som behövs för effektiv programexekvering är inte särskilt förvånande. Att fler register och treaddressinstruktioner ger mer kompakt kod och bättre cache-beteende och att möjligheten att generera rak kod förbättrar branch prediction var välkänt långt innan långt innan ARM64 kom så att antyda att Intel använt ARM64 som mall för APX tycker jag är lite magstarkt.

Och förresten, vill man att en AArch32-applikation skall dra full nytta av ens ARM64 krävs det att man kompilerar om programmet, gör man inte det får man något som inte riktigt är lika bra...

Jag tror poängen mer är en liknelse mellan två exempel där man haft enorm framgång historiskt men lider av gamla designval som inte åldrats väl. Där effekten då är att man är bakbunden av sin egen framgång; om man fixar de problematiska designvalen så bryter man kompatibiliteten och folk tvingas att anpassa sig till något nytt. Men om de då tvingas att lägga ned jobb på att anpassa sig till något nytt, varför ska de inte se sig runt bland alla alternativ på marknaden, och om de gör det, varför välja just denna lösning om den fortfarande inte är den allra bästa?

Börjar med det enkla: Jag skriver “kopiera” för jag har faktiskt inga bevis för var man gör så i fallet med APX. I fallet med “safe C++”, är man helt öppen med att man verkligen vill försöka få in motsvarande funktioner i C++ som Rust redan har och se vad det leder till.

Sedan håller jag helt med om Itanium. Intel gjorde egentligen helt rätt; de tog det som var trendande inom forskningen och det man då trodde och hoppades skulle vara framtiden och gick all-in! Så problemet låg definitivt inte där; det var att forskningen tyvärr vid den tidsperioden hamnat i ett mindre lyckat sidospår. Intel hade maximal otur med timing.

Som du påpekade (och jag håller helt med där) blev den väldigt trista konsekvensen av att den allmänna uppfattningen blev “ISA spelar ingen roll, är bara mikroarkitektur som räknas”.

Här får jag erkänna att jag var lite skeptisk när Arm presenterade ARM64 2010 och det blev klart att man inte hade gjort som alla andra och bara utökade deras existerande ISA med 64-bits stöd. Man såg bristerna i att ta Aarch32 till high-end och startade från grunden. Det var en gigantisk risk med tanke på till exempel Intels erfarenhet med Itanium.

Rätt tidigt började man se resultat där reaktionen var “det kan inte stämma!”. På samma CPU (fram till ganska nyligen hade de flesta 64-bitars Arm-CPU stöd för både Aarch32 och Aarch64) kunde de skilja allt från 5 % till upp mot 30 % bara genom att köra Aarch64 istället för Aarch32. Det vill säga, ISA kan spela stor roll; man körde med samma mikroarkitektur.

Jag försöker verkligen inte idiotförklara dem. Jag har ett par gånger ställt den retoriska frågan om de är idioter eller om det finns en betydligt rimligare förklaring. För självklart har de sin del av eliten inom CPU-design, så förklaringen är rimligen att begränsningarna ligger i att de sitter fast med teknik som hindrar dem.

Och det som jag vill se här är att vi kommer bort från den tekniken så fort som möjligt. Jag bryr mig faktiskt inte alls hur det går för Intel, AMD, Apple eller någon annan. Hoppas bara utvecklingen tar en sådan väg så vi som kunder får så bra produkter som möjligt

Angående “Och förresten, vill man att en AArch32-applikation skall dra full nytta av ens ARM64 krävs det att man kompilerar om programmet, gör man inte det får man något som inte riktigt är lika bra... ;)”

Ja, det är ju självklart. Men om man nu faktiskt måste göra det, varför vänta in APX (som kommer behöva designas inom ramen av flera x86-begränsningar) istället för att ta det som redan finns idag? Oavsett vad man väljer måste man kompilera om programmet; om det jobbet ändå ska göras är det väl rimligt att välja den bättre av två tekniker?

Hade inte Arm vågat släppa hörnflaggan och starta från grunden hade världens snabbaste mikroarkitektur 2024 definitivt inte varit Arm-baserad. Who dares win (i alla fall om man har turen på sin sida…)!

OK, jag gjorde inte "om vi ändå måste kompilera om"-kopplingen i det inlägget jag kommenterade.

Beträffande "varför inte byta om vi ändå måste kompilera om allting?" så tror jag att det kommer ta mycket längre tid än du hoppas på. Valet blir nog nästan alltid att fortsätta med det språk/den arktektur man redan sitter fast i (existerande programvara och kunnande). Här tror jag att det är en stor tröghet att byta, både programspråk och arkitektur, och att byta C++ till Rust är ett betydligt större steg än att byta från X86 till ARM64. Alternativet må vara bättre tekniskt sett, men det kommer alltid att vara lockande att välja något som gör att man kan fortsätta att köra samma sak som i dag (utan att behöva kompilera om, och om vi kompilerar om då kommer det bli ännu bättre!).

Den trögheten finns på alla nivåer. Att stora organisationer med omfattande installationer av diverse mjukvara på ägda serverparker kommer se det som ett stort steg att byta är naturligt. De är konservativa och vill inte riskera någonting som kan störa verksamheten. Men även om vi Sweclockers-nördar betraktar oss som teknikpositiva och framåt så vore ett stort steg att byta arkitektur. Här debatteras valet mellan AMD eller Intel snarare än mellan X86 eller ARM64Mac. Om man skulle byta arkitektur, hur mycket av Steam/EPIC/GOG-biblioteket supportas på Mac? Hur mycket bättre måste alternativet vara för att det skall vara värt att ta steget och riskera att inte längre kunna spela några av favoritspelen?

Denna tröghet hos existerande användare var en av de saker lade krokben för Itanium. ARM, å andra sidan, användes under tidigt 2010-tal främst för embedded och mobiler. De tillverkarna satt inte fast i en existerande användarbas på samma sätt utan var beredda att byta till ARM64 och de togs glatt emot av användarna. 64-bitars telefon, måste ha!