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

Nu har du skrivit det så många gånger och det känns fortfarande som galimatias. Vad menar du med "överlagra metoder"?

Av språken med statisk typsystem lär Go ha den mest flexibla varianten av polymorfism.

Rust har ett trait-system som inte är lika komplicerat som C++? Och Rust har också ett macro-system som på flera sätt är mer kraftfullt än det C++ har via templates.

Vad är det konkret man inte kan göra???

Huvudsyftet med DOD i spel har varit att effektivt utnyttja SIMD, något som ofta underlättas rätt mycket av att köra SOA istället för AOS. Hur gör du det med vad som beskrivs det enklare att använda SIMD och hur använder du SIMD?

Eller är det bara ett sätt att försöka minska cache-missar? Det kan nog ge en del, men normalt sett är det främst ihop med SIMD som man blir rätt rejält begränsad av cache-missar i en modern CPU nu när OoO-fönstret blivit så brutalt stort.

Gissar du bara vad som är flaskhals, eller har en profiler faktiskt visat det du optimerar som en flaskhals?

Och framförallt, har du tagit ett steg tillbaka och funderat: "kan jag göra det här smartare i form av att inte göra beräkningen alls eller långt mer sällan"? Kommer tillbaka till detta för det har varit så många gånger under åren när jag optimerat saker där slutklämmen blivit: ingen poäng att optimera original low-level koden, fanns hög-nivå optimeringar som gav långt mer och med dessa dyker inte low-level delarna vi tänkte optimera längre upp som signifikanta i profilern.

Det hade ju varit bra om vi kunde hållit oss till etablerade termer och definitioner så behövs det inte förklaras så mycket.

Tror de flesta hört talas om HN så ingen mening med att förklara det. Är det overloading du syftar på med överlagring som i function overloading?

???

SIMD -> parallellism på en enskild kärna. Normalt av typen data-parallelism p.g.a. av "S" i SIMD.

MIMD -> dela upp arbetet i flera trådar. Stödjer både data-parallelism men också uppgifts-parallelism.

Med MIMD kan det vara prestandamässigt negativt att packa data allt för mycket, kan ge "false-sharing" vilket kan vara en rejäl prestandadödare (i sina värsta former går det då långsammare ju fler kärnor man slänger på problemet).

Så kör du SIMD eller MIMD?

Här känns det igen mer som "vet på ett ungefär vad en kompilator från förra årtusendet klarar att optimera".

Just strängoperationer är något som rätt ofta är handoptimerade m.h.a. SIMD idag. Detta då egentligen inget av de "normala" språken har något vettig stöd för att uttrycka vad man vill göra som låter en kompilator göra ett bra jobb. Men är inte en omöjlig uppgift, Nvidias CUDA (GPU) och Intels ISPC (SIMD på CPU och GPU) är båda dialekter av C/C++ som har en semantik gör det möjligt för en kompilator att göra väldigt bra SIMD-kod.

Något kompilatorer/länkare är långt bättre på idag är att ta program som är uppdelade i många små (och enkla att testa...) delar, men ändå optimera det som-om allt är skrivet som en big-ball-of-mud.

Och kopplingen mellan "vilken assembler blir det / hur många instruktioner blir det" har allt mindre koppling till "hur snabbt körs detta på en modern CPU" då out-of-order fönstret blivit så gigantiskt. En människa ha extremt svårt att överblicka detta, även kompilatorer har problem då de bara har statiskt information och allt mer av prestandaflaskhalsarna är dynamiska (vilket är orsaken till varför JIT:ad kod (som JVM och .NET använder) idag kan vara snabbare än AOT (vilket C, C++, Rust, Go, m.fl. använder)).

Både C++ och Rust arbetar på ett grundläggande SIMD stöd i deras standardbibliotek. Rust-varianten är hyfsat färdig, men inte i skarp release än (men är alltid med och går att slå på med flaggor). C++ varianten är lite längre från att hamna i standarden, men går att test-köra. Ingen av dessa tar stödet lika långt som CUDA/ISPC, men ändå långt bättre stöd av vad som finns idag.

Tror alla som varit med i NH-diskussionen greppar vad NH är. Det jag tror ingen alls fattar är vad i HN du hävdar gör det så mycket enklare att "scanna stora mängder kod".

Och även här måste det ju finnas en eller flera specifika detaljer som gör C++ helt överlägsen allt annat då de överhuvudtaget inte har funktionen. DET måste vara trivialt att exemplifiera. Du har gjort ett par försök, alla har så här lång fallit totalt platt då du inte har koll på vad som faktiskt är möjligt i alternativen.

Så hur hackar du SIMD-koden idag?

Assembler och/eller intrinsics så då gör din kod helt låst till en viss CPU ISA? Eller använder du ISPC (som i alla fall fungerar på alla relevanta varianter av x86 SIMD och ARM64 pre-ARMv9)?

Hur du hanterar MIMD har vi fått ett smakprov på. Tips: det är rätt mycket ett löst problem på ramverksnivå, använd ramverken då de är rätt mycket mer effektiva än ditt hemmasnickrade försök. Om nu inte huvudmålet är att lära dig, för finns rätt mycket att lära sig här (och något jag gillar då jobbat och även forskat en del kring detta).

Nej, en term är följande "uttryck som används inom ett visst verksamhetsområde och där har en speciell l. noggrant bestämd betydelse". Noggrant bestämt och vi använder dessa för att snabba upp kommunikationen, exempelvis kunde du säga regressionstest eller HN och alla vet redan vad det innebär utan att du behöver förklara mer.

Dom är alltså inte anpassade(enl. dig förenklade) för att så många ska kunna förstå dom.

Problemet är inte att saker är invecklade. Istället för att du går till Wiki-sidan för att kontrollera om "function overloading" är samma som du hade i åtanke och svara "ja, det är det jag tänkte på" eller "nej, jag tänkte på något annat" så får vi otekniska berättelser som nedan.

Det vill säga det går inte ha tekniska diskussioner när du berättar historier utan att anknyta dom till teknik...

Detta sa inget om överlagring.

Sure, vad är problemet med unsafe? Det finns i språket av en anledning och det är ju för att användas.

Detta låter mest om oerfarenhet. Jag uppfattar det som väldigt vanligt att man återanvända kod i Rust har väl rekord många paket(crates) till sitt förfogande och ligger väl på nivå med NPM. Det finns saker som är svåra att få till i Rust i dagsläget som async-traits (läs som interface med asynkrona funktioner/metoder) och då finns det en tillägnad crate, som löser detta, där användaren lägger till motsvarande ett macro på sitt trait(ser ut som en decorator från Python). Macrot kommer sedan modifierar funktion/metod-signaturen och wrappar-returvärdena på ett sätt så att ett icke-async-trait kommer fungera i async-förhållande. Det skulle jag ser som återanvändning.

Nej, det gjorde det inte eftersom du binder inte ihop resonemanget. Nu har jag försökt att tolka det du skrev så allt här efter är ett försök att bryta ner ditt inlägg för tolkning. Peka gärna ut vilka delar du tycker att jag lagt för lite vikt vid som hade rott hem din förklaring.

Du försöker inleda med en problembeskrivning och problemen är:
- Hur hittar man X bland rader och columner?
- Storlek (tusen sidor fast oviktigt), samma tidskomplexitet.

Vidare...
- "Samma sak med kod" så problemet är programmatiskt.
- "hur mycket vi kan ha i huvudet samtidigt", någon form av minnesbegränsning.
- "hur mycket vi kommer ihåg", någon form av lagringsbegränsning alternativt repetition av minnesbegränsning.

Kim Peek, https://sv.wikipedia.org/wiki/Kim_Peek

Nu pratar vi om någons prestation och gått ifrån överlagringsbeskrivning genom problembeskrivning eller annan beskrivning.

Nu kommer vi äntligen till beskrivningen av överlagring. Beskrivningen är:
- Teknik för att skriva kod.
- Producerar kod som är lättare att hantera.
- Baseras på mönster(mycket viktigt!).

Om jag någonsin skulle ge exempel på en vag beskrivning så är ovan nog en stark kandidat.

Du beskriver ju inte:
- Hur löser tekniken din problemställning som du inledde med?
- Vad tekniken går ut på?
- Vad i tekniken får den att producerade koden lättare att hantera?
- Vilka kriterier uppfyller kod för att klassas som lättare att hantera?
- Vilka fasta mönster baseras tekniken på?
- Vad är ett "fast mönster" i kontexten? Regex, design-patterns eller något annat?

Hur hör detta ihop med din överlagringsteknik? Samt hur hör det ihop med din problembeskrivning i din beskrivning av din överlagringsteknik? Dvs hitta X bland rader och kolumner med konstant tidskomplexitet med minnesbegränsning.

När jag först påstod att inget i ditt tidigare inlägg beskrev överlagrings så svarade du med:

Efter att jag bröt ner ditt inlägg så skriver du:

I inlägg 1 så hävdar du att du redan beskrivit tekniken om man är smart nog att förstå det.
I inlägg 2 så skriver du att det inte går att diskutera tekniken efter att jag bevisat att inlägg 1 var falsk.

Förstår du varför jag tror att du trollar eller är en oseriös aktör? Jag var nästan övertygad att du var ett troll (typ en gymnasieelev med chatgpt). ChatGPT hade förklarat feberyrandet som fått diskussionen att hopp från ämne X till Y till Z utan att riktigt bearbeta något ämne.

Hade du inte bara kunnat hålla dig till tekniska diskussioner? Förklara tillvägagångssätt, processer osv, istället för saker som "Angående överlagring så tänk på en telefonbok ...".

Om du tycker att X är skit och du har en egen teknik som är bättre men inte går att förklara på ett forum, skulle du inte bara kunnat undvika att dra igång sådan diskussioner eftersom det ändå inte leder någonstans?

@klk Blir bara lite nyfiken gällande ett inlägg några sidor tillbaka om HN och hur du resonerar där. Om jag inte missförstod det så förespråkade du bIsReady framför is_ready; strider inte det mot din första grundlag om att skriva vettig kod från början, dvs med vettig kod så är det redan självklart?

Jag har svårt att se hur en "is ready"-funktion/metod skulle returnera annat än sant/falskt och fortfarande klassas som vettig. (Förtydligande: logiskt sant/falskt så att en if (is_ready) alternativt if (is_ready()) fungerar oavsett datatyp)

Jo, men nu var det ju du som valde exemplet och inte jag. Jag ställde bara frågan kring ditt exempel eftersom det var just ditt eget exempel Upplever lite magnetpolsskifte i svaren.

Denna sorts diskussion är faktiskt perfekt för ett forum, här har man möjlighet att skriva ned exakt och precist vad man menar, man kan förklara vilka definitioner för något man använder, ställa och svara på väldigt specifika frågor för att förtydliga exakt vad man menar, följa upp på andras tankar och berätta var man haft fel eller på vilket vis man blir misstolkad osv.

Allt detta sker också asynkront, så man har väldigt mycket tid att skriva egna tydliga argument eller att läsa och förstå andras argument och frågor.

Till exempel skulle detta kunna hända:

1. Man gör ett övergripande påstående så som att "Enhetstester är värdelösa", och det man menar är att i ens egen erfarenhet, för en viss (eller kanske majoriteten av) sorts programvara så ger inte enhetstester mer värde än vad de kostar osv.

2. En medskribent på forumet tolkar detta som att du säger att "I alla tänkbara scenarion, har inte enhetstester något värde, och dom bör aldrig användas". Medskribenten påpekar att i fall där människor faktiskt riskerar att dö, avlida, skadas allvarligt på grund av buggar i koden, då är det faktiskt värt det "extra arbete" som det skulle innebära, och när man arbetar på ett visst sätt så är det kanske inte ens extra arbete

3. Sedan när du läser detta svar, så har du möjlighet att svara och förtydliga, och säga att du förstår att i fall där människor riskerar att dö så kan det vara värt kostnaden. Sedan säga att du utryckte dig på ett dåligt och otydligt sätt för du tänkte inte just då på att det finns väldigt mycket kod som körs på andra ställen än vad du refererade till.

4. Efter att du gjort detta förtydligande, så har du nu möjlighet att förtydliga i exakt vilka sorters use cases eller applikationer du faktiskt hade i åtanke med orginaluttalandet och så vidare, och diskussionen kan hållas på ett plan där alla skribenter har en gemensam förståelse av ramarna för diskussionen.

Det finns alltså i detta formatet oändligt med tid att göra sig förstådd tydligt.
Tex i en diskussion om A och B, så kan man skriva: "På grund av A så händer ofta B. Till exempel i denna anekdoten C så kan ni se hur A leder till B pga D".

Det som istället ofta händer i denna tråden är att du i ditt svar lämnar ute A och B, och svarar "i anekdot C händer D", och sedan räknar med att folk automatiskt ska veta vad ditt argument egentligen är.

Det kanske känns som att du sparar tid på att skriva på detta viset, men det leder istället till att diskussionen fraktaliseras iväg i oändliga sidospår att svara på istället.

För mig så handlar det om att du påstår saker som är lätta att falsifiera samt att du säger det som att det är en objektiv sanning när det är högst subjektiva åsikter.

Du pratar hela tiden om denna typen, enl. dig, unika scenarion men när du beskriver dessa mer konkret så låter dessa alltid extremt vardagliga.

Har mycket svårt att begripa varför man ägnar sig åt att kasta ut påståenden som man sedan inte kan underbygga med vettiga förklaringar och sedan påstår att det man sagt är så svårt att beskriva i en sån här tråd på ett sånt här forum.
Hur kan man själv på ett effektivt sätt använda tekniker och metoder som man inte kan förklara?
Jag har ägnat mig åt programmering av stora, komplexa interaktiva webb- och databasdrivna applikationer med krav på så hög tillgänglighet som möjligt och med (potentiellt) obegränsat antal samtidiga användare och aldrig någonsin under realiserandet av dessa system har vi använt annat än vedertagna modeller för programmeringsarbetet. Några av de grundläggande kraven har alltid varit begriplighet och testbarhet. I det senaste projektet var mer än 60 % av den skrivna koden just testkod och i slutet av vajre arbetsdag kördes samtliga tester för att verifiera att vi inte gjort bort oss. Alla programversioner sparades i ett versionshanteringssystem och alla testkörningars alla resultat sparades för maximal spårbarhet. Delar skrevs i Java, Groovy, Javascript, Python och integrationen av alla delar likväl som kommunikationen mellan dem testades så noga att vi kunde påvisa (och få åtgärdade) brister i serverprogramvaror som vi använde och även brister i minneshanteringen i Java.
Räknar jag alla programspråk som jag använt under mina runt 40 år i gamet, hamnar det runt 30 medan andra påstår att det är väsentligt flera och vi (man jobbar oftast inte ensam) har aldrig avfärdat ett språk på det sätt som du (@klk) gör. T.ex. har flera projekt framgångsikt skrivits i Python. Inte någonsin användes några obskyra obeskrivbara metoder eller tekniker, varför skulle man göra det, kommunikationen mellan projektmedlemmarna skulle ju inte kunna fungera.
Om inte du (@klk) är ett troll så måste jag dra slutsatsen att du antingen driver med övriga tråddeltagare eller inte riktigt förstår vad du själv skriver eller att du gör det men vill provocera fram en diskussion trots att den egentliga diskussionen ju faktiskt är över (den om utvecklingen med minnessäker programmering i C++)
Och varför påstå att folk ska undvika C/C++ på grund av att folk inte har tillräckligt intresse för att förstå vad du pratar om? Tvärtom har ju t.ex. @orp verkligen försökt förstå men du tar hans inlägg som kritik mot dig (en del är väl det men många är frågor i genuina försök att förstå).