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

20-talets högsta prioritet på språk - Säkerhet & Snabbhet

1 2 3 4
Skriv svar
Permalänk
Medlem ★
●
Skrivet av heretic16:

Jag vet inte vad för korkade saker som C++ har.

Är detta inte vanligt med programmeringsspråk? Jag menar, jag ser många som tycker att Rust är lösningen på allt. Sedan så ser jag att vissa anser att Zig är bättre än Rust och Google's Carbon kommer konkurrera ut exakt alla, speciellt Rust. Det är många exalterade situationer.

Gå till inlägget

”Bättre” är en åsikt. Du kan få tycka att C++, Zig, Go eller Swift är bättre än Rust, och det beror ganska mycket på var du skall använda dem. Det går garanterat att göra ännu bättre programspråk. Min poäng (och många andras i den här tråden) är att det är omöjligt att göra C++ lika säkert som Rust utan att det blir ett helt annat språk. Om du väntar på det så får du vänta för evigt. C++ är inte dött och lär inte dö under min livstid (upptäckte av en slump att ett av programmen jag använder på jobbet har en backend delvis skriven i fucking COBOL!) men om du skall skriva ett nytt program idag, så bör du överväga något annat. Kan du inget annat än C++ så kan det vara en god idé att lära sig det. Ironiskt nog kommer sannolikt C att överleva C++, eftersom det fortfarande är överlägset i kerneln.

Den moderna utvecklingen i kompilatorer - dvs, LLVM, samt att dess existens har fått gcc att steppa upp lite - gör att det inte längre är lika svårt att hitta på ett nytt programspråk. Folk experimenterar, och det är bra, för vi satt fast ett tag där.

Visa signatur

5900X | 6700XT

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

”Bättre” är en åsikt. Du kan få tycka att C++, Zig, Go eller Swift är bättre än Rust, och det beror ganska mycket på var du skall använda dem. Det går garanterat att göra ännu bättre programspråk. Min poäng (och många andras i den här tråden) är att det är omöjligt att göra C++ lika säkert som Rust utan att det blir ett helt annat språk. Om du väntar på det så får du vänta för evigt. C++ är inte dött och lär inte dö under min livstid (upptäckte av en slump att ett av programmen jag använder på jobbet har en backend delvis skriven i fucking COBOL!) men om du skall skriva ett nytt program idag, så bör du överväga något annat. Kan du inget annat än C++ så kan det vara en god idé att lära sig det. Ironiskt nog kommer sannolikt C att överleva C++, eftersom det fortfarande är överlägset i kerneln.

Den moderna utvecklingen i kompilatorer - dvs, LLVM, samt att dess existens har fått gcc att steppa upp lite - gör att det inte längre är lika svårt att hitta på ett nytt programspråk. Folk experimenterar, och det är bra, för vi satt fast ett tag där.

Gå till inlägget

Jag skulle gärna vara sugen på att testa Rust. Men jag hittar dock inga bra bibliotek för Rust. Dessutom är jag en person som värderar språk som ändras extremt långsamt. Rust updateras väldigt snabbt och får många nya funktioner.

Till skillnad från C och C++ som uppdateras typ en gång vart fjärde år. Detta betyder att jag kan investera min tid och skriva kod som inte blir föråldrat.

Just nu skriver jag C++ kod för ImGui. Jag vet att det finns ett ImGui-bibliotek för Rust, men projektet verkar ha dött ut.
Dessutom finns det inga seriösa utvecklare inom halvledare som använder Rust. Istället är det bara C och i vissa fall C++ som gäller.

Jag har sett att MicroEj använder Java för att programmera hårdvara. Coolt.

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

Jag skulle gärna vara sugen på att testa Rust. Men jag hittar dock inga bra bibliotek för Rust. Dessutom är jag en person som värderar språk som ändras extremt långsamt. Rust updateras väldigt snabbt och får många nya funktioner.

Till skillnad från C och C++ som uppdateras typ en gång vart fjärde år. Detta betyder att jag kan investera min tid och skriva kod som inte blir föråldrat.

Just nu skriver jag C++ kod för ImGui. Jag vet att det finns ett ImGui-bibliotek för Rust, men projektet verkar ha dött ut.
Dessutom finns det inga seriösa utvecklare inom halvledare som använder Rust. Istället är det bara C och i vissa fall C++ som gäller.

Jag har sett att MicroEj använder Java för att programmera hårdvara. Coolt.

Gå till inlägget

Redan nämnt i tråden, men du kanske missade det: Rust-gänget har faktiskt tänkt ett steg längre än de flesta andra just kring stabilitet. Finns något som kallas "Editions", dessa släpps rätt sällan (finns idag 3 st, 2015, 2018 och 2021) och kör man t.ex. Edition 2015 är den garanterad att vara helt kompatibel. Varje enskild "crate" (tänk bibliotek i C/C++) måste använda samma "edition", men en applikation kan använda sig av "crates" som var och en kör olika "editions".

Angående användningen

Världens största kommersiella RTOS, VxWorks, har stöd för Rust out-of-the-box.
Infineon, Tysklads största tillverkare av halvledare, har Rust stöd för deras mikrokontrollers.
AVR har rätt bra stöd för Rust, AVR-baserade mikrokontrollers är kanske mest kända av gemene man i kontext av Arduino men de är billiga och populära kretsar för custom-designer.
ESP8266/ESP32 + FreeRTOS + Rust finns också.

Linux/Windows har numera officiellt stöd för Rust i kärnan. Linux är utanför mikrokontrollers/OS-lösa system idag världens största embedded OS, det har definitivt Rust stöd.

Däremot ska man vara medveten om att no_std varianten av Rust inte nått samma mognad som "normalversionen" av språket. Med no_std går det redan idag att använda Rust ihop med de flesta aktuella mikrokontrollers och OS-lösa system.

Men gör man nischade saker är det självklart ett problem att nivån på vissa bibliotek kan ha tveksam kvalité. Just det var något som fick mig att gå från Rust till Go i ett projekt, visade sig att Go har betydligt mognare bibliotek för RS485/ModBus än Rust (efter att använt det skulle jag säga att Go biblioteket även slår de C bibliotek jag testat på fingrarna i funktion och stabilitet!).

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 heretic16:

Hur har dom löst det innan att skriva säkert C++ kod?

Gå till inlägget

På samma sätt som med kod skriven i alla andra språk - skickliga programmerare som vet vad de håller på med, och rejält med testning utförd av duktiga testare.

Det finns inget programmeringsspråk eller kompilator som kan upptäcka eller förhindra alla fel som programmerare kan ställa till med.
I en del programmeringsspråk (som till exempel C++) så är det dock väldigt enkelt att skriva dålig kod, vilket gör att kod skriven av medelmåttiga programmerare i sådana språk ofta är dålig. (Dålig kod inkluderar felaktig kod, men även kod som är svår att läsa eller förstå och kod som är svår att modifiera i efterhand)
Andra programmeringsspråk (som till exempel Rust) gör det lite svårare att skriva dålig kod vilket i sig minskar förekomsten av fel.

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

Jag skulle gärna vara sugen på att testa Rust. Men jag hittar dock inga bra bibliotek för Rust. Dessutom är jag en person som värderar språk som ändras extremt långsamt. Rust updateras väldigt snabbt och får många nya funktioner.

Till skillnad från C och C++ som uppdateras typ en gång vart fjärde år. Detta betyder att jag kan investera min tid och skriva kod som inte blir föråldrat.

Gå till inlägget

Det är sant att det finns väldigt många externa bibliotek för C och C++. Det är en av de mycket få vettiga anledningar som finns att välja C++ för ett nytt projekt idag. En annan är om utvecklaren/utvecklarna redan kan C++ bra men inte behärskar alternativen.

Vart fjärde år är rätt ofta. C++ är ett språk som utvecklas och förvandlas snabbt.

Om man skriver C++ enligt senaste standarden, och enligt de normer och konventioner som finns för hur man skriver bra C++ kod idag, så ser koden väldigt annorlunda ut mot C++ kod som skrevs för 25 år sedan enligt den tidens best practice. Med andra ord så är den 25 år gamla C++ koden kraftigt föråldrad idag. Antagligen kommer C++ kod som skrivs idag vara lika kraftigt föråldrad om 25 år.
Bakåtkompatibilitet i standarden gör att den 25 år gamla koden antagligen fortfarande är kompatibel med nyare standard och fungerar någorlunda, men den är garanterat inte skriven som C++ kod bör skrivas idag.

C har utvecklats långsammare. 25 år gammal C kod skiljer sig inte så mycket från C kod skriven idag. Det har tillkommit funktionalitet, men hur man använder språker har inte ändrats mycket.

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

Antagligen kommer C++ kod som skrivs idag vara lika kraftigt föråldrad om 25 år.

Gå till inlägget

Det här kan man ju få äta upp inom 25 år, men är det så säkert? Många av de ytliga förändringarna har ju gått mot att förenkla språket (och skala bort tekniska detaljer som iteratorer och liknade) och där finns väl en gräns för hur långt man kan gå? Känns det inte ganska rent redan?
Annars håller jag förstås med om att det förmodligen kommer fortsätta hända saker snabbt.

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

Det här kan man ju få äta upp inom 25 år, men är det så säkert? Många av de ytliga förändringarna har ju gått mot att förenkla språket (och skala bort tekniska detaljer som iteratorer och liknade) och där finns väl en gräns för hur långt man kan gå? Känns det inte ganska rent redan?
Annars håller jag förstås med om att det förmodligen kommer fortsätta hända saker snabbt.

Gå till inlägget

Säkert är det inte, utan mest en kvalificerad gissning.

Redigera
Citera flera Citera
Permalänk
Medlem
●

Är det någon som kan läsa av assemblerkod från Rust via GoodBolt? Jag har tydligen problem att generera assemblerkod. Jag vill jämföra likvärdiga exempel mellan C++ och Rust för att kolla vem som ger minst assemblerkod.

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

Är det någon som kan läsa av assemblerkod från Rust via GoodBolt? Jag har tydligen problem att generera assemblerkod. Jag vill jämföra likvärdiga exempel mellan C++ och Rust för att kolla vem som ger minst assemblerkod.

Gå till inlägget

Vad är problemet?

Är väl bara göra något likt detta och sen slänga in den kod du vill jämföra.

Sen är ju frågan om "minst" assembler kod alltid är bäst...

I vissa lägen kommer Rust generera mer för den helt enkelt kollar fler saker runtime. Sen kan det bli rätt mycket mer assembler om kompilatorn t.ex. försöker sig på SIMD-optimeringar (händer ibland vid -O3 i alla fall), mer kod men typiskt snabbare.

Så är långt ifrån lätt att göra något supervettig med en sådan jämförelse.

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
●

Jo, det är alltid bättre med mindre assemblerkod. Så länge man får funktionen som man önskar.

En sak till.
Min IDE kan avgöra om jag glömmer initialisera variabler för C++.
Är det IDE:n som larmar eller är det kompilatorn?

Jag använder Visual Studio Community och som jag uppfattar den, så verkar IDE:n kunna larma om jag gör fel.
Det den inte larmar om är minnesläckor eller överindexeringar.

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

Jo, det är alltid bättre med mindre assemblerkod. Så länge man får funktionen som man önskar.

Gå till inlägget

Kan du utveckla varför? Har ingen koll på assemblerkod så är nyfiken på detta.

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

Jo, det är alltid bättre med mindre assemblerkod. Så länge man får funktionen som man önskar.

Gå till inlägget

Det är väl bättre med 20 byte kod än 10 byte kod om 20 byte är klart snabbare? (T ex Loop unrolling)
Om du inte försöker kompilera för antika datorer med några MB RAM eller dylikt.

Visa signatur

Asus ROG STRIX B550-F / Ryzen 5800X3D / 48 GB 3200 MHz CL14 / Asus TUF 3080 OC / WD SN850 1 TB, Kingston NV1 2 TB + NAS / Corsair RM650x V3 / Acer XB271HU (1440p165) / LG C1 55"
NAS: 6700K/16GB/Debian+ZFS | Backup (offsite): 9600K/16GB/Debian+ZFS

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

Kan du utveckla varför? Har ingen koll på assemblerkod så är nyfiken på detta.

Gå till inlägget

Varför mer än vad man behöver?

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

Det är väl bättre med 20 byte kod än 10 byte kod om 20 byte är klart snabbare? (T ex Loop unrolling)
Om du inte försöker kompilera för antika datorer med några MB RAM eller dylikt.

Gå till inlägget

Om man har gjort en kod som är ej optimerad eller rent av dåligt skrivet så bör man börja där istället.
Jag skulle säga att en enklare kod är alltid snabbare än en avancerad kod. Den avancerade koden har alltid för mycket i bagaget och dom som har skrivit den är säkerligen mer intresserade utav att lära sig nya funktioner i språket, än att göra klar jobbet så enkelt som möjligt.

T.ex när jag anropar databaser via MySQL Connector/C++ så låter jag alltid databasen sortera åt mig. Finns ingen anledning att skriva extra C++ kod, när databasen kan göra sina rutiner

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

Varför mer än vad man behöver?

Gå till inlägget

Så länge de försöker göra samma sak på samma sätt och man kan se att den ena krånglar till det för sig kan det ju ge något, men om de har olika lösningar blir det ju värre. Det man egentligen vill veta är ju vilket som går fortast.

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

Så länge de försöker göra samma sak på samma sätt och man kan se att den ena krånglar till det för sig kan det ju ge något, men om de har olika lösningar blir det ju värre. Det man egentligen vill veta är ju vilket som går fortast.

Gå till inlägget

Snabbhet är det jag högst värderar när det kommer till ett språk. Snabbhet och konservativt. Men Rust säkerhet är självklart en framtid ser jag.
Just nu skriver jag om ett program för att hantera databaser i C++.
Jag använder mig ImGui.

Detta borde du testa. Det är riktigt snabbt. Jag körde först QT. Det var bra, men allt skulle skrivas i OOP. Dom hade dåligt stöd för grafer och databaser. Det gick, men det var inte direkt smidigt.

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

Jag skulle säga att en enklare kod är alltid snabbare än en avancerad kod. Den avancerade koden har alltid för mycket i bagaget och dom som har skrivit den är säkerligen mer intresserade utav att lära sig nya funktioner i språket, än att göra klar jobbet så enkelt som möjligt.

Gå till inlägget

Visst håller jag med till viss del, fast när det gäller höga prestandakrav så blir ju kod oftast extremt komplex, snarare än simpel.

Kolla t ex in denna optimerade implementation av strcpy.

Jämför sedan den med denna kod som en väldigt simpel C-implementation ger via GCC (-O2)

strcpy(char*, char const*):
        mov     rax, rdi
        xor     edx, edx
.L2:
        movzx   ecx, BYTE PTR [rsi+rdx]
        mov     BYTE PTR [rax+rdx], cl
        add     rdx, 1
        test    cl, cl
        jne     .L2
        ret

Den första är visserligen även mer flexibel än att enbart implementera strcpy(), men oavsett så är den också snabbare.
(Skulle de lägga ner det där arbetet för att få en långsammare funktion?)

Visa signatur

Asus ROG STRIX B550-F / Ryzen 5800X3D / 48 GB 3200 MHz CL14 / Asus TUF 3080 OC / WD SN850 1 TB, Kingston NV1 2 TB + NAS / Corsair RM650x V3 / Acer XB271HU (1440p165) / LG C1 55"
NAS: 6700K/16GB/Debian+ZFS | Backup (offsite): 9600K/16GB/Debian+ZFS

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

Jag använder mig ImGui.

Detta borde du testa. Det är riktigt snabbt. Jag körde först QT. Det var bra, men allt skulle skrivas i OOP. Dom hade dåligt stöd för grafer och databaser. Det gick, men det var inte direkt smidigt.

Gå till inlägget

Jag tror att vi har diskuterat detta tidigare, men jag vet inte om jag håller med. Qt har (gott) stöd för både databaser, grafer och grafik och att kritisera kritisera databasstödet och istället gå till något som inte har något stöd alls är väl en smula märkligt? Du kan förstås lösa det via externa bibliotek, men det hade ju fungerat lika bra i Qt.

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

Jo, det är alltid bättre med mindre assemblerkod. Så länge man får funktionen som man önskar.

En sak till.
Min IDE kan avgöra om jag glömmer initialisera variabler för C++.
Är det IDE:n som larmar eller är det kompilatorn?

Gå till inlägget

Kan vara endera beroende på typen av fel. Oavsett vilket så måste delar av en kompilators jobb göras för att kunna hitta något som helst problem i kod, men en text-editor eller IDE kan göra vissa enkla kontroller, och i fallet med en IDE så kan den tolka kompilatorns felmeddelanden så att man kan gå direkt till rätt plats i koden.
Just för att upptäcka saknad initialisering av en variabel så är det nästan säkert kompilatorn som varnar - en IDE gör ytterst sällan så pass avancerad analys av koden.

Mindre assemblerkod är inte alltid bättre. I en del fall så kan något mer komplicerad assemblerkod generera snabbare kod än kortast möjliga assemblerkod - men det är nästan alltid högst arkitekturberoende.

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

Kan vara endera beroende på typen av fel. Oavsett vilket så måste delar av en kompilators jobb göras för att kunna hitta något som helst problem i kod, men en text-editor eller IDE kan göra vissa enkla kontroller, och i fallet med en IDE så kan den tolka kompilatorns felmeddelanden så att man kan gå direkt till rätt plats i koden.
Just för att upptäcka saknad initialisering av en variabel så är det nästan säkert kompilatorn som varnar - en IDE gör ytterst sällan så pass avancerad analys av koden.

Mindre assemblerkod är inte alltid bättre. I en del fall så kan något mer komplicerad assemblerkod generera snabbare kod än kortast möjliga assemblerkod - men det är nästan alltid högst arkitekturberoende.

Gå till inlägget

Jag tycker min IDE verkar göra mer än bara så.
Vad min IDE kan avgöra är om jag har glömt initialisera ett objekt, variabel eller liknande.
Även om jag glömmer frigöra minnet så larmar den. Men den säger inte vart felet är dock. Felet kommer när programmet har slutat köras.

Samt den kan inte avgöra om man överindexerar arrayer. Skulle min IDE kunna analysera detta så är jag riktigt nöjd med C++ för detta är något som jag stöter på ofta.

Jag brukar använda valgrind för att avgöra om jag överindexerar. Men valgrind finns bara för Linux.

Fick reda på idag att Rust har väldigt ergonomiska felmeddelanden.

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

Jag skulle säga att en enklare kod är alltid snabbare än en avancerad kod.

Gå till inlägget

Jag skulle säga att det är helt fel. Den enklaste och kortaste algoritmen för att lösa ett problem är mycket sällan den mest effektiva.

För att ta ett trivialt exempel så är en selection sort en av de absolut enklaste sorteringsmetoderna, men den är ineffektiv.
Mergesort kräver mer avancerad kod, men i nästan alla fall så är den betydligt snabbare - O(n log n) kontra O(n^2) för selection sort.

Däremot stämmer det att man inte skall krångla till saker i onödan. I första hand skall man skriva kod som tydligt uttrycker det man vill göra, och först i efterhand skriva en mer avancerad och mer optimerad variant om det visar sig behövas.

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

Jag tycker min IDE verkar göra mer än bara så.
Vad min IDE kan avgöra är om jag har glömt initialisera ett objekt, variabel eller liknande.
Även om jag glömmer frigöra minnet så larmar den. Men den säger inte vart felet är dock. Felet kommer när programmet har slutat köras.

Samt den kan inte avgöra om man överindexerar arrayer. Skulle min IDE kunna analysera detta så är jag riktigt nöjd med C++ för detta är något som jag stöter på ofta.

Jag brukar använda valgrind för att avgöra om jag överindexerar. Men valgrind finns bara för Linux.

Fick reda på idag att Rust har väldigt ergonomiska felmeddelanden.

Gå till inlägget

I en IDE (Integrated Development Environment) så ingår det ju både kompilator och editor och länkare (och oftast debugger) som samverkar. Exakt vilken komponent som varnar är sak samma vilket är lite av poängen med att ha en IDE jämfört med helt fristående verktyg.

Om den kan upptäcka att minne inte frigörs så är det för att den kör programmet i någon form av debugmiljö där den precis innan programmet avslutas kan kontrollera om det finns något allokerat minne som inte frigjorts.

Om du ofta råkar ut för att överindexera arrayer så skriver du antagligen din kod på något olämpligt sätt. Det finns troligen bättre sätt att skriva din kod på så att du minskar risken för överindexering.

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

I en IDE (Integrated Development Environment) så ingår det ju både kompilator och editor och länkare (och oftast debugger) som samverkar. Exakt vilken komponent som varnar är sak samma vilket är lite av poängen med att ha en IDE jämfört med helt fristående verktyg.

Om den kan upptäcka att minne inte frigörs så är det för att den kör programmet i någon form av debugmiljö där den precis innan programmet avslutas kan kontrollera om det finns något allokerat minne som inte frigjorts.

Om du ofta råkar ut för att överindexera arrayer så skriver du antagligen din kod på något olämpligt sätt. Det finns troligen bättre sätt att skriva din kod på så att du minskar risken för överindexering.

Gå till inlägget

Jag håller på mycket med matrisalgebra och optimering inom C. Det är mycket jobb att få till så det bli bra, men när det är klart så är det en supersnabb algoritm. Jag brukar hålla på med kvadratisk programmering och Non Negative Least Square med mera så som QR-faktorisering med House Holder reflektioner och Singular Value Decomposition.

....i C. Det är därför överindexering är så vanligt förekommande för mig.

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

Jag håller på mycket med matrisalgebra och optimering inom C. Det är mycket jobb att få till så det bli bra, men när det är klart så är det en supersnabb algoritm. Jag brukar hålla på med kvadratisk programmering och Non Negative Least Square med mera så som QR-faktorisering med House Holder reflektioner och Singular Value Decomposition.

....i C. Det är därför överindexering är så vanligt förekommande för mig.

Gå till inlägget

Om du skriver sådan kod för att du tycker det är roligt eller för att lära dig så är det ju en sak, men annars så finns det ju väletablerade bibliotek med funktioner för sådana problem som antagligen är både snabbare och robustare än din kod, och som du kanske borde fundera på att använda.

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

Om du skriver sådan kod för att du tycker det är roligt eller för att lära dig så är det ju en sak, men annars så finns det ju väletablerade bibliotek med funktioner för sådana problem som antagligen är både snabbare och robustare än din kod, och som du kanske borde fundera på att använda.

Gå till inlägget

Problemet är att dessa väletablerade bibliotek har sina brister också.
Dom är väldigt användbara om man har rätt hårdvara. Men ska man bara göra minsta kvadrat anpassningar så är OpenBLAS ungefär som att hammra småspik med en slägga.

Dessutom så är dessa väletablerade bibliotek inte snabbare än en enkel for-sats.

Jag har testat Eigen C++ mot mitt egna bibliotek och i många fall så är Eigen C++ någon millisekund långsammare än mitt.

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

Dessutom så är dessa väletablerade bibliotek inte snabbare än en enkel for-sats.

Jag har testat Eigen C++ mot mitt egna bibliotek och i många fall så är Eigen C++ någon millisekund långsammare än mitt.

Gå till inlägget

Kan du ge ett exempel på ett sådant fall?

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

Problemet är att dessa väletablerade bibliotek har sina brister också.
Dom är väldigt användbara om man har rätt hårdvara. Men ska man bara göra minsta kvadrat anpassningar så är OpenBLAS ungefär som att hammra småspik med en slägga.

Dessutom så är dessa väletablerade bibliotek inte snabbare än en enkel for-sats.

Jag har testat Eigen C++ mot mitt egna bibliotek och i många fall så är Eigen C++ någon millisekund långsammare än mitt.

Gå till inlägget

Arbetar du med små matriser så är det ju möjligt att det extra arbetet dessa bibliotek utför inte lönar sig. Är det bara millisekunder vi pratar om så är det antagligen bara små matriser involverade.
Skulle du börja jobba med stora matriser så misstänker jag att du kommer att se andra resultat.

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

Jag tycker min IDE verkar göra mer än bara så.
Vad min IDE kan avgöra är om jag har glömt initialisera ett objekt, variabel eller liknande.
Även om jag glömmer frigöra minnet så larmar den. Men den säger inte vart felet är dock. Felet kommer när programmet har slutat köras.

Samt den kan inte avgöra om man överindexerar arrayer. Skulle min IDE kunna analysera detta så är jag riktigt nöjd med C++ för detta är något som jag stöter på ofta.

Jag brukar använda valgrind för att avgöra om jag överindexerar. Men valgrind finns bara för Linux.

Fick reda på idag att Rust har väldigt ergonomiska felmeddelanden.

Gå till inlägget

Eigen lär vara enklare om allt ska vara i C eller C++. "Vettiga" sättet att använda OpenBLAS är via NumPy eller Octave. Med NumPy blir det rätt enkelt

>>> import numpy as np
>>> np.show_config()
openblas64__info:
    libraries = ['openblas64_', 'openblas64_']
    library_dirs = ['/usr/local/lib']
    language = c
    define_macros = [('HAVE_CBLAS', None), ('BLAS_SYMBOL_SUFFIX', '64_'), ('HAVE_BLAS_ILP64', None)]
    runtime_library_dirs = ['/usr/local/lib']
blas_ilp64_opt_info:
    libraries = ['openblas64_', 'openblas64_']
    library_dirs = ['/usr/local/lib']
    language = c
    define_macros = [('HAVE_CBLAS', None), ('BLAS_SYMBOL_SUFFIX', '64_'), ('HAVE_BLAS_ILP64', None)]
    runtime_library_dirs = ['/usr/local/lib']
openblas64__lapack_info:
    libraries = ['openblas64_', 'openblas64_']
    library_dirs = ['/usr/local/lib']
    language = c
    define_macros = [('HAVE_CBLAS', None), ('BLAS_SYMBOL_SUFFIX', '64_'), ('HAVE_BLAS_ILP64', None), ('HAVE_LAPACKE', None)]
    runtime_library_dirs = ['/usr/local/lib']
lapack_ilp64_opt_info:
    libraries = ['openblas64_', 'openblas64_']
    library_dirs = ['/usr/local/lib']
    language = c
    define_macros = [('HAVE_CBLAS', None), ('BLAS_SYMBOL_SUFFIX', '64_'), ('HAVE_BLAS_ILP64', None), ('HAVE_LAPACKE', None)]
    runtime_library_dirs = ['/usr/local/lib']
Supported SIMD extensions in this NumPy install:
    baseline = NEON,NEON_FP16,NEON_VFPV4,ASIMD
    found = ASIMDHP,ASIMDDP
    not found = ASIMDFHM

För att anpassa y=k*x+m med minstakvadratmetoden, Ax=y, där de k är kurvans lutning och m är skärningspunkten med y-axeln gör man ju bara

>>> x_samples = [ 0.1, 1.1, 2.05, 2.99 ]
>>> y_samples = [ -0.1, 1.0, 1.99, 3.2 ]
>>> A = np.matrix([ x_samples, np.ones(len(x_samples)) ]).T
>>> y = y_samples
>>> [k, m] = np.linalg.lstsq(A, y, rcond=None)[0]
>>> k
1.1315630266626329
>>> m
-0.24273832159370667

Vilken inte känns allt för komplicerat

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 Erik_T:

Arbetar du med små matriser så är det ju möjligt att det extra arbetet dessa bibliotek utför inte lönar sig. Är det bara millisekunder vi pratar om så är det antagligen bara små matriser involverade.
Skulle du börja jobba med stora matriser så misstänker jag att du kommer att se andra resultat.

Gå till inlägget

Ja. Små matriser använder jag. Max typ 10x10.
Jag gör alla mina beräkningar i C för att det är snabbt och portabelt.

Skrivet av Yoshman:

Eigen lär vara enklare om allt ska vara i C eller C++. "Vettiga" sättet att använda OpenBLAS är via NumPy eller Octave. Med NumPy blir det rätt enkelt

>>> import numpy as np
>>> np.show_config()
openblas64__info:
    libraries = ['openblas64_', 'openblas64_']
    library_dirs = ['/usr/local/lib']
    language = c
    define_macros = [('HAVE_CBLAS', None), ('BLAS_SYMBOL_SUFFIX', '64_'), ('HAVE_BLAS_ILP64', None)]
    runtime_library_dirs = ['/usr/local/lib']
blas_ilp64_opt_info:
    libraries = ['openblas64_', 'openblas64_']
    library_dirs = ['/usr/local/lib']
    language = c
    define_macros = [('HAVE_CBLAS', None), ('BLAS_SYMBOL_SUFFIX', '64_'), ('HAVE_BLAS_ILP64', None)]
    runtime_library_dirs = ['/usr/local/lib']
openblas64__lapack_info:
    libraries = ['openblas64_', 'openblas64_']
    library_dirs = ['/usr/local/lib']
    language = c
    define_macros = [('HAVE_CBLAS', None), ('BLAS_SYMBOL_SUFFIX', '64_'), ('HAVE_BLAS_ILP64', None), ('HAVE_LAPACKE', None)]
    runtime_library_dirs = ['/usr/local/lib']
lapack_ilp64_opt_info:
    libraries = ['openblas64_', 'openblas64_']
    library_dirs = ['/usr/local/lib']
    language = c
    define_macros = [('HAVE_CBLAS', None), ('BLAS_SYMBOL_SUFFIX', '64_'), ('HAVE_BLAS_ILP64', None), ('HAVE_LAPACKE', None)]
    runtime_library_dirs = ['/usr/local/lib']
Supported SIMD extensions in this NumPy install:
    baseline = NEON,NEON_FP16,NEON_VFPV4,ASIMD
    found = ASIMDHP,ASIMDDP
    not found = ASIMDFHM

För att anpassa y=k*x+m med minstakvadratmetoden, Ax=y, där de k är kurvans lutning och m är skärningspunkten med y-axeln gör man ju bara

>>> x_samples = [ 0.1, 1.1, 2.05, 2.99 ]
>>> y_samples = [ -0.1, 1.0, 1.99, 3.2 ]
>>> A = np.matrix([ x_samples, np.ones(len(x_samples)) ]).T
>>> y = y_samples
>>> [k, m] = np.linalg.lstsq(A, y, rcond=None)[0]
>>> k
1.1315630266626329
>>> m
-0.24273832159370667

Vilken inte känns allt för komplicerat

Gå till inlägget

Ja, enklare. Men när jag implementera något så ska det vara fixerat och inte röras något mera.
Jag använder Matlab när jag kör testberäkningar.

>> x_samples = [ 0.1, 1.1, 2.05, 2.99 ];
>> y_samples = [ -0.1, 1.0, 1.99, 3.2 ];
>> A = [x_samples' ones(length(x_samples), 1)];
>> b = y_samples';
>> x = linsolve(A, b)
x =

   1.1316
  -0.2427

>>
Senast redigerat
Redigera
Citera flera Citera
Permalänk
Medlem
●

Nu när tråden är varm, då tänkte jag ställa en liten fråga som berör struktur.

Jag jobbar inte som mjukvarutuvecklare, men jag håller på programmera mycket på fritiden och även inom jobbet.
När jag programmerar så har jag en tendens att strukturera om mina filer hela tiden i mappar. Jag har liksom många mappar där bara enskilda filer ligger.

Detta tar dock en tid, men när jag hittar min struktur så blir projektet allt lättare att modifiera vid behov.
Känner ni igen er också att varje projekt tar sin tid att få sin struktur och när strukturen är klar, ja då är det 10X lättare att programmera?

Jag försöker undvika till varje pris att få spagettikod. Jag skriver aldrig sådant dock, så jag är mycket noga på att från vissa t.ex. .cpp filer så skall man ej kunna anropa vissa funktioner.

Jag kör inte OOP, om inte behovet finns tydligt.

Senast redigerat
Redigera
Citera flera Citera
1 2 3 4
Skriv svar