Forum Mjukvara Programmering och digitalt skapande Tråd Inlägg

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

1 2 3 4 5 6 7 8
Skriv svar
Permalänk
Datavetare ★
●
Skrivet av Elgot:

Valgrind är ett ofta använt alternativ som i alla fall löser tillgänglighet och pris…

Gå till inlägget

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...

Visa signatur

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Redigera
Citera flera Citera
Permalänk
Medlem ★
●
Skrivet av Elgot:

Valgrind är ett ofta använt alternativ som i alla fall löser tillgänglighet och pris…

Gå till inlägget

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

Redigera
Citera flera Citera
Permalänk
Medlem
●

Jag använde Microsofts egna...sak..minns inte namnet på den. Men den fungerade mycket bra för Visual Studio (inte Code). Den larmade om man glömde att deallokera minnet.

Detta var för C dock jag körde.

Sedan undrar jag hur ofta minnesläckor förekommer i större program? Jag har byggt rätt stora program, och jag har aldrig fått någon minnesläcka efter jag har lanserat mitt program. Dels för att jag buggtestar allt från alla olika scenarion. Men sådant kanske inte görs längre hos större företag?

Redigera
Citera flera Citera
Permalänk
Medlem ★
●
Skrivet av heretic16:

Sedan undrar jag hur ofta minnesläckor förekommer i större program? Jag har byggt rätt stora program, och jag har aldrig fått någon minnesläcka efter jag har lanserat mitt program. Dels för att jag buggtestar allt från alla olika scenarion. Men sådant kanske inte görs längre hos större företag?

Gå till inlägget

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.

Redigera
Citera flera Citera
Permalänk
Hedersmedlem ★
●
Skrivet av Curik:

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

Gå till inlägget

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

Redigera
Citera flera Citera
Permalänk
Hedersmedlem ★
●
Skrivet av heretic16:

Jag har byggt rätt stora program, och jag har aldrig fått någon minnesläcka efter jag har lanserat mitt program.

Gå till inlägget

Ä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.

Redigera
Citera flera Citera
Permalänk
Medlem
●
Skrivet av Elgot:

Ä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.

Gå till inlägget

Jag är säker på detta. Programmet går än idag.
Men jag gjorde många månaders testning Kanske förklarar varför.

Men åter igen, det var ju min kompilator som larmade. Alltså borde GCC ha denna funktion som standard.

Redigera
Citera flera Citera
Permalänk
Medlem
●
Skrivet av Yoshman:

Kan du vara specifk? Vad exakt är det som inte är bra?
Tar man Arduino har det bl.a. börjar användas i vissa PLC:er, stora fördelen är att man kan bygga produkter till lägre pris.

Gå till inlägget

Låg budget PLC! Inte PLC så som Siemens, Beijer med flera.

Citat:

Visst kan man fsck-up med Micropython, men "rätt" sätt att hantera minne där är precis som i C eller C++ för en MCU: allokera allt minne vid start och släpp aldrig referensen -> inget problem. Så till skillnad från "vanlig" Python programmering krävs förståelse för minneshantering i väldigt begränsade miiljöer även om man kör Micropython.

Varför Volvo, eller antagligen någon biltillverkare, kör RPi Pico lär ha minst två förklaring:
1. de använder väldigt ofta CAN, finns många MCUer med integrerad CAN men RPi Pico är inte en av dem (finns inte heller i vanliga RPi, dock har Arduino R4 CAN samt även Orange Pi 5, använder med fördel OPi5+Go+CAN i "industriprojekt").
2. allt som hittar in i en bil man kan köpa är rejält gammal, RPi Pico är rimligen allt för ny att finnas i någon existerande bilmodell

Grejen med att företag använder inte hobbyleksaker, är för att dom är hobbyleksaker. Det finns ingen support för dom som man kan förlita sig på. Vad händer om det blir en uppdatering? Vad händer om det blir en ändring?

Raspberry Pi skapades för barn för utbildning, inte för att Mercedes Benz S-klass 600 ska använda dom.

Citat:

Sen tillbaka till tråd-topic: här är lite "modern" C++ (initializer_list kom i C++11 och string_view i C++17) kod-haveri. Buggarna med string_view är tydligen tyvärr inte alls ovanliga i "verkligheten". De kompilerar helt utan varning och tenderar ge rätt svar i debug-byggen och ibland även i release-byggen, men de är fel (valgrind plockar bara string-concat-fallet).

#include <iostream>
#include <string_view>
#include <vector>

using namespace std;

void print_sw(string_view sw) {
        cout << sw << endl;
}

void all_ok() {
        print_sw(string_view{"a string literal"});

        string x = "This is long enough to bypass short-string optimization";
        string y = "Short";

        string_view sw = string_view{"a string literal"};
        print_sw(sw);

        vector<string_view> vec;
        initializer_list<string_view> initlist = { x, y };
        vec = initlist;
        for (string_view sw: vec)
                print_sw(sw);
}

void horribly_broken() {
        // using sting literal suffix creates temporary instance that broken1 outlives                                                                                  
        string_view broken1 = string_view{"a temporary string"s};
        print_sw(broken1);
         
        // ...still broken
        print_sw(string_view{"a temporary string"s});

        string x = "Foot ";
        string y = "gun!";

        // string concatenation creates temporary string, which broken2 outlives                                                                                        
        string_view broken2 = string_view{x + y};
        print_sw(broken2);

        // still broken
        print_sw(string_view{x + y});

        initializer_list<string_view> initlist;
        // The C++ Standard does not guarantee that std::initializer_list supports assignment in a meaningful or safe way.                                              
        // This was the *only* case that the compiler warned about, but it does compile!!!                                                                              
        initlist = { x, y };
        vector<string_view> vec = initlist;
        for (string_view sw: vec)
		print_sw(sw);
}

int main() {
	all_ok();
	horribly_broken();
}

Skulle inte kompilera i Rust och skulle inte vara en bug i något språk med GC då temporära objekt inte går out-of-scope där så länge det finns referenser.

Även C är långt bättre än C++ här. För skulle man göra motsvarande i C skulle man ha betydligt större varningsflaggor att man gör något korkat då C inte har några implicita anrop. Just implicita anrop är en foot-bazooka i C++.

När jag kör din kod https://onlinegdb.com/ZrNnJBJQh så säger den följande. Detta betyder att den gav mig en varning. Jag kan ju ställa in en flagga på att jag ska få ett felmeddelande, istället för varning. Eller hur? Alltså är det mitt ansvar att säga åt min kompilator att granska för minnessäkerhet?

Citat:

main.cpp: In function ‘void horribly_broken()’:
main.cpp:48:27: warning: assignment from temporary ‘initializer_list’ does not extend the lifetime of the underlying array [-Winit-list-lifetime]
48 | initlist = { x, y };
| ^
a string literal
a string literal
This is long enough to bypass short-string optimization
Short
sw�L5�\
b=ng
a temporary string
Foot gun!
Foot gun!
Foot

Redigera
Citera flera Citera
Permalänk
Hedersmedlem ★
●
Skrivet av heretic16:

Jag är säker på detta. Programmet går än idag.
Men jag gjorde många månaders testning Kanske förklarar varför.

Men åter igen, det var ju min kompilator som larmade. Alltså borde GCC ha denna funktion som standard.

Gå till inlägget

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.

Redigera
Citera flera Citera
Permalänk
Datavetare ★
●
Skrivet av heretic16:

Låg budget PLC! Inte PLC så som Siemens, Beijer med flera.

Gå till inlägget

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.

Skrivet av heretic16:

Grejen med att företag använder inte hobbyleksaker, är för att dom är hobbyleksaker. Det finns ingen support för dom som man kan förlita sig på. Vad händer om det blir en uppdatering? Vad händer om det blir en ändring?

Raspberry Pi skapades för barn för utbildning, inte för att Mercedes Benz S-klass 600 ska använda dom.

Gå till inlägget

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!

Skrivet av heretic16:

När jag kör din kod https://onlinegdb.com/ZrNnJBJQh så säger den följande. Detta betyder att den gav mig en varning. Jag kan ju ställa in en flagga på att jag ska få ett felmeddelande, istället för varning. Eller hur? Alltså är det mitt ansvar att säga åt min kompilator att granska för minnessäkerhet?

Gå till inlägget

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.

Visa signatur

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Redigera
Citera flera Citera
Permalänk
Medlem ★
●
Skrivet av Yoshman:

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...

Gå till inlägget

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...

Senast redigerat
Redigera
Citera flera Citera
Permalänk
Medlem ★
●
Skrivet av Ingetledigtnamn:

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...

Gå till inlägget

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?

Visa signatur

Desktop spel m.m.: Ryzen 9800X3D || MSI X870 Tomahawk Wifi || MSI Ventus 3x 5080 || Gskill FlareX 6000 64GB || Kingston KC3000 2TB || Samsung 970 EVO Plus 2TB || Samsung 960 Pro 1TB || Fractal Torrent || Asus PG42UQ 4K OLED
Arbetsstation: Ryzen 7945HX || Minisforum BD790i || Asus Proart 4070 Ti Super || Kingston Fury Impact 5600 65 GB || WD SN850 2TB || Samsung 990 Pro 2TB || Fractal Ridge
Proxmox server: Ryzen 5900X || Asrock Rack X570D4I-2T || Kingston 64GB ECC || WD Red SN700 1TB || Blandning av WD Red / Seagate Ironwolf för lagring || Fractal Node 304

Redigera
Citera flera Citera
Permalänk
Datavetare ★
●
Skrivet av Ingetledigtnamn:

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...

Gå till inlägget

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…)!

Visa signatur

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Redigera
Citera flera Citera
Permalänk
Medlem ★
●
Skrivet av Yoshman:

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?

Gå till inlägget

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!

Redigera
Citera flera Citera
Permalänk
Datavetare ★
●
Skrivet av Ingetledigtnamn:

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!

Gå till inlägget

Itanium hade betydligt fler problem än tröghet… Det var inte en bra ISA utanför ett par rätt specifika fall, ofta relaterat till flyttal (som historiskt var en svag punkt hos x86 men som man till största del rättat till via stöd för skalärer i SSE/AVX-enheterna). Det fanns helt enkelt rätt få tekniska anledningar att bli speciellt upphetsad över IA64, medan vi nu ser Apple, Qualcomm och även Arm själva designa ARM64 mikroarkitekturer som alla har bättre perf/Hz och bättre perf/transistor jämfört med Intels/AMDs senaste (och vi verkar vara överens om att det inte går att förklara med bristande kompetens hos Intels och AMDs designers).

Håller inte med om att det är en fundamentalt annorlunda marknad för telefoner jämfört med desktop. Arm tog en gigantisk risk och hade ARM64 varit ungefär som Itanium i “värdet av att lägga resurser på att byta till den ISA” hade det antagligen misslyckats. Nu gick det istället otroligt snabbt, väldigt mycket då förändringen gav så många tekniska fördelar i bättre prestanda, bättre prestanda/W och bättre prestanda/transistor.

I datacenter har ARM64 gått från 0 % till 10 % snabbare än vad AMD gick från ~0 % till 10 %. Vi får se hur det utvecklas framåt.

Och sedan Itanium har tekniken att binäröversätta från en ISA till en annan gjort gigantiska steg framåt. Specifikt spel är också en relativt tacksam programtyp att binäröversätta då väldigt mycket av de tyngsta lyften ligger i DirectX och GPU-drivarna, vilka kommer använd “native”-kod då det är OS-tjänster även om spelet stannar som x86_64.

Misstänker att både Apple och Qualcomm/Microsoft initialt utelämnade stöd för AVX då jag förstått att Intel hade en del patent som skulle kunna ställa till med problem (och Intel har hotat Qualcomm/Microsoft med just patentkortet kring x86-emulering). En rad patent har gått ut de senaste åren och Apple lade ju till stöd också för AVX i Rosetta 2 som kommer med årets MacOS Sequoia (släpptes denna vecka).

Men du har ändå tyvärr helt rätt i att det finns en stor tröghet, framförallt i något som att byta programspråk. Sedan jag började arbeta på 90-talet har jag bara varit med om att skriva om existerande kod två gånger i ett annat programspråk om vi ignorerar kodbaser under 10k rader. De som blev omskrivna var i sammanhanget rätt små, låga 100k rader kod.

Det betyder också att “safe C++” har en rätt brant uppförsbacke. För man har rätt mycket konstaterat att om man ska få ett riktigt bra resultat måste man göra signifikanta ändringar i språket. “Safe C++” kommer säkert att kunna uppnå många av Rusts fördelar, men det kräver att man gör en hel del modifikationer vilket är en risk i sig precis som du skriver.

Fast även här har det skett kvantsprång på senare tid i form av LLMs! Tror väldigt många följer DARPAs projekt TRACTOR. Precis som står i trådstarten har bland annat USAs regering tagit beslutet att man inte längre ska använda C och C++.

Projekt TRACTOR handlar om att med hjälp av LLMs maskinöversätta all deras C-kod till Rust.

Testade att stoppa in exemplet jag gav ovan i ChatGPTs “o1-preview”-modell. Den översatte inte bara det hela korrekt, den konstaterade också att den översatta koden för de felaktiga fallen (den tog alla) inte kommer att kompilera i Rust.

// Function demonstrating unsafe usage patterns that Rust prevents
fn horribly_broken() {
    // The following lines are commented out because they do not compile in Rust.
    // Rust's compiler ensures that references do not outlive the data they point to.

    // Attempting to create a string slice from a temporary String.
    // This would result in a dangling reference in C++, but Rust prevents it.
    /*
    let broken1: &str = &String::from("a temporary string");
    print_sw(broken1);
    */

Som ett annat snabbtest (jag hade inte själv använt LLMs på detta sätt innan) tog jag 2017 års Advent of Code, använde det året C++ och sa åt den att översätta till Rust. Här får man ju en snabbkontroll på om det verkar okej genom att se om svaren fortfarande blir rätt. Den gjorde rätt på alla 25 direkt och det blev riktigt prydlig Rust av det hela (faktiskt skrämmande bra resultat sett ur perspektivet: jag skriver kod som arbete, frågan är om det är dags att börja använda min master i kemi istället…).

Visa signatur

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Redigera
Citera flera Citera
Permalänk
Medlem
●

Är det någon som har koll på C++ senaste standard hur minnessäker den kommer vara?

Som jag har greppat allt. Använder man std::vector och std::shared_ptr så kommer man långt när det kommer till minnessäkerhet.

Men std::vector så kan man under körtid få ett kraschmeddelande om man överindexerar vektorn.
Med smarta pekare så har man en "garbage collector", typ.

Men vad kommer mer i c++26?

Redigera
Citera flera Citera
Permalänk
Medlem
●
Skrivet av heretic16:

Jag vill veta från er övriga hur denna utveckling går? Går det framåt med utvecklingen eller står det stilla? När kan vi förvänta oss ett minnessäkert C++? Hur i fall skulle detta gå till? Är det en flagga man aktiverar hos kompilatorn så den förbjuder en att använda vissa osäkra funktioner?

Gå till inlägget

Det här handlar nog mer om inkompetens hos myndigheter i USA, de har ingen aning om vad de pratar om.

Om jag påstår att av all maskinkod som exekveras på en processor så är kanske mer än 90% kompilerad från C eller C++. Nästan allt som körs på datorer är från de språken. Då ligger det nog ganska nära verkligheten
Ta ett språk som Python, det är C eller C++ eftersom det är en "skriptmotor" som tolkar python och denna är skriven i C eller C++. Python är alltså kompilerad C eller C++ kod (finns säkert något annat där med).

När det kommer till C++ språket så dominerar tre stycken kompilatorer, de är Microsofts CL samt GCC och CLang. C++ är så tekniskt avancerat att det är mycket svårt att skriva en bra kompilator och konkurrera.
Tittar man däremot på C finns det säkert över 100 kompilatorer. Så fort ett företag producerar en ny CPU måste de också skeppa en C kompilator för att det skall gå att skriva kod åt CPUn.
Skall de skeppa med något annat språk måste de först knacka en C kompilator som de använder för att göra det andra språket.

Angående minne så är det inte speciellt svårt att hantera. `new` och `delete` är inte jättesvårt.
Vad som är svårt är att designa en bra arkitektur och då hålla reda på minne samt att göra denna arkitektur snabb. Svårigheterna med minne är egentligen ett problem med hur man designar kod för program.
De flesta språk som påstår att de "löst" minneshantering kommer ofta med ramverk för hur de skall koda, då löser ramverket arkitekturen åt dem.

Men C++ kan göras förhållandevis "minnessäkert" idag och man använder smartpointers.
Tror däremot inte så många C++ gör det helt och hållet för något man bör tänka på är att det är ett fantastiskt verktyg att kunna hantera minnet. Det öppnar upp så många olika lösningsmöjligheter.

Men C++ kommer aldrig bli ett språk för majoriteten av utvecklare. De allra flesta utvecklare idag skriver primärt deklarativ kod, de skriver kod som använder komponenter skrivna med imperativ kod. Detta är nästan två helt olika yrken för man tänker helt annorlunda. Och att inte förstå skillnaden mellan imperativ och deklarativ kod tror jag orsakar mycket förvirring när programmering diskuteras. C++ är framförallt gjort för imperativ kodning.

Att C++ kommer dominera genererad maskinkod framöver beror framförallt på
- Framtidssäkert, skriver man C++ kod är man nära 99,9% säker på att den koden kan kompileras om 20 år.
- Prestanda, De bästa C++ kompilatorerna är tekniska under och kombinera det med friheten i språket C++
- Bakåtkompatibilitet. Att C++ måste vara bakåtkompatibelt är en garanti att de inte kan förstöra språket.
- Ingen som "äger" språket och därmed är det svårt att förstöra

De har kommit och kommer komma nya språk som blir poppis men de rusar ofta fram funktioner och förstår inte konsekvenserna. C++ har också gjort misstag men lärt sig även om det fortfarande görs misstag. Misstagen är inte alls lika allvarliga som andra språks misstag.

Kommer det nytt i andra språk som är bra är det sannolikt att de plockas upp i C++ med och då mer erfarenhet från andra språk, så det är mycket bra att det händer saker inom språkutvecklingen.

AI tror jag kommer göra mycket för de lite svårare språken. C++ har mängder med bibliotek men de är ofta svåra att använda. Ta boost exempelvis. Finns mycket bra där men tröskeln är så hög att få klarar det. AI är en stor hjälp för utvecklare att hantera svårare extern teknik.
AI hjälper även till bland enklare språk eller kanske helt tar över. Men utvecklare där brukar ha mindre koll på riskerna och kan skena iväg, producera mycket saker de senare inte kan underhålla. Deklarativ kod är ofta kvalitetsmässigt sämre än imperativ kod.

Senast redigerat
Redigera
Citera flera Citera
Permalänk
Medlem ★
●
Skrivet av klk:

Men C++ kommer aldrig bli ett språk för majoriteten av utvecklare. De allra flesta utvecklare idag skriver primärt deklarativ kod, de skriver kod som använder komponenter skrivna med imperativ kod. Detta är nästan två helt olika yrken för man tänker helt annorlunda. Och att inte förstå skillnaden mellan imperativ och deklarativ kod tror jag orsakar mycket förvirring när programmering diskuteras. C++ är framförallt gjort för imperativ kodning.

Gå till inlägget

De allra flesta utvecklare idag har aldrig ens petat på eller lärt sig något om deklarativ kod - vilket är synd, för det finns mycket att lära där.
Men sättet att tänka är inte så olika oavsett vilken programmeringsparadigm man använder.

Traditionellt delas programmeringsspråk upp i två huvudgrupper - deklarativa och imperativa.
De imperativa kan sedan delas upp i procedurorienterade och objektorienterade.
Deklarativa språk kan i sin tur delas upp i logiska och funktionella.

Procedurorienterade språk är sådana som klassisk C, Pascal, Basic, Fortran.
Objektorienterade är sådana som Smalltalk, Simula, Java, med flera.

Funktionella är språk som Lisp, Haskell, ML
Logiska språk har Prolog som det enda någorlunda kända exemplet.

Om man skall generalisera lite så är imperativa språk baserade på Turing-maskiner, medan de deklarativa utgår från lambda-kalkyl som sin matematiska grund.

Ingendera typ av programmeringsspråk är bättre än någon av de andra, men de lämpar sig olika bra för att lösa olika typer av problem.

Många språk stöder mer än en av ovanstående modeller, i åtminstone någon grad.
C, t.ex. är i grunden ett procedurellt språk, men existensen av funktionspekare gör att man kan skriva funktions-orienterad kod i det också - det är bara lite bökigare och mer begränsat än i ett funktionellt språk som Haskell.
C++ har C i grunden, men lägger sedan till stöd för objekt-orienterad programmering. Java och C# är i princip försök att kopiera C++, men med en renare grunddesign.

Redigera
Citera flera Citera
Permalänk
Medlem
●
Skrivet av Erik_T:

Men sättet att tänka är inte så olika oavsett vilken programmeringsparadigm man använder.

Gå till inlägget

Det viktiga att förstå är att man kan förstöra imperativ lösning med deklarativa tankegångar på en dag.

Däremot går det inte att förstöra en deklrativ lösning med imperativ kod (det är nästan alltid en mix) för det är per default förstörd kod och med det menar jag att man blandar in domänen och vips ryker återanvändbarhet.

Redigera
Citera flera Citera
Permalänk
Medlem ★
●
Skrivet av klk:

Det viktiga att förstå är att man kan förstöra imperativ lösning med deklarativa tankegångar på en dag.

Däremot går det inte att förstöra en deklrativ lösning med imperativ kod (det är nästan alltid en mix) för det är per default förstörd kod och med det menar jag att man blandar in domänen och vips ryker återanvändbarhet.

Gå till inlägget

Jag hävdar att det där är rent nonsens. Det når inte ens nivån av att vara fel.

Återanvändbar kod är lite av en myt.

Vad är det du tror att deklarativ kod innebär?

Redigera
Citera flera Citera
Permalänk
Datavetare ★
●
Skrivet av klk:

Det här handlar nog mer om inkompetens hos myndigheter i USA, de har ingen aning om vad de pratar om.

Gå till inlägget

Bara en FYI: Microsoft, Google och Meta har liknande policy och gissar att det är en av huvudanledningarna att myndigheterna i USA kan dra till med en sådan policy.

Detta baserar sig på statistik. De tre stora tech-jättarna har väldigt snarlika resultat där ca 70 % av de senaste årens säkerhets-sårbarheter är av den typ som inte skulle ha gått att utnyttja i "minnessäkra språk". Det skulle i de flesta fall varit en bugg, men inte en som skulle kunna utnyttjas för otillbörlig access av systemet.

Och sedan diskussionen ovan har det tillkommit en viktig detalj: från och med 1 januari 2026 måste företag som utvecklar programvara till myndigheter ha en plan för hur man ska migrera bort från miljöer som inte anses vara "memory safe".

Notera, en plan, kommer fortfarande vara tillåtet att använda C och C++ och även framåt verkar det fullt tillåtet, men för att fortsätta använda C eller C++ behöver man motivera varför.

Skrivet av klk:

Om jag påstår att av all maskinkod som exekveras på en processor så är kanske mer än 90% kompilerad från C eller C++. Nästan allt som körs på datorer är från de språken. Då ligger det nog ganska nära verkligheten
Ta ett språk som Python, det är C eller C++ eftersom det är en "skriptmotor" som tolkar python och denna är skriven i C eller C++. Python är alltså kompilerad C eller C++ kod (finns säkert något annat där med).

Gå till inlägget

För flera typer av systemprogrammering har historisk C och ofta (men inte alltid) C++ varit de enda realistiska alternativen. T.ex. kernel-programmering och utveckling på mikrokontrollers. Men för båda dessa exempel används idag också Rust, även om det inte är några stora mängder än.

För de flesta typer av projekt skulle jag bestämt hävda att det var länge sedan C++ dominerade (men finns självklart undantag, t.ex. spel). Back-end kod skrivs primärt i språk som Java, C#, JS, Python m.fl. Go är en av dominanterna för "cloud-native" programvara etc. Så är inte i närheten några 99 % totalt sett för C och C++.

Historisk var det nog precis som du skriver: tool-chain och run-time bibliotek för de flesta språk var skrivna i C och/eller C++.

Men finns gått om språk/ramverk som är "self-hosted" idag, t.ex.

Rust: nu bygger det på LLVM som är ett C++-projekt, men kompilator, standardbibliotek etc är allt skrivet i Rust

Go: kompilator, standardbibliotek, alla grundläggande verktyg är helt skrivna i Go

Zig: kompilator och standardbibliotek är skrivet i Zig

Sen finns hybrider

C#: kompilator och många verktyg är idag skrivna i C#, men run-time är fortfarande C++

Just Go är ett ett exempel där väldigt få bibliotek ens är wrappers kring C-bibliotek (vilket annars är vanligt i t.ex. Rust, C#, Python m.fl.). Det har primärt två orsaker

1. en av Go:s största styrkor är hur extremt portabelt det är i praktiken, även fast det är kompilerat kompilerar det till en enda "self-contained" binär som innehåller allt som behövs så länge man inte drar in externa C-bibliotek i form av dll/so filer
2. även om det rent handgripligen är väldigt lätt att anropa C-kod (stödet är integrerat i språket) så är det p.g.a. hur Go:s run-time fungerar väldigt ineffektivt att anropa C (i t.ex. C# är det ju "by-design" billigt att anropa C).

TL;DR är att även tech-jättarna har liknande policy för C och C++ samt det är knappast några 99 % av all kod som är C och C++ idag.

Visa signatur

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Redigera
Citera flera Citera
Permalänk
Medlem
●
Skrivet av Yoshman:

Bara en FYI: Microsoft, Google och Meta har liknande policy och gissar att det är en av huvudanledningarna att myndigheterna i USA kan dra till med en sådan policy.

Gå till inlägget

Det tror inte jag, jag tror det handlar om konkurrens och de stora techjättarna befarar problem. De vill inte ha duktiga programmerare som klarar av att hantera minne och de vill fortsätta tvinga in folk i deras "moln".

Skrivet av Yoshman:

Detta baserar sig på statistik. De tre stora tech-jättarna har väldigt snarlika resultat där ca 70 % av de senaste årens säkerhets-sårbarheter är av den typ som inte skulle ha gått att utnyttja i "minnessäkra språk". Det skulle i de flesta fall varit en bugg, men inte en som skulle kunna utnyttjas för otillbörlig access av systemet.

Gå till inlägget

Det där stämmer inte, nästan allt i "minnesäkra" språk är skrivet i C/C++. Nästan all exekverbar kod (maskinkod) är kompilerad C/C++. Inte konstigt om buggarna finns där då

Skrivet av Yoshman:

Och sedan diskussionen ovan har det tillkommit en viktig detalj: från och med 1 januari 2026 måste företag som utvecklar programvara till myndigheter ha en plan för hur man ska migrera bort från miljöer som inte anses vara "memory safe".

Gå till inlägget

Bra lobbat av techjättar eller vad jag läst så är det CIA/FBI som går ut med dessa riktlinjer. De vet mycket väl om att det inte går att ta bort. Skulle Python skriva om alla sina komponenter i något som är "memory safe", tror inte det.

Skrivet av Yoshman:

Men för båda dessa exempel används idag också Rust, även om det inte är några stora mängder än.

Gå till inlägget

Jag tror aldrig det kommer göras några större projekt i Rust, de har rusat fram språket och det finns för mycket designfel. Men jag tror rust kommer få många utvecklare för det passar väl till inom linuxvärlden, python eller javascript utvecklare som äntligen kan gå på att göra snabba applikationer.

Skrivet av Yoshman:

För de flesta typer av projekt skulle jag bestämt hävda att det var länge sedan C++ dominerade (men finns självklart undantag, t.ex. spel). Back-end kod skrivs primärt i språk som Java, C#, JS, Python m.fl. Go är en av dominanterna för "cloud-native" programvara etc. Så är inte i närheten några 99 % totalt sett för C och C++.

Gå till inlägget

C++ kommer aldrig "dominera", det är för svårt för en genomsnittlig utvecklare att skriva komponenter för andra miljöer men en majoritet av komponenter som används i andra språk kommer alltid vara skrivna i C/C++.
Duktiga C++ utvecklare är för produktiva eftersom koden har så väldigt lång livslängd och sällan är domänspecifik.
Skriver någon en bra XML parser idag kommer den vara bra om 20 år. Den kommer vara lätt att använda eftersom komponenter skrivna i C++ inte behöver installera en hel hög med annat för att det skall fungera.

Skrivet av Yoshman:

Historisk var det nog precis som du skriver: tool-chain och run-time bibliotek för de flesta språk var skrivna i C och/eller C++.
Men finns gått om språk/ramverk som är "self-hosted" idag, t.ex.
Rust: nu bygger det på LLVM som är ett C++-projekt, men kompilator, standardbibliotek etc är allt skrivet i Rust

Gå till inlägget

Påstår inte att jag är i närheten av kunnig i Rust men kör man Rust projekt som vips laddas mängder in i projektet. Säkert ok om man inte vill "bry sig" men skall företag göra saker långsiktigt fungerar inte den metoden.

Skrivet av Yoshman:

Go: kompilator, standardbibliotek, alla grundläggande verktyg är helt skrivna i Go
Zig: kompilator och standardbibliotek är skrivet i Zig

Gå till inlägget

Om de valt att skriva kompilatorer i det egna språket så tar de en stor risk. Det är inget som gynnar dem även om jag kan förstå det då de som skapar språken ofta är entusiaster och gärna vill sitta i språken och koda.

Skrivet av Yoshman:

tech-jättarna har liknande policy för C och C++ samt det är knappast några 99 % av all kod som är C och C++

Gå till inlägget

tech-jättarna är byråkratiska monster, de har mycket svårt att få tag i kompetens. Och med monopol försvinner incitament till att skriva bra kod, istället handlar det om att låsa kunderna. Det är ingen miljö som kompetens växer inom.

Viktigast är ändå att utvecklare måste lära sig hantera minne om de skall kunna producera bra saker. En majoritet av processorns arbete handlar om det, läsa och skriva till och från minnet.
Förstår inte de hur och varför eller får jobba med sådant kommer de aldrig klara av att skriva effektiv kod.

Redigera
Citera flera Citera
Permalänk
Medlem ★
●
Skrivet av klk:

Om jag påstår att av all maskinkod som exekveras på en processor så är kanske mer än 90% kompilerad från C eller C++. Nästan allt som körs på datorer är från de språken. Då ligger det nog ganska nära verkligheten
Ta ett språk som Python, det är C eller C++ eftersom det är en "skriptmotor" som tolkar python och denna är skriven i C eller C++. Python är alltså kompilerad C eller C++ kod (finns säkert något annat där med).

Gå till inlägget

90% tror jag är en ganska stor överskattning. Om du räknar all JIT-kod som C/C++-genererad för att JIT-kompilatorn är skriven i C/C++, så visst, då kommer vi säkert upp i 90%. Men i mina ögon är JIT-koden genererad av en annan kompilator än C/C++.

Nu körs ju mer och mer kod i din webb-browser, där JavaScript och WebAssembly JIT-kompileras innan koden exekveras. Många "applikationer" som du installerar på din dator i dag är bara en wrapper runt Chrome så all "business logic" i dessa är också JIT-kompilerad. Sedan har vi Java och .NET som båda JIT-kompileras. Både .NET och Java är vanliga i back end-sammanhang. Tillsammans med JIT-koden i browsern lär de stå för en ansenlig del av de exekverade instruktionerna.

Java/Kotlin i Android-telefoner kommer huvudsakligen Ahead-of-time-kompileras (vad heter det på svenska?), men det är i alla fall inte instruktioner som genereras av en C/C++-kompilator.

C/C++ dominerar helt klart och inom vissa områden, som embedded, är siffran säkerligen över 90%, men om vi kikar globalt, på alla instruktioner som exekveras, tror jag inte vi kommer upp dit trots att embedded-marknaden med consumer electronics och automotive är enormt stor.

Redigera
Citera flera Citera
Permalänk
Medlem
●
Skrivet av Ingetledigtnamn:

90% tror jag är en ganska stor överskattning. Om du räknar all JIT-kod som C/C++-genererad för att JIT-kompilatorn är skriven i C/C++, så visst, då kommer vi säkert upp i 90%. Men i mina ögon är JIT-koden genererad av en annan kompilator än C/C++.

Gå till inlägget

Normalt så det sista lagret, precis när data konverteras till något som passar användare. Där brukar andra språk ta över. Så det är riktigt men ser man till hur mycket sådan kod exekveras så är det oftast en mindre del.
Ta en vanlig databaslösning, det är databasens maskinkod som får gå varm och den behöver prestanda och är därför skriven med något som går att få snabbt.

Skrivet av Ingetledigtnamn:

Nu körs ju mer och mer kod i din webb-browser, där JavaScript och WebAssembly JIT-kompileras innan koden exekveras. Många "applikationer" som du installerar på din dator i dag är bara en wrapper runt Chrome så all "business logic" i dessa är också JIT-kompilerad. Sedan har vi Java och .NET som båda JIT-kompileras. Både .NET och Java är vanliga i back end-sammanhang. Tillsammans med JIT-koden i browsern lär de stå för en ansenlig del av de exekverade instruktionerna.

Gå till inlägget

Ja men browsern är skriven i C/C++ och där spenderas mest tid. En javascript motor (parsa och konvertera till något körbart) är med stor sannolikhet också skriven i C/C++.
Samma med Java och .NET, gissar att det mesta där är skrivet i C/C++

Domänkod, de del som anpassar data till specifikt område. Där arbetar de flesta utvecklarna och här kommer andra språk än C++ dominera. C++ passar inte för sådant så det kommer vara en majoritet av utvecklare som sitter i andra språk för denna delen kräver mest arbete.

När de pratar minnessäkert så tänk på att det finns gott om skydd direkt i operativsystem. Man kan inte skriva ett program som tar ner ett operativsystem idag om man inte medvetet går in för det. Processorn har olika nivåer där ett "vanligt" program aldrig kommer åt systemkritiska saker.
Förutom det så används andra typer av virtuella lösningar som docker och liknande. Det är många som inte förstår dessa riktlinjer då de saknar logik såvida det inte handlar om att tech jättar vill skydda sina monopol

Senast redigerat
Redigera
Citera flera Citera
Permalänk
Datavetare ★
●
Skrivet av klk:

Det där stämmer inte, nästan allt i "minnesäkra" språk är skrivet i C/C++. Nästan all exekverbar kod (maskinkod) är kompilerad C/C++. Inte konstigt om buggarna finns där då

Gå till inlägget

Dels är det allt vanligare att språk/miljöer blir "self-hosted", men framförallt spelar det väl ingen roll vad runtime är skrivet i?

Finns rätt bra "bevis" för att C kan vara väldigt tillförlitligt. Har haft det tveksamma nöjet (kul att testa, hoppas aldrig behöva göra det igen för det var skittråkigt!) att skriva C-kod mot DO-178C specifikationen.

För högsta nivå krävs där att man har tester som täcker 100 % av alla assembler-instruktioner som genereras samt 100 % täckning av varje villkorat hopp. Typiskt pris på sådan kod är ~$100 per statement, d.v.s. helt orimligt för allt där det inte är ett hårt krav.

Så finns inget motsatsförhållande i "runtime är skriven i C++" och "det kommer bli färre säkerhetshål om man skriver i C#/Python/Java/etc". Detta då man redan har accepterat en relativt dyr/kompilerad/noggrann utveckling av runtime, som primärt numera är i "serviceläge", medan nya features helt utvecklas i "minnessäkra språk".

Det de "minnessäkra" språken primärt tillför är att de eliminerar den idag vanligaste orsaken till säkerhetsproblem i kod skriven i C eller C++. Skulle säga att den som inte drar nytta det om det är möjligt uppvisar bristande kompetens.

Men även framåt kommer det finns fall när man inte har något realistiskt val annat än C eller C++, men det lär bli allt färre sådana.

Uppenbarligen förstår ISO C++ kommitté problematiken och de fattar att "smart-pointers" inte alls är en tillräcklig lösning.

Men är själv inte säker att "rätt" sätt här är att försöka fixa problemet (verkar inte heller som C++ community är eniga heller). För problemet blir uppenbart när man tittar på utkastet för "safe C++", det ser inte längre ut som "vanlig C++" utan ser väldigt mycket ut som "Rust skrivet med C++-bryting". Vad är då poängen?

Skrivet av klk:

C++ kommer aldrig "dominera", det är för svårt för en genomsnittlig utvecklare att skriva komponenter för andra miljöer men en majoritet av komponenter som används i andra språk kommer alltid vara skrivna i C/C++.
Duktiga C++ utvecklare är för produktiva eftersom koden har så väldigt lång livslängd och sällan är domänspecifik.
Skriver någon en bra XML parser idag kommer den vara bra om 20 år. Den kommer vara lätt att använda eftersom komponenter skrivna i C++ inte behöver installera en hel hög med annat för att det skall fungera.

Gå till inlägget

Min erfarenhet av detta är att C absolut har och har haft extrem stabilitet. Men har haft en en del problem med att C++ projekt råkat ut för "bit-rot" i form av att saker som fungerade på system version N slutade att fungera på version N+M.

Och till skillnad från C (och flera andra språk) valde ju C++ redan från starta att INTE ha en stabil ABI. Så på binärnivå går det inte allt lita på att C++ program/bibliotek är bakåtkompatibla.

Nämnde Go ovan. En av de saker som gjort Go så väldigt populärt är specifikt att de har en garanti kring att allt från och med version 1.0 alltid ska fortsätta att fungera på framtida 1.x kompilatorer. Och de har nu met än 10-årigt track-record att de i praktiken också kan upprätthålla det!

Likt C är en annan "killer-feature" i Go att det är så enkelt att lära sig språket. Både C++ och Rust har problemet att de är extremt komplexa språk där man tyvärr också behöver rätt hög nivå för att hantera dem på "vettig sätt". En ung jag tyckte det var "coolt" (lärde mig rätt mycket att programmera i assembler och C++ och ägnat ca två decennier av karriärer med embedded/RTOS/kernel primärt i C men även C++), en gammal jag ser det primärt som en belastning.

Så idag finns alternativ även om kraven är t.ex. stabilitet!

Skrivet av klk:

Normalt så det sista lagret, precis när data konverteras till något som passar användare. Där brukar andra språk ta över. Så det är riktigt men ser man till hur mycket sådan kod exekveras så är det oftast en mindre del.
Ta en vanlig databaslösning, det är databasens maskinkod som får gå varm och den behöver prestanda och är därför skriven med något som går att få snabbt.

Ja men browsern är skriven i C/C++ och där spenderas mest tid. En javascript motor (parsa och konvertera till något körbart) är med stor sannolikhet också skriven i C/C++.
Samma med Java och .NET, gissar att det mesta där är skrivet i C/C++

Gå till inlägget

Ett program som Visual Studio Code är mer ett "rent Typescript projekt" än vad Chrome är ett "rent C++ projekt"

Chrome är primärt skrivet i C++, men ca 1/4 är skrivet i andra språk (där märkligt nog Java, inte JavaScript, är det vanligaste).

Historiskt var C++ rätt mycket det självklara valet för desktop-applikationer. Skulle gissa att det är långt mindre än hälften av desktop-applikationer som skrivs i C++ idag. Skulle själv tänka rätt många gånger innan jag inte väljer C# för att utveckla en Windows-applikation och något likt Electron (så Typescript) om det även ska fungera på MacOS/Linux.

Nämnde spel ovan, även de börjar ju i allt större utsträckning skrivas i just C# (en väldigt viktig orsak är just hur enkelt och effektivt det är att anropa C-bilbliotek från C#, för både Windows och spel bilbiotek är primärt skriva i C++ med C-API än).

Visa signatur

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Redigera
Citera flera Citera
Permalänk
Medlem
●
Skrivet av Yoshman:

Ett program som Visual Studio Code är mer ett "rent Typescript projekt" än vad Chrome är ett "rent C++ projekt"

Chrome är primärt skrivet i C++, men ca 1/4 är skrivet i andra språk (där märkligt nog Java, inte JavaScript, är det vanligaste).

Gå till inlägget

VS Code använder Electron tror jag som i sin tur använder Chromium och jag kan nog med stor säkerhet säga att det när miljön används är det framförallt maskinkod från kompilerad C/C++ som körs.

Microsoft behövde få fram en kopia av Sublime Text som växte snabbt i popularitet, samtidigt har de svårt att skaka fram duktiga programmerare. Sublime Text är ett litet mästerverk och tror det från början skrevs av en enda person. Först med många smarta lösningar så det är uppenbart att det är en duktig kodare som kanske vart lite trött på andra editorer och gjorde något som hade det han saknade.
Känner inte till om Sublime text använder någon annat ramverk för grafiken eller om de skrivit sitt egna men tror faktiskt de gjort det själva.

Använder själv Sublime ibland då den är mycket rappare jämfört med VS Code (gillar inte vs code alls). Visual Studio är min vanliga miljö.

Redigera
Citera flera Citera
Permalänk
Medlem ★
●
Skrivet av Sinery:

"går programmera minnessäkert med C++ om man använder rätt funktioner"
Man kan inte lite på programmerarna och C++ har för mycket baggage för att konvertera gamla projekt till safe++ eller allt dom kallar det och om man har ett nytt projekt varför bygga det i C++ istället för ett språk som är minnessäkert i början.

Gå till inlägget

Beror ju såklart på projektet. Att programmera en skrivare kanske inte är helt optimalt/eller möjligt med java, rust, go.

Visa signatur

Dator:
Intel Core i5 14600K 3.5 GHz 44MB
ASUS Prime Z790-P
G.Skill 32GB (2x16GB) DDR5 7200MHz CL 35 Triden
EVGA GeForce RTX 3070 8GB XC3 ULTRA

Redigera
Citera flera Citera
Permalänk
Medlem ★
●
Skrivet av klk:

Använder själv Sublime ibland då den är mycket rappare jämfört med VS Code (gillar inte vs code alls). Visual Studio är min vanliga miljö.

Gå till inlägget

Bytte från VS till Rider för länge sen. Så himla mkt bättre och trevligare!

Visa signatur

Dator:
Intel Core i5 14600K 3.5 GHz 44MB
ASUS Prime Z790-P
G.Skill 32GB (2x16GB) DDR5 7200MHz CL 35 Triden
EVGA GeForce RTX 3070 8GB XC3 ULTRA

Redigera
Citera flera Citera
Permalänk
Datavetare ★
●
Skrivet av klk:

VS Code använder Electron tror jag som i sin tur använder Chromium och jag kan nog med stor säkerhet säga att det när miljön används är det framförallt maskinkod från kompilerad C/C++ som körs.

Microsoft behövde få fram en kopia av Sublime Text som växte snabbt i popularitet, samtidigt har de svårt att skaka fram duktiga programmerare. Sublime Text är ett litet mästerverk och tror det från början skrevs av en enda person. Först med många smarta lösningar så det är uppenbart att det är en duktig kodare som kanske vart lite trött på andra editorer och gjorde något som hade det han saknade.
Känner inte till om Sublime text använder någon annat ramverk för grafiken eller om de skrivit sitt egna men tror faktiskt de gjort det själva.

Använder själv Sublime ibland då den är mycket rappare jämfört med VS Code (gillar inte vs code alls). Visual Studio är min vanliga miljö.

Gå till inlägget

Fast vad spelar det för roll vad Electron är skrivet i (kollar man dessa git-repo är det strax över 50 % C++, strax över 30 % Typescript + lite annat)?

Det ändrar inte det faktum att applikationer som använder Electron är skrivna i ett "memory safe" språk och det därför inte blir den typ av sårbarheter som detta skyddar mot.

Självklart kan de då förekomma typiska C++ sårbarheter i själva runtime, men man slipper det i alla fall i applikationen. Vilket är en fördel på flera sätt, inte minst då applikationskoden lär röra på sig betydligt mer än runtime-koden så större risk att det blir buggar i applikationen.

Tog just VS Code som exempel då jag gillar det (betydligt mer än Visual Studio). Men då jag för tillfället jobbar med C#/.NET8, WinRT3 och lite sådant får man hålla sig till Visual Studio då stödet för sådant inte är på samma nivå i VS Code.

Och givet att du skriver att du också använder Visual Studio: ser inte riktigt hur hastigheten i VS Code är ett problem i jämförelse. VS Code är absolut inte den snabbaste editor jag använt (var under många år en Emacs och till mindre del VIM-användare). Men VS Code är ju en raket jämfört med Visual Studio, trots Electron.

Visa signatur

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Redigera
Citera flera Citera
Permalänk
Medlem
●
Skrivet av Yoshman:

Fast vad spelar det för roll vad Electron är skrivet i (kollar man dessa git-repo är det strax över 50 % C++, strax över 30 % Typescript + lite annat)?

Gå till inlägget

För användaren spelar det knappt någon roll alls, fungerar applikationen som förväntat så är användare nöjd.

Men diskussionen här tar upp dumheterna USAs myndigheter gått ut med att skriva kod i "minnessäkra" språk. Det är nästan lika dumt som att säga att bilar inte får lov att köra med hjul så därför tror jag inte på orsakerna de nämner. Tror det är något annat som ligger bakom.

Applikationsutvecklare har hårt tryck på sig att utveckla saker som fungerar för kunden, gör det inte det så blir det jobbigt.

Och skulle USA och Europa gå så långt som att förbjuda C++ kommer asien att slakta oss inom mjukvara också. Våra politiker verkar göra allt de kan för att förstöra förutsättningarna och flytta all tillverkning ill asien.

Skrivet av Yoshman:

Och givet att du skriver att du också använder Visual Studio: ser inte riktigt hur hastigheten i VS Code är ett problem i jämförelse. VS Code är absolut inte den snabbaste editor jag använt (var under många år en Emacs och till mindre del VIM-användare). Men VS Code är ju en raket jämfört med Visual Studio, trots Electron.

Gå till inlägget

För mig så är det framförallt problematiskt med att editorn är seg på att hänga med med markeringar. Typ som att om man rättar en sak som markerats som fel så dröjer det en stund innan editorn fattar att det är rättat. Det är speciell så när jag kör WSL.
Debuggern går heller inte att jämföra med Visual Studios, tänker då på C++
VSCode har obland svårt att hoppa till deklarationer/definitioner. Kör man CMake fattar den inte alls (i alla fall inte för mig), variabler och annat i CMake alltså

Senast redigerat
Redigera
Citera flera Citera
1 2 3 4 5 6 7 8
Skriv svar