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

Nu tror jag det är dags att du kollar lite på hur en modern GC fungerar. Det är inte stop-and-copy längre. Om vi tar fallet Go, så är GC:n inkrementell och concurrent. Den är designad för low latency och använder lediga kärnor för att köra GC samtidigt som ditt program kör i full fart. Ja, programmet kommer att dra mer minne eftersom onåbart minne inte upptäcks i samband med att sista referensen släpps och det går åt minne till bookkeeping i samband med GC, men att saker och ting automatiskt skulle bli 10X snabbare bara du skrev det i C++ kan du fetglömma.

Nu skriver du prefetch igen. Pratar du om software prefetch eller hardware prefetch? Software är helt och hållet en fråga för kompilatorn så där tror jag inte att GC blockar användandet av prefetch-instruktioner. Hardware prefetch är baserat på att CPUn hittar någon form av regularitet i accessmönstren, dvs loopar över arrayer. På vilket sätt skulle loopen bli annorlunda för att språket har GC? GC kommer typiskt gå i samband med att man allokerar nytt minne, och gör du det förstör du för prefetchern även om du gör det i C++. Kan du utveckla på vilket sätt GC är skadligt för hardware prefetching?

Får se om jag fattat det hela korrekt? Dina argument här består av

• För 30 år sedan var GC inte snabbt. Om du inte har uppdaterat dig sedan dess är det kanske du som hör hemma på ålderdomshemmet, inte språk som har GC.

• Cache är viktigt. Detta är sant, både med och utan GC. Bookkeeping för GC:n kommer öka cache-trycket lite grann, men i het kod kommer dessa data snabbt ersättas av det data man jobbar med.

• I C++ kan stoppa in flera olika saker i 32-bits element. Kan man inte det i andra språk? Go kanske inte har stöd för bitfields, men de är bara syntaktiskt socker för shiftar och maskningar.

• Ett objekt som är 64 bytes stort passar i en cache line, medan ett 72 bytes stort objekt inte gör det. Vad har det med GC att göra?

• Prefetchers är viktiga för att få in data snabbare i cachen. Ja visst! Låt mig återigen fråga om du tänker på software eller hardware prefetching? Och varför skulle ett språk utan GC utnyttja prefetchers bättre? Vänligen förklara detta i termer någon med lång erfarenhet som mjukvaruutvecklare (i C++!) förväntas förstå. Bara teknik, inga liknelser eller andra utvikningar. Vi förstår en teknisk förklaring.

• SIMD. Vad har SIMD, med GC att göra? Är det bara C++-kompilatorer som kan generera SIMD-instruktioner?

• Optimeringar. Om man bryr sig när man skriver sitt program kan det gå fortare. Helt korrekt. Kan man inte bry sig om man skriver i annat språk än C++?

Jag kan inte se att något av dessa argument innehåller något som är unikt för C++ och skulle motivera en 10X uppsnabbning jämfört med optimerade program skrivna i ett annat språk, bara för att detta språk kör en minnesmodell med GC. Men du får hemskt gärna förklara för mig varför prefetching inte fungerar när man har GC.

Läser du något av svaren?

Det finns multipla prefetchers och han frågade dig vilken du syftar på. En AI-sökmotor kan inte läsa dina tankar så svara istället.

Så du ger ett missledande svar och trollar istället för att svara på frågorna...

Börjar mer och mer tro att @klk lägger in hela tråden i chatgpt och instruerar den med ”skriv ett svar som är vagt relaterat till ämnet, men se till att det är motsägande till allt och mestadels består av anekdoter”

Yngre kommer garanterat inte få jobb om dom läser dina svar. Det kommer ta stopp för de yngre om dom ens anammar dina åsikter gällande kvalitetssäkring. Om yngres skulle plocka upp dina åsikter om att:
- envisas med uppfinna hjulet på nytt
- kodstil med 120 kolumners indentering på asserts
- envisades med att pilla på minne när det inte behövs
- åsikter om att kod inte ska vara läsbar utan scan-bar
- egna definitioner av deklarativ/imperativ, regressionstestning osv
- tro att man är någon övermänniska för att man kodar C++
- tro att andra utvecklare är mindre värdiga för att man inte kodar C++

... allt det kommer få yngre till att inte ens överleva en provanställning.

Att sätt arbetsgivare och arbetstagare i kommunikation är inte samma som att vara mentor till blivande utvecklare och ge dom dina åsikter från denna tråden som "tips".

Du har ju själv medgivit att du skulle undanhålla dina åsikter på en arbetsintervju pga att dom går emot industristandarder.

Du missförstår mig. Visst är jag intresserad av att lära mig mer, men i detta fall vill jag veta vad du baserar ditt uttalande på. Jag hävdar att det är 100% nötboskapsexkrement att prefetch inte skulle fungera för att språket har GC.

Hela idén består i att programmeraren/kompilatorn/CPUn identifierar accessmönster där adresserna har ett linjärberoende: y = k*x + m (m = basadress + eventuellt offset, k = stride * accesstorlek). Det är typiskt tillämpbart i loopar med förutsägbara array-accesser, typ a[i] eller a[i * x]. I mjukvara kan man börja prefetcha redan i första iterationen av en loop. Görs prefetchingen av hårdvara tar det ett antal iterationer innan CPUn identifierar linjärberoendet och börjar prefetcha data till efterföljande iterationer. Är vi överens så långt?

Varför skulle detta sluta fungera för att språket har GC?

Om vi skulle råka köra GC mitt i en het loop där hardware prefetching är aktiv (vilket i sig är osannolikt), då kommer prefetchern tappa all kontext eftersom vi börja köra annan kod med andra accessmönster, men när GCn är klar och vi återvänder till loopen kommer hardware prefetchern återigen upptäcka accessmönstrens linjärberoende och prefetcha data från kommande iterationer. Låter detta rimligt? Detta kommer ske oavsett om GC har flyttat de använda arrayer eller inte. Du kommer få ett antal iterationer när HW prefetching inte är aktiv, men det är inte så att det slutar fungera.

Precis. Nyckelordet här är "kod" och inte C++. Som du själv sagt så är det enda som körs maskinkodsinstruktioner. CPUn kan inte veta om koden kommer från ett språk med GC och stänga av prefetching.

Om du fortfarande hävdar att prefetching inte fungerar om språket har GC får du allt komma med ett par riktigt bra argument till varför det inte fungerar.

Bjarne har klargjort lite mer vad han anser är rätt väg framåt för att minska säkerhetsproblemen i C++
https://www.infoworld.com/article/3839386/c-plus-plus-founder...

"According to Stroustrup, profiles are essential to the language’s future, will not break existing code, and will not prevent a favorite new feature. They also are part of a long tradition of C++ evolution. He advised support for initial profiles in C++ 26, and warned against incompatible, ad hoc restrictions as the alternative."

Lite mer utbroderat vad profiler betyder
https://herbsutter.com/2024/03/11/safety-in-context/

Som jag förstår det kan man välja att följa en profil, det blir då lite som att sätta "treat warnings as errors" där en profil kan göras så att saker som normalt är tillåtet i standard C++, men som idag anses vara "bad practice" genererar kompileringsfel (men ska vara möjligt att opt-out vid behov).

Lite exempel från C++ Core Guidelies (som m.h.a. clang-tidy redan idag kan fungera som jag fattar profiler kommer göra framåt)

Några axpol på "do"

• Use RAII for resource cleanup

• Prefer std::vector, std::string over raw arrays

• Avoid raw pointers, prefer std::unique_ptr or std::shared_ptr

och "don't"

• Avoid goto

• Avoid manual memory management (new / delete)

• Avoid volatile for multithreading—use std::atomic instead (den här är lite mysko givet att det förra är en direkt bug, inte abra "bad practice")

Bjarne verkar väldigt emot något som skulle kräva att man pajar bakåt kompatibilitet

"Demands for memory safety are not unreasonable, he said. “Profiles provide a unifying framework that allows the C++ community to address safety challenges without compromising C++’s core strengths,” Stroustrup said."

Blir därför väldigt spännande att följa utvecklingen av TrapC som har en del "breaking changes" från C, men som tack vare dessa resulterar i kod som ser väldigt mycket ut som "vanlig C" och ändå innehåller de egenskaper Bjarne försöker uppnå med profiler (och som Safe C++ försöker uppnå med att begränsa språket till en säker delmängd + några extra nya features).

Bjarne är övertygad utfallet kommer bli att C++ blir allt mer övergivet om man INTE agerar

"“The sky isn’t falling, but unless we act now and get C++ onto a track supporting a flexible framework of profiles (supporting various forms of safety), we risk a painful decline,”"

Vi gör den här kort: läs "art of multiprocessor programming" och fundera om något du skrivit i just det ämnet i denna tråd är ens i närheten korrekt.

Jag ser inget motsatsförhållande här.

Att kunna sina standardbibliotek tycker jag är en viktig del av att vara en duktig programmerare. Koden däri är typiskt vältestad och effektiv. Att själv sitta och skriva kod som gör samma sak är bara slöseri med tid. Inte nog med det, att använda standardbiblioteket signalerar även intent på ett helt annat sätt än din hemknåpade kod. Används funktionalitet ur standardbiblioteken är sannolikheten att folk direkt förstår vad koden gör mycket större än om man måste läsa implementationen av funktionen som anropas.

Jag förundras varje år över folk i Advent Of Code-tråden som skriver sida upp och sida ner med kod för att göra saker som finns färdiga i Pythons standardbibliotek.

Byt ut "python" mot "C++", så blir det mer korrekt.

Ok, då kanske jag misstolkat det hela, men...

När jag ifrågasatte att saker och ting skulle gå 10X snabbare om de skrevs i C++ istället för ett språk med GC:

I svaret på det står det:

Jag läser detta som att prefetch funkar i C++ och om C++ skall ha någon fördel av detta så implicerar det ju rimligen att det inte funkar för de språk vi jämförde med. Right?

När jag avfärdade dina argument skrev jag:

kontrade du med:

Hade det inte varit en bra idé att redan här påpeka att du inte hade sagt det jag trodde att du sagt? Det var väl ingen tvekan om att jag fått det runt bakfoten?