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

Permalänk
Medlem
Skrivet av Ingetledigtnamn:

Can you give examples of large project where most of the code is written in Python

Svar från chat gpt bör tas med en nypa salt, inget av de projekten som installeras är python applikationer

Websystem är vanligt i python men det är mer eller mindre CRUD eller varianter av CRUD applikationer. Det räknar i alla fall inte jag som system
Och CRUD tror jag kommer tas över helt av AI

Permalänk
Medlem
Skrivet av klk:

Svar från chat gpt bör tas med en nypa salt, inget av de projekten som installeras är python applikationer

Websystem är vanligt i python men det är mer eller mindre CRUD eller varianter av CRUD applikationer. Det räknar i alla fall inte jag som system
Och CRUD tror jag kommer tas över helt av AI

Strategiskt undvek du mitt svar?

Skrivet av orp:

OpenStack, HomeAssistant(700 000 rader), Celery, Django(480 000 rader)

Jag inkluderar radantalet för projekten som jag har utklonade.

Permalänk
Medlem

Två andra Python-projekt som jag använder ganska frekvent Ansible(240 000 rader), Meson(111 000 rader).

Så nej det är inte enbart mindre skript som skrivs i Python.

Permalänk
Medlem
Skrivet av Ingetledigtnamn:

Jo, det är klart att det finns folk som är mer lämpade att lösa vissa typer av problem. Somliga är bra på fotboll, andra kan vara bra på att programmera. Detta har dock ingenting att göra med frågan jag ställde.

10x developer är absolut något som existerar och det är personer som är mer eller mindre nödvändiga för att gå i mål med projekt där det inte finns färdiga standardmallar.
En feltolkning många gör däremot är att detta skulle vara några super personer, det är det inte. Ofta uppfattas en 10x developer som långsam. Och det är heller inte speciellt svårt.

En viktig egenskap hos 10x developer som de kan åka på kritik för (uppfattas som de är onödigt långsamma) är att vara duktiga på att hålla ordning och städa kod. Deras ordningssinne gör att jobbet för andra utvecklare går så mycket bättre.
Städning handlar också om ordning, att ta tag i tråkiga arbetsuppgifter som stör utan att någon annan specifikt säger till.

Språk som blir mer och mer deklarativa, använder bibliotek och annat. Där är det svårare och veta vad ordning och reda är och det går för fort att röra till det. Städare hinner inte med så jag tror 10x developers undviker sådana projekt

Permalänk
Medlem
Skrivet av orp:

Strategiskt undvek du mitt svar?

Nej för jag ville kontrollera och vad är det django gör som behöver 480 000 rader?

480 000 rader är inte jättemycket men jag tvivlar på att django behöver så mycket kod för vad det gör om det inte handlar om extrasaker

Permalänk
Medlem
Skrivet av klk:

10x developer är absolut något som existerar och det är personer som är mer eller mindre nödvändiga för att gå i mål med projekt där det inte finns färdiga standardmallar.
En feltolkning många gör däremot är att detta skulle vara några super personer, det är det inte. Ofta uppfattas en 10x developer som långsam. Och det är heller inte speciellt svårt.

En viktig egenskap hos 10x developer som de kan åka på kritik för (uppfattas som de är onödigt långsamma) är att vara duktiga på att hålla ordning och städa kod. Deras ordningssinne gör att jobbet för andra utvecklare går så mycket bättre.
Städning handlar också om ordning, att ta tag i tråkiga arbetsuppgifter som stör utan att någon annan specifikt säger till.

Svammel, konceptet 10x developer heter just så eftersom dom anses vara 10 gånger mer produktiva och då i jämförelse med andra duktiga utvecklare.

Skrivet av klk:

Språk som blir mer och mer deklarativa, använder bibliotek och annat. Där är det svårare och veta vad ordning och reda är och det går för fort att röra till det. Städare hinner inte med så jag tror 10x developers undviker sådana projekt

Du kommer ihåg att vi fastställt att Python klassas som imperativt, va

Skrivet av klk:

Nej för jag ville kontrollera och vad är det django gör som behöver 480 000 rader?

480 000 rader är inte jättemycket men jag tvivlar på att django behöver så mycket kod för vad det gör om det inte handlar om extrasaker

Varför kollar du upp det när du borde kolla din egna påstående? Du tror inte att jag kollar upp sakerna innan jag postar dom?

Det är ett webbramverk... granska det så får du väl se om du kan kapa några rader. Det har ju överlevt ett tag så jag antar att dom har kapabla maintainers.

Varför är kodbasstorlek viktigt, behövs det kompenseras för något eller? Om inte ett batteries-included webbramverk behöver 480 000 rader, varför behöver du fler kodrader än så?

Permalänk
Medlem
Skrivet av orp:

Du kommer ihåg att vi fastställt att Python klassas som imperativt, va

"vi" ?

Du (och troligen de andra som gillar dina inlägg) och jag har inte alls samma syn på programmering.

Permalänk
Medlem
Skrivet av klk:

"vi" ?

Du och jag (och troligen de andra som gillar dina inlägg) har inte alls samma syn på programmering.

Du och resten av världen delar inte definitioner. Det är tur att definitionerna är konsensusbaserade och inte kontrollerade av dig

Det har inte mer programmering att göra utan språkkategorisering men vi är säkert inte överens om programmering och att C++ är en enhörning i heller.

Permalänk
Medlem
Skrivet av klk:

"vi" ?

Du (och troligen de andra som gillar dina inlägg) och jag har inte alls samma syn på programmering.

Nej, din syn är nog ganska unik. Liksom ditt användande av "imperativ" och "deklarativ".

Permalänk
Medlem
Skrivet av Erik_T:

Nej, din syn är nog ganska unik. Liksom ditt användande av "imperativ" och "deklarativ".

Spelar kanske mindre roll om synen, poängen är att få till bra lösningar

Permalänk
Medlem
Skrivet av orp:

Du och resten av världen delar inte definitioner. Det är tur att definitionerna är konsensusbaserade och inte kontrollerade av dig

Det har inte mer programmering att göra utan språkkategorisering men vi är säkert inte överens om programmering och att C++ är en enhörning i heller.

Jag tycker det är dags för dig att posta lite kod du är stolt över

Permalänk
Medlem
Skrivet av klk:

Jag tycker det är dags för dig att posta lite kod du är stolt över

Jag tycker att det är dags för dig att posta sammanhängande resonemang.

Jag kan inte posta någon av min kod eftersom den är proprietär men min kod snurrar i tåg, övervakningskameror, smarta lås osv så du har troligen varit i kontakt med den på ett eller annat vis.

Jag vet fortfarande inte vart du vill komma. Varför ska jag visa dig kod för att du inte känner till begrepp som du använder?

Permalänk
Medlem
Skrivet av orp:

Jag kan inte posta någon av min kod eftersom den är proprietär men min kod snurrar tåg, övervakningskameror, smarta lås osv så du har troligen varit i kontakt med den på ett eller annat vis.

Jag vet fortfarande inte vart du vill komma. Varför ska jag visa dig kod för att du inte känner till begrepp som du använder?

Skriver du ingen kod på fritiden?
Jag är nyfiken eftersom du vet så mycket, intressant och granska och personligen gillar jag att läsa kod. Har till och med pysslat en hel del med att recensera olika kända bibliotek vilket faktiskt var mycket uppskattat med tog lite för mycket tid för mig för att fortsätta.

Permalänk
Medlem
Skrivet av klk:

Skriver du ingen kod på fritiden?

Självklart men den är inte öppen för det.

Skrivet av klk:

Jag är nyfiken eftersom du vet så mycket, ...

Jag kollar iaf upp saker innan jag postar dom och jag rättar mig om någon hävdar att jag har fel och kan bevisa det.

Skrivet av klk:

... intressant och granska och personligen gillar jag att läsa kod. Har till och med pysslat en hel del med att recensera olika kända bibliotek vilket faktiskt var mycket uppskattat med tog lite för mycket tid för mig för att fortsätta.

Du ifrågasatte varför Django behövde 480 000 rader, kanske bra att börja läsa där?

Permalänk
Medlem
Skrivet av klk:

Spelar kanske mindre roll om synen, poängen är att få till bra lösningar

Det beror väl på vad du faktiskt har producerat/levererat, du kan väl berätta.

Skrivet av klk:

Jag tycker det är dags för dig att posta lite kod du är stolt över

What are you, 5? Att visa upp "kod" på samma sätt som en 5åring som visar en teckning hen har gjort för sina föräldrar känns oerhört infantilt, och det troliga är att den song gör det i realiteten inte har producerat någonting relevant.

Det är ju där hela språk-diskussionen blir barnslig.
Har du en produkt/tjänst med...säg...10.000 nöjda användare som har valt att använda och betala för den produkten/tjänsten, så är jag imponerad.
Har du sen skrivit den i ett språk som egentligen är helt fel för ändamålet, och dessutom med dålig kod, då är jag egentligen ännu mer imponerad.

Skrivet av klk:

Gå till någon av alla AI sökmotorer istället och fråga,...

Skrivet av klk:

Svar från chat gpt bör tas med en nypa salt...

Permalänk
Medlem
Skrivet av Xeonist:

Det beror väl på vad du faktiskt har producerat/levererat, du kan väl berätta.

Det kommer tolkas som för mycket skryt

Skrivet av Xeonist:

What are you, 5? Att visa upp "kod" på samma sätt som en 5åring som visar en teckning hen har gjort för sina föräldrar känns oerhört infantilt, och det troliga är att den song gör det i realiteten inte har producerat någonting relevant.

Que? Hur vanligt är det inte med att visa kod vid anställningar
Får jag se ett repo där någon då och då jobbar och det går att se väldigt bra om personen passar för uppgifterna eller inte

Skrivet av Xeonist:

Har du en produkt/tjänst med...säg...10.000 nöjda användare som har valt att använda och betala för den produkten/tjänsten, så är jag imponerad.

Det där är något helt annat, då skall du prata med företagare/säljare istället

Permalänk
Medlem

När ska ni inse att han bara trollar er? Han har åtminstone 2 gånger nu citerat sina egna inlägg, men tillskrivit dom någon av er andra, och sen argumenterat emot sig själv.

Skrivet av klk:

Det kommer tolkas som för mycket skryt

Som att du skulle stå över det menar du, halva den här tråden är ju inlägg från dig där det är typ det enda du gör.

Sanningen är såklart att du inte ha producerat ett skit.

Du är den där kompisens pappa som "när jag var ung så spelade jag faktiskt fotboll på elitnivå..." och sen när man kollar upp det så visar det sig att han var avbytare i ett division 5 lag.

Permalänk
Medlem
Skrivet av Xeonist:

När ska ni inse att han bara trollar er? Han har åtminstone 2 gånger nu citerat sina egna inlägg, men tillskrivit dom någon av er andra, och sen argumenterat emot sig själv.

Jag har sagt att han trollar vid multipla tillfällen.

Permalänk
Medlem
Skrivet av Xeonist:

När ska ni inse att han bara trollar er? Han har åtminstone 2 gånger nu citerat sina egna inlägg, men tillskrivit dom någon av er andra, och sen argumenterat emot sig själv.

Som att du skulle stå över det menar du, halva den här tråden är ju inlägg från dig där det är typ det enda du gör.

Sanningen är såklart att du inte ha producerat ett skit.

Du är den där kompisens pappa som "när jag var ung så spelade jag faktiskt fotboll på elitnivå..." och sen när man kollar upp det så visar det sig att han var avbytare i ett division 5 lag.

haha, ok

Funderar på om jag skulle kunna skriva ihop något som du vill för att bevisa att jag kan programmera

Tror du verkligen någon skulle ge sig in i en sådan här diskussion utan att ha på fötterna. När jag var "ny" utvecklare var mitt självförtroende inte i närheten av de som det är idag. Det är ett fantastiskt tufft yrke eftersom kunskap är så utslagsgivande och felbeslut kan få helt ödesdigra konsekvenser.

Minns än idag hur löjligt nervös man var första dagen på jobbet som ny programmerare, på vippen att jag drog hem vid lunch för att jag inte skulle klara av att palla. Som tur var så den uppgiften jag fick var i princip det enda jag kunde och efter det kunde jag förbereda bättre.
Mitt första jobb var som C++ programmerare i windows 3.11 och visual studio 2.0. På den tiden fanns inte internet, du var mer eller mindre tvungen att läsa böcker. För mig var Programming Windows skriven av Charles Petzold en bibel. Strax efter jag började köpte vi MSDN och det hjälpte mycket.

Ovanstående är en av orsakerna till att programmerare från den tiden blev mycket duktiga på att koda. Du fick testa enorma mängder kod eftersom man inte visste hur man skulle göra. Tänk dig själv att försöka göra något utan internet, inget stack overflow och så vidare. Man skriver och skriver, kompilerar om och testar. Hela tiden.

Editorn var ett skämt om du jämför med dagen, autocomplete kom långt senare

Permalänk
Medlem
Skrivet av klk:

Mitt första jobb var som C++ programmerare i windows 3.11 och visual studio 2.0.

Det var det garanterat inte. Det har aldrig funnits någon "visual studio 2.0".
Möjligen var det Visual C++ 2.0 du använde, men då den var för 32-bitars kod så vore det lite märkligt att kombinera den med Windows 3.11 som fortfarande mest var 16-bitars.

Permalänk
Medlem
Skrivet av Erik_T:

Det var det garanterat inte. Det har aldrig funnits någon "visual studio 2.0".
Möjligen var det Visual C++ 2.0 du använde, men då den var för 32-bitars kod så vore det lite märkligt att kombinera den med Windows 3.11 som fortfarande mest var 16-bitars.

Korrekt men hur många vet det idag? Och det var 1.5 vi körde när jag tänker efter. Jag fick jobbet för att jag själv köpt 1.0 till mig egen PC och försökte lära mig. Kommer inte ihåg alla versioner

Permalänk
Datavetare
Skrivet av klk:

Det kommer tolkas som för mycket skryt

Du kan ju optimera "hello-world" boost HTTP-servern jag postade ovan. Fixa också så den tar sig ur "knatteligan" när man kör på Windows, för detta är lite anledningen varför jag satt den etiketten på att köra något lite mer krävande nätverkstungt program på Windows (Windows är långt bättre med t.ex. databaser, möjligen för de rätt mycket är sina egna OS...)

CPU

OS

Language

Transactions/s

5950X

Windows 11

C++/Boost

9.7k

5950X

Windows 11

Go/standard library

118k

5950X

Ubuntu 24.04/WSL2

C++/Boost

21.5k

5950X

Ubuntu 24.04/WSL2

Go/standard library

149k

Orange Pi 5

Ubuntu 24.04/Native

C++/Boost

31.8k

Orange Pi 5

Ubuntu 24.04/Native

Go/standard library

125k

Go versionen på en Orange Pi 5 (en CPU som drar <10W) är väsentligt snabbare än Boost versionen på någon plattform.

Du borde absolut kunna förbättra boost-versionen givet att det rätt mycket var den första nätverksapplikation jag någonsin skrivit med boost (har dock använt andra delar av boost många gånger). Och på Windows presterar just C++/boost horribelt dåligt av någon anledning. Byggde med senaste boost versionen (1.87) i vcpkg i VS 2022 och med GCC 13.3 på Linux.

Använde wrk2 som klient med det antal trådar som gav högst resultat för varje enskilt fall. Testa på MacOS innan, det är normalt bättre än Windows sett till nätverksprestanda, men det når inte upp till Linux körandes på motsvarande HW.

Visa signatur

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

Permalänk
Medlem
Skrivet av Yoshman:

Du kan ju optimera "hello-world" boost HTTP-servern jag postade ovan.

Angående boost och om man använt deras exempel. Nu är jag ute på djupt vatten för det var ett tag sedan jag testade exempel där men jag tror de använder std::shared_ptr för att hålla data, om det var root mappen i något exempel. Den här kopierades till varje tråd.

Om man vill massbomba en http server så byt den mot någon variabel (kanske en global) eftersom den inte ändrar sig, bara läses. std::shared_ptr använder en referensräknare som behöver synkroniseras och kopieras denna till olika trådar blir det en liten flaskhals.

Skall titta vidare på det när jag hinner

Permalänk
Datavetare
Skrivet av klk:

Angående boost och om man använt deras exempel. Nu är jag ute på djupt vatten för det var ett tag sedan jag testade exempel där men jag tror de använder std::shared_ptr för att hålla data, om det var root mappen i något exempel. Den här kopierades till varje tråd.

Om man vill massbomba en http server så byt den mot någon variabel (kanske en global) eftersom den inte ändrar sig, bara läses. std::shared_ptr använder en referensräknare som behöver synkroniseras och kopieras denna till olika trådar blir det en liten flaskhals.

Skall titta vidare på det när jag hinner

Borde ju vara en smal sak att slå Go som drar på ett GC-ankare, är designat av folk som har noll koll på prefetching och minne rent generellt!

Visa signatur

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

Permalänk
Medlem
Skrivet av Yoshman:

Borde ju vara en smal sak att slå Go som drar på ett GC-ankare, är designat av folk som har noll koll på prefetching och minne rent generellt!

Skall se om jag kan debugga lite och se vad som händer. Låt säga att de parsar data i boost men inte gör det i Go så då är det skillnad på funktionalitet

De skilnaderna som visades i testet tyder på det

Permalänk
Medlem

Fantastiskt hur kod kan väcka så mycket känslor och leda till en sådan k*kmätar tävling!

Tur för er att 99,99% av oss bara bryr sig om front-end och skiter fullständigt i vad som händer bakom kulisserna så länge det tutar och går!

Var nu sakliga och vänliga!

Permalänk
Datavetare
Skrivet av klk:

Skall se om jag kan debugga lite och se vad som händer. Låt säga att de parsar data i boost men inte gör det i Go så då är det skillnad på funktionalitet

De skilnaderna som visades i testet tyder på det

Go parsar absolut protokollen, rätt mycket som inte skulle fungera annars och skulle framförallt inte fungera att bygga vettiga webb-applikationer (en av styrkorna i Go).

Att det inte är något sådan som är flaskhalsen är rätt uppenbart från relativ prestanda mellan plattformar. Om t.ex. parsing vore en signifikant flaskhals i C++/boost skulle det visa sig i rätt liten skillnad i prestanda mellan olika OS-plattformar då flaskhalsen då ligger i kod som är samma oavsett plattform (och även om MSVC++ producerar mindre effektiv kod än GCC och Clang är den inte mycket sämre).

Likaså pekar dessa siffror på att vi egentligen inte ser fulla potentialen hos Go-servern. Givet hur lika alla plattformarna presterar med Go-lösning pekar det på att flaskhalsen där är att wrk2-klienten helt enkelt inte orkar pusha hårdare.

Här ligger tvärtom förklaringen just low-level optimeringar (har markerat de som du hävdar är typiskt C++ exklusiva), inklusive mer effektiv användning av minne hos Go. Den här typen av applikationer är "killer-app:en" för Go.

Här är en rätt bra sammanfattning på den, rätt omfattande, listan med saker som Go gör mer effektiv i detta fall

Klicka för mer information

Why Go is so much faster than C++/Boost as an HTTP server

Go is often much faster than C++/Boost when used as an HTTP server, despite C++ generally being faster in raw computation. This performance difference is due to several key architectural differences:

---

📌 1. Go's Network Stack is Optimized for Concurrency
- Go does not use traditional threads for handling HTTP connections.
- Instead, it uses goroutines, which are lightweight, stack-allocated coroutines that allow handling millions of connections with very low overhead.
- The Go runtime efficiently schedules goroutines across multiple CPU cores.

🔹 C++/Boost: Uses OS threads or a thread pool, which has higher context-switching overhead.

🔹 Go: Uses goroutines + a scheduler, avoiding expensive thread creation and context switches.

Go can handle thousands of connections per thread, whereas Boost might create OS threads per connection.

---

📌 2. Go Uses pollset-Based Networking (Efficient Event Handling)
- Go’s networking runtime is based on pollset with epoll (Linux), kqueue (macOS), and I/O Completion Ports (IOCP) on Windows.
- The Go runtime automatically handles async I/O without blocking threads.
- This avoids costly thread contention and reduces syscalls.

🔹 C++/Boost: Boost.Asio is fast but still relies on explicit async programming with `std::future`, callbacks, or coroutines.

Go's event loop automatically schedules work, while Boost.Asio requires explicit async handling.

---

📌 3. Go's Built-In HTTP Server is Highly Optimized
Go’s `net/http` package:
- Uses zero-copy techniques to reduce memory allocations.
- Has pipelining, connection reuse, and gzip compression built-in.
- Uses efficient request parsing (without external dependencies).
- Avoids heap allocations whenever possible using `sync.Pool`.

🔹 C++/Boost: Writing an HTTP server with Boost.Beast requires manual memory management, explicit connection pooling, and manual async handling.

Go’s HTTP server is optimized out-of-the-box, while Boost requires manual fine-tuning.

---

📌 4. Go Avoids Memory Fragmentation and Manual Memory Management
- Go’s garbage collector (GC) prevents memory leaks and fragmentation.
- It automatically reclaims memory, reducing the need for manual buffer pooling.
- Go aggressively reduces heap allocations by reusing sync.Pool objects.

🔹 C++/Boost: Requires manual memory allocation, object reuse, and pooling to avoid heap fragmentation.

Go automatically manages memory efficiently, while Boost requires explicit allocation strategies.

---

📌 5. Go Scales Better for High-Connection Workloads
- Go's scheduler ensures fair CPU usage, even under heavy loads.
- Blocking in one goroutine does not block the entire thread.
- Go’s networking stack is optimized for long-lived, concurrent connections.

🔹 C++/Boost: Needs manual thread pool tuning to optimize for many concurrent clients.

Go scales better for high-throughput, high-connection workloads.

---

📌 6. Go's Compiled Code is More Portable
- Go compiles to a single binary with no external dependencies.
- Go’s standard library includes HTTP, TLS, and networking.
- Go's cross-platform support is seamless (Windows/Linux/macOS).

🔹 C++/Boost: Requires external dependencies (Boost.Beast, OpenSSL, etc.) and different build configurations per platform.

Go is easier to deploy and maintain.

Visa mer
Visa signatur

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

Permalänk
Datavetare

I ett större sammanhang, och i någon mening "on topic" för tråden så är det självklart så att C++ är en av de absolut viktigaste programmeringsspråken vi har just nu. C har en särställning då i princip alla viktiga OS-kärnor är använder språket och då det definierar "den gemensamma nämnare som gör det möjligt att binda ihop alla andra språk med varandra".

Men vi hanterar långt mer komplicerade system idag än vad vi gjorde under C++ storhetstid på 90-talet och tiden strax efter millenieskiftet. Hela diskussionen kring "minnessäkerhet" kommer från att både C och C++ har visat sig resultera i kod som oftare än de andra populära språken ger minnesproblem/säkerhetsproblem. Det samtidigt som nästan allt vi skriver idag är tillgängligt via Internet.

Microsoft skapade C# dels som en svar på att SUN stämde dem kring J++. Men enligt Microsoft själva ser de C# mer som en modern variant av C++ än deras svar på Java. De fördelar man lyfter är bättre minnessäkerhet, lättare att jobba med fast samtidigt, effektivt (man hävdar inte C++ nivå, men det går att skriva väldigt effektiv C# kod).

Google skapade Go "medan man väntade på att C++-koden skulle kompilera klart". Go är inte tänkt som ett "språk som är bäst eller ens bra på allt", utan det är designat specifikt för I/O-tunga uppgifter där man accepterat lite mindre "compute-efficiency" för att hålla det lätt/tillgängligt för de uppgifter man primärt optimerat för. Det är också designat för att kunna användas i gigantiska projekt, där kompileringstiden i Go (och antagligen också Rust) blir en rejäl flaskhals. Go kod kompileras otroligt mycket snabbare än C++/Rust.

Rust skapades bl.a. därför att Mozilla såg hur hopplöst mycket buggar multitrådad C++-kod tenderar dra på sig redan i hyfsat modesta kodbaser. Att data-race buggar faktiskt inte kompilerar i Rust är vad jag vet forfarande helt unikt. Det man gjorde för att uppnå detta har medfört en hel del andra trevliga egenskaper, bl.a. väldigt hög minnessäkerhet (men är fortfarande möjligt att t.ex. läcka minne i Rust även utan unsafe).

På 90-talet fanns det egentligen inte så mycket konkurrenter till C och C++ om man ville ha riktigt bra prestanda. Idag är inte längre dessa två nödvändigtvis att likställa med "bästa tänkbara prestanda". För många specifika fall finns det ofta alternativ som är minst lika effektiva, t.ex. Go för I/O-tunga laster, Rust för de mesta compute (och är långt enklare att få effektiv + korrekt kod i Rust än C++ vid multitrådning), JVM-språk är idag (tog nog längre än man gissade när Java släpptes i mitten av 90-talet) extremt effektiva när de passerat initiala warm-up perioden.

Visa signatur

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

Permalänk
Medlem
Skrivet av Yoshman:

Här är en rätt bra sammanfattning på den, rätt omfattande, listan med saker som Go gör mer effektiv i detta fall

Som din lista visar på så jämför du ju lite äpplen och päron i ditt benchmark när boost tvingas till "traditionell" trådning och Go arbetar med sina lightweight goroutines.

En mer rättvis jämförelse vore att använda async coroutines även i Boost, som det här exemplet (som jag saxade och anpassade från github.com/evilenzo/coroutine-server då jag själv har minimal Boost-erfarenhet):

Klicka för mer information

#include <iostream> #include <thread> #include <boost/asio/as_tuple.hpp> #include <boost/asio/co_spawn.hpp> #include <boost/asio/detached.hpp> #include <boost/asio/use_awaitable.hpp> #include <boost/beast/core.hpp> #include <boost/beast/http.hpp> namespace asio = boost::asio; namespace beast = boost::beast; namespace http = beast::http; namespace ip = asio::ip; using tcp = ip::tcp; asio::awaitable<void> handle_request(beast::tcp_stream &stream, http::request<http::string_body> request) { http::response<http::string_body> response(http::status::ok, request.version()); response.set(http::field::content_type, "text/html"); response.body() = "<h1>Hello, World!</h1>"; response.prepare_payload(); co_await http::async_write(stream, response, asio::use_awaitable); } asio::awaitable<void> poll_socket(tcp::socket socket) { http::request<http::string_body> request; beast::tcp_stream stream{std::move(socket)}; beast::flat_buffer buffer; for (;;) { auto [ec, size] = co_await http::async_read( stream, buffer, request, asio::as_tuple(asio::use_awaitable)); if (ec) { if (ec == http::error::end_of_stream) { break; } std::cerr << ec.message() << std::endl; break; } bool close{request.need_eof()}; co_await handle_request(stream, std::move(request)); if (close) { break; } request = {}; } stream.socket().shutdown(tcp::socket::shutdown_send); } asio::awaitable<void> poll_connections(asio::ip::address address, uint16_t port) { auto executor = co_await asio::this_coro::executor; tcp::endpoint endpoint{address, port}; tcp::acceptor acceptor{executor}; acceptor.open(endpoint.protocol()); acceptor.bind(endpoint); acceptor.listen(); tcp::socket socket{executor}; for (;;) { co_await acceptor.async_accept(socket, asio::use_awaitable); asio::co_spawn(executor, poll_socket(std::move(socket)), asio::detached); socket = tcp::socket{executor}; } } int main(int argc, char *argv[]) { const int threads = std::thread::hardware_concurrency(); asio::io_context ioc{threads}; asio::co_spawn(ioc.get_executor(), poll_connections(ip::make_address("0.0.0.0"), 8082), asio::detached); std::vector<std::thread> v(threads - 1); for (int i = 1; i < threads; i++) { v.emplace_back([&ioc] { ioc.run(); }); } ioc.run(); }

Visa mer

Jag får då följande resultat på min Macbook Air:

Ditt Go-exempel

160.82k/s

Ditt Boost-exempel

2.96k/s

async Boost

213.41k/s

Med det sagt skulle även jag välja Go före C++ för webbservrar/applikationer, men det kliade lite för mycket i fingrarna när jag läste att C++ skulle prestera så långsamt. 😅

Permalänk
Medlem
Skrivet av Yoshman:

Här ligger tvärtom förklaringen just low-level optimeringar (har markerat de som du hävdar är typiskt C++ exklusiva), inklusive mer effektiv användning av minne hos Go. Den här typen av applikationer är "killer-app:en" för Go.

Lite generellt om att testa prestanda.
Får man mer än dubbla hastigheten på något enklare test och språken kompilerar (kan generera maskinkod) så är det läge att misstänka dåligt test (de testar olika saker).
Så mycket skiljer det inte på enklare saker och när det är lite data som används eller det på annat sätt inte är speciellt krävande för en processor och man BARA testar en sak, detta sköter processorer så bra att det knappt går att märka skillnader.

Prestandakrävande lösningar har helt andra prioriteringar.

För att då spinna vidare på webserver exemplet.
De flesta som gör websystem gör dessa "stateless", med den tekniken måste också varje anrop vara komplett. Skall man ha ett api där ett mejl skickas så måste det innefatta alla delar som behövs och eftersom servern inte har en aning om vem användaren är, rättigheter mm behöver också skötas.

Om servern däremot vet om sina användare, kan lagra data för dem. Den typ av server kan ha helt andra typer av API, varje API behöver inte vara isolerat.
Exempelvis blir det mycket enklare att skriva kommandon som kan pipas
"validate user" | "connect-db" | "select result" | "mail result"
Servern behöver inte alls ha lika många APIer, varje API blir enklare men ändå ökas flexibiliteten, det behövs inte lika många anrop

Självklart försöker man få till något smart oavsett vilka lösningar som väljs men det blir mycket extra för att en webserver är stateless. Min poäng här är olika lösningar har konsekvenser.

Så varför gör man då inte en webserver som vet om sina användare?

Lösningen där servern behöver veta om användarna är svår och servern får inte krascha. Kraschar servern måste alla användare logga in igen.

Svårigheterna i att ha koll på användare.
Servern behöver någon form av lista/listor där information om varje inloggad användare finns. Eftersom en webserver som kan hålla state alltid är trådad behöver också den här listan trådsäkras. Vad händer med listan när en användare behöver läggas in (måste hela listan låsas för andra trådar då).
Så länge det är få användare och/eller få anrop, inga större problem.
Plötsligt stiger antalet samtida användare, och antalet anrop ökar. En enkel trådsäkrad lista som fungerade utmärkt i liten skala kan snart bli ett allvarligt problem - det tar för mycket tid att leta i den. Speciellt som den låses oftare samt växer då det är fler användare och den då också behöver städas mer.

Att fixa det här problemet som var så lätt i liten skala blir plötsligt extremt svårt och detta är en av orsakerna till varför det inte görs. Klarar man det (låt säga att teamet har någon 10x developer) så kan den göra en lösning som skalar tillräckligt bra och resten av teamet skördar frukterna av att ha en mycket enklare server att jobba mot.

Självklart finns det andra problem med att bygga en server som håller state men klarar de att sköta användare tror jag resten är ett mindre problem.

Parallella lösningar har inte mindre behov av prestanda utan tvärtom mer och det handlar nästan alltid om att synkroniseringslösningar måste vara extremt optimerade för att klara av att skala till alla kärnor som processorer har och de hela tiden får fler av.