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

Frågan var ju efter en bättre presterande C++ version, inte Go version. Misstänkte att den C++/boost jag fick ihop inte på något sätt var optimal, men den gjorde i alla fall rätt sak.

Om du vill testa att göra en "stateful HTTP-server" vore det faktiskt kul att se hur man gör det inom ramen för stackless coroutines. Misstänker att det blir klart med komplicerat jämfört med en stateful Go version (en sådan är rätt simpel).

Man kan simulera ett gäng användare och någon "request data" t.ex. så här med WRK (peka ut skript med -s users.lua)

-- users.lua
math.randomseed(os.time())  -- Seed random generator

request = function()
    local user_id = math.random(1, 10000)
    local arg_val = math.random(1, 20)
    local url = "http://localhost/api?user=" .. user_id .. "&arg=" .. arg_val
    return wrk.format("GET", url)
end

Man får då GET-anrop på formen

http://localhost/api?user=17&arg=42
http://localhost/api?user=66&arg=2
etc.
En superenkel stateful server skulle bara kunna summera arg-värdet per användare och skicka tillbaka det som svar: "user=17\nsum=3466".

Lösning med global tabell + lås fungerar, men lär inte skala speciellt bra. Kanske finns något riktigt spännande trick ihop med C++20 coroutines?

Historiskt var boost rätt mycket en inkubator för "bra att ha saker" där de mest generellt användbara togs in i standardbiblioteket. Vet inte om det stämmer längre.

Men just coroutines är inte en boost-finess, boost verkar ha "stackful coroutines" och C++ ISO kommittén tittade både på "stackful" och "stackless" coroutines, valet föll på "stackless".

"Stackless" varianten har fler begränsningar, men man verkar ha ansett att de fungerar ändå bra ihop med de flesta I/O-intensiva uppgifter och man såg störst värde där.

"Stackful" coroutines är mer generella, då går i praktiken att använda "till allt". Men ett stort problem för C++ (och de flesta språk) är att det inte finns något enkelt sätt att växa stacken efter man startat en tråd/task -> man behöver ta höjd för "worst-case" vilket skulle gjort coroutines väl dyrt. Go "löser" detta genom att alltid starta med väldigt liten call-stack (typ 4k) som kan växa vid behov (något som kräver runtime-stöd och att man tänkt på det från start).

Angående std::stringview etc. Är helt med på hur cache och dess konsistensprotokoll fungerar, men hur relevant är det att mikro-optimera något sådan på moderna CPUer som dels kan ha >500 instruktioner "in-flight", ha >50 samtida minnesoperationer "in-fligh" samt kan göra rätt många load/store per cykel?

OK om man gör korkade saker, men lär knappast spela någon relevant roll om man använder 12 eller 16 bytes...

Vidare är det egentligen inget problem att packa in fler 12 bytes objekt i en cache-line. Sedan Sandy Bridge (2011) kostar det inget extra att läsa/skriva ens på udda alignment om man nu absolut måste optimera på den nivå (lär inte finnas någon modern high-end CPU som inte har dessa optimeringar idag).

Angående stateful server: i just detta läge skulle det nog ändå fungera helt OK med en vanlig std::unordered_map<userId, userData> och en mutex över den tabellen (ger inte speciellt bra skalning över kärnor, om nu inte servern gör något som är beräkningsmässigt dyrt för då lär det inte spela någon roll).

Det skrivet just sådant är väldigt enkelt i Go då http-servern enkelt kan ges "state", t.ex. så här

package main

import (
	"fmt"
	"net/http"
	"strconv"
	"sync"
)

type StatefulServer struct {
	users sync.Map // safe to use from multiple go-routines without additional locking
}

type User struct {
	mtx sync.Mutex // per-user lock, sum could be an atomic instead in this trivial case
	sum int32
	// other user data
}

func (serverState *StatefulServer) handler(w http.ResponseWriter, r *http.Request) {
	userStr := r.URL.Query().Get("user")
	argStr := r.URL.Query().Get("arg")
	userId, userIdOk := strconv.Atoi(userStr)
	arg, argOk := strconv.ParseInt(argStr, 10, 32)
	if userIdOk != nil || argOk != nil {
		http.Error(w, "Missing or invalid formatted parameters", http.StatusBadRequest)
		return
	}
	userEntry, _ := serverState.users.LoadOrStore(userId, &User{sum: 0})
	user := userEntry.(*User)
	user.mtx.Lock()
	defer user.mtx.Unlock()
	user.sum += int32(arg)
	fmt.Fprintf(w, "Sum is %d for user %d", user.sum, userId)
}

func main() {
	port := 8080
	serverState := StatefulServer{sync.Map{}}
	fmt.Printf("Server running on port %d...\n", port)
	http.HandleFunc("/", serverState.handler)
	err := http.ListenAndServe(fmt.Sprintf(":%d", port), nil)
	if err != nil {
		fmt.Println("Server error:", err)
	}
}

Edit: även med denna "stateful" HTTP fixar Orange Pi 5:an 88k transaktioner per sekund (mot 95k innan).

Hur är detta relaterat till att C och C++ inte har några alternativ pga att någon spelutvecklare tycker om att använda för-allokerade minnesregioner för minneshantering?

Vad är det för alternativ C och C++ saknar?

Missade nog detta svar...

Fast nu är det enda relevanta problemet löst: med CSP (vilket Go har "native" och som är trivialt att implementera med C++20 co-routines) så har man en multitrådad load-balancer som lurar ut vilken användare det är.

Efter den har man en go-routine / co-routine som hanterar exakt en användare med isolerad data -> inga multi-thread problem, samtidigt som man effektivt kan använda många kärnor så länge som antalet aktiva användare är "tillräckligt" stort.

I Go är användning av flera kärnor automatiskt då det sköts av runtime. I C++20 får man bygga en "executor" som schemalägger co-routiner på önskat sätt.

Herregösses: "jag är en spelutvecklare som upptäckt arena-allokatorer, nu är min åsikt att alla som inte fattar hur bra arena-allokator är n00bs".

Och ja, vet vem personen är. En rätt vanlig kritik jag sett mot honom är just att han må vara väldigt duktig inom sitt specifika område, men han verkar ha väldigt dålig koll på vad som är de relevanta flaskhalsarna i andra krävande områden. Men ändå lyfter han fram sina egna erfarenheter som att de är helt allmängiltiga (skulle vara spännande att se hans "superoptimeringar" applicerade i en starkt multitrådad miljö där livslängden inte är 100 % deterministisk...)

Han har också rätt ordentligt missförstått RAII. Det är just RAII, inte MAII. Minne är bara en resurs av många som väldigt smidigt och effektivt kan hanteras via RAII. För att ta Go som exempel igen, där finns inga destruktorer (finns överhuvudtaget inget explicit OOP stöd, vilket i.m.n.h.o är en av fördelarna med språket) men man har ett specifikt nyckelord just för att kunna implementera RAII (ett som TrapC verkar "stjäla" för att få in RAII stöd även där).

Arena-allokator är otroligt bra i renderings-steget i spel då så mycket upphör att leva efter man skickat allt till GPU varje frame. Arena-allokator är långt ifrån allmängiltigt bra, det är ett verktyg av många och även om det finns flera bra use-case utanför just 3D-rendering i spel är det totalt sett en nischfunktion.

Det är inte heller något som är bundet till C och C++, det är precis lika relevant att använda tekniken i spel som använder C#.

Vidare är inte smarta pekare och arena-allokatorer motsatser. Tvärtom finns en rad fördelar med att använda smarta pekare (d.v.s. utnyttja RAII, går inte att använda std::shared_ptr<> eller std::unque_ptr<> här). Ett sådant är att man då kan växla mellan arena-allokator och vanlig heap-allokator utan att ändra något mer än implementationen av den smarta pekaren. Även när man kör arena-allokator varianten finns fördelar med RAII, t.ex. att i debug-buggen verifiera att destruktor körs innan hela arenan går out-of-scope (gör den inte det har man en rätt svårhittad uses-after-free bug som i stort sätt inga verktyg som bygger på statisk analys kommer hitta då minnet sett från OS/runtime faktiskt är allokerat hela tiden).

Slutligen: just det som gör arena-allokatorer så snabba, extremt simpel logik för att "allokera" X bytes minne, är exakt vad som gör att GC-språk i vissa lägen kan vara snabbare än C, C++ och Rust om/när man har logik som allokerar väldigt många små objekt. Heap-allokering med GC är rätt mycket en arena-allokator i sin allok-logik. Skillnaden är att de flesta GC-språk kan kompaktera sin heap vid behov vilket undviker extern fragmentering, något som kan bli ett rätt svårt problem i C, C++ och Rust (är specifikt inte ett problem när man kör arean-allokator då den alltid ger upp hela minnet varje gång).

Jag vet inte hur många gånger vi har varit över detta ... börjar bli aningen tjatigt ...
Du kan pilla på minnet i Rust, tror du själv att dom hade tillåtit drivare skrivna i Rust till Linux om du inte kunde kontrollera minnet?

Här är motsvarande memset:
https://doc.rust-lang.org/std/ptr/fn.write_bytes.html

Här är motsvarande memcpy:
https://doc.rust-lang.org/std/ptr/fn.copy_nonoverlapping.html

Kan du vänligen komma ihåg detta nu?

Skoj för dig. Jag använder Neovim till det mesta.

Nu när vi än en gång fastställt att du kan pilla på minne i Rust och Zig och troligen en hög med andra språk utöver C och C++ så undrar jag vilka alternativ som C- och C++-utvecklare saknar eller det var det hela?

Bara om man tror att en GC 2025 fungerar på exakt samma sätt som en GC gjorde 1995.

Vissa av sakerna du skriver är så arroganta och ofattbart korkade.

@Yoshman har lagt så jäkla mycket energi på att förklara resonemanget för dig och är uppenbart mer påläst och allt du gör är att stoppar fingrarna i öronen och säger något i stil med "na na na na jag kan inte höra dig.... GC är dåligt för C++ är min enhörning ...".

Du menar väl "utan GC måste man lösa det på andra sätt för att inte få bedrövlig prestanda i ett språk vars huvudpoäng är bra prestanda"? Och i nästan alla custom-memory-allocator trix går att göra även om man har GC.

I detta fall skulle man självklart göra en custom-memory-allocator lösning i C++ om det var ett "riktigt" problem. Men bara för att få en känsla för just hur mycket bättre en modern GC är med en naiv approach jämfört med en logiskt identisk C++ lösning kan vi kika på detta

Detta kommer från en microbenchmark för minneshantering, så är lite poängen att det ska vara mycket små allokeringar.

#include <iostream>
#include <memory>
#include <cmath>

struct Node
{
    Node *left;
    Node *right;

    Node(Node *l = nullptr, Node *r = nullptr) : left(l), right(r) {}

    ~Node()
    {
        delete left;
        delete right;
    }

    int itemCheck() const
    {
        if (!left)
            return 1;
        return 1 + left->itemCheck() + right->itemCheck();
    }
};

Node *bottomUpTree(int depth)
{
    if (depth <= 0)
        return new Node();
    return new Node(bottomUpTree(depth - 1), bottomUpTree(depth - 1));
}

const int minDepth = 4;

int main(int argc, char *argv[])
{
    int n = 0;
    if (argc > 1)
    {
        n = std::stoi(argv[1]);
    }

    int maxDepth = n;
    if (minDepth + 2 > n)
    {
        maxDepth = minDepth + 2;
    }
    int stretchDepth = maxDepth + 1;

    Node *stretchTree = bottomUpTree(stretchDepth);
    int check = stretchTree->itemCheck();
    std::cout << "stretch tree of depth " << stretchDepth << "\t check: " << check << "\n";
    delete stretchTree;

    Node *longLivedTree = bottomUpTree(maxDepth);

    for (int depth = minDepth; depth <= maxDepth; depth += 2)
    {
        int iterations = 1 << (maxDepth - depth + minDepth);
        check = 0;

        for (int i = 1; i <= iterations; i++)
        {
            Node *tempTree = bottomUpTree(depth);
            check += tempTree->itemCheck();
            delete tempTree;
        }
        std::cout << iterations << "\t trees of depth " << depth << "\t check: " << check << "\n";
    }

    std::cout << "long lived tree of depth " << maxDepth << "\t check: " << longLivedTree->itemCheck() << "\n";
    delete longLivedTree;

    return 0;
}

package main

import (
	"flag"
	"fmt"
	"strconv"
)

var n = 0

type Node struct {
	left, right *Node
}

func bottomUpTree(depth int) *Node {
	if depth <= 0 {
		return &Node{}
	}
	return &Node{bottomUpTree(depth - 1), bottomUpTree(depth - 1)}
}

func (n *Node) itemCheck() int {
	if n.left == nil {
		return 1
	}
	return 1 + n.left.itemCheck() + n.right.itemCheck()
}

const minDepth = 4

func main() {
	flag.Parse()
	if flag.NArg() > 0 {
		n, _ = strconv.Atoi(flag.Arg(0))
	}

	maxDepth := n
	if minDepth+2 > n {
		maxDepth = minDepth + 2
	}
	stretchDepth := maxDepth + 1

	stretchTree := bottomUpTree(stretchDepth)
	check := stretchTree.itemCheck()
	fmt.Printf("stretch tree of depth %d\t check: %d\n", stretchDepth, check)

	longLivedTree := bottomUpTree(maxDepth)

	for depth := minDepth; depth <= maxDepth; depth += 2 {
		iterations := 1 << uint(maxDepth-depth+minDepth)
		check = 0

		for i := 1; i <= iterations; i++ {
			tempTree := bottomUpTree(depth)
			check += tempTree.itemCheck()
		}
		fmt.Printf("%d\t trees of depth %d\t check: %d\n", iterations, depth, check)
	}
	fmt.Printf("long lived tree of depth %d\t check: %d\n", maxDepth, longLivedTree.itemCheck())
}

Go versionen är på min datorn (M3 Max) nästan 10 gånger snabbare!!! Bygger med clang 16.0 och -O2 för C++, och för Go är det 1.24.1.

Man lär se samma resultat om Go byts ut mot moderna varianter av C# eller Java.

C++ kan vara effektivt, framförallt när man bygger enkeltrådad programvara där man då bara har logik att tänka på i sina custom-memory allocators. Inte lika roligt att försöka bygga något icke-trivial, använda många CPU-kärnor och fortfarande ha det väldigt effektivt...

Overhead att använda GC minskar rejält så fort man går multicore. Vissa (multicore-aware)algoritmer går att göra både enklare och effektivare när man har GC.