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

Nej, sedan vi blev presenterade av filstorleken så är det ingen hit med minneslagring, men innan dess tänkte vi ju oss på sin höjd några MB.

Vad är det för applikation som inte har fallback om en körning blir liggandes mitt i, det måste väl ändå gå att starta om från senaste stabila punkt? Att indata helt plötsligt får formateringar som är ohanterliga är väl ändå något man måste räkna med! Särskilt om indata baserar sig på mänsklig inblandning, vilket det alltid gör, indirekt (buggar), även när indata är maskingenererat!

Denna kan säkert överraska dig. Han pratar om operationstider om 2-3 minuter..
How to analyse 100s of GBs of data on your laptop with Python: In this article I will show you a new approach: a faster, more secure, and just overall more convenient way to do data science using data of almost arbitrary size, as long as it can fit on the hard-drive of your laptop, desktop or server.
https://vaex.io/blog/how-to-analyse-100s-of-gbs-of-data-on-yo...

Vad är det som kan gå sönder om programmet stannar mitt i en körning? Du har väl senaste indatafilen lagrad på disk? Eller pratar vi om så långa körningar att en återstart för en enskild fil blir problematisk? (Långa körtider, som du inte nämnt? Fler än 20 pass igenom indatafilen som kröp fram nu..)

Om du gör 20+ pass genom indatafiler på 10+GB så motsvarar det ju den dåliga minneshanteringen du pratade om långt tidigare. Återkommande icke lokala referenser är ju döden för vilken datorverksamhet som helst. Du skrev tidigare att det görs en viss minimering av data i varje steg, är det dessa 20 pass?

Om den filen ligger på disk, och programmet kraschar medan det uppdaterar filen så är den också förstörd. Jobba med den i minnet gör inte det hela särskilt mycket opålitligare.
Det finns ju sätt att hantera sådant, men då börjar vi prata riktig databasmotor som måste göra en massa jobb för att databasen inte skall kunna förstöras bara för att ett program kraschade vid fel tillfälle.

Bara en fråga: givet att det handlar om få gigantiska filer, varför ens hålla på med ett eget ihoptragglat "tar-format"? Vore det inte bättre att använda en katalog och helt normala filoperationer?

Gör man något "custom" bör man rimligen ha något hyfsat udda användarfall, t.ex. extrema prestandakrav. Annars lär man bara skapa problem som egentligen inte finns. Här verkar det nu allt mer se ut att vara rätt normal fil I/O-hantering, av relativt stora filer.

Och hur du än vrider och vänder på det kvarstår att OS, av prestandaskäl, aggressivt cache:ar både disk-data och disk-meta-data i RAM. Att ta höjd får att programvara är så vinglig att man inte vågar använda RAM så är det nog stabiliteten i programvaran som borde vara prio#1.

Vad är egentligen vitsen med att packa filer i ett arkivformat när de är så stora? Du får väl upp tillräckligt med sekventiell prestanda med dem direkt på disken. Varför inte bara skapa en katalog och låta filsystemet (som kan tunas) ta hand om det? Då läser/skriver du bara filen du jobbar med, inte hela arkivet varje gång du skall uppdatera något? Jag hoppas ni inte har tusentals filer i en och samma katalog?

Det hela låter för mig som att det är någon uråldrig robust lösning där man inte kan röra på indata-formatet på minsta sätt för att göra saker smartare på moderna plattformar. Finansvärlden, nej stämmer inte med att behöva gå tillbaka i filen flera gånger. Telecom, nej sms och mejl är småfiler i köeerna, jag har sett båda dessa från sina sämsta sidor. (När det stått still!). Core-beräkningar från en reaktorhärd, tveksamt. En råfil för paketförmedling (post) skulle det kunna vara om man måste gå tillbaka historiskt och leta upp färdvägen för att sortera upp den per försändelse?

Om jag skulle gissa bland allt detta så känns Telekom::trafikdata som det närmaste jag kan tänka mig.
Någonstans runt 30 miljoner samtal/dag i Sverige? Men det förklarar ju inte varför man måste gå igenom filen 20+ gånger!

Spännande! Kan du ge lite mer bakgrund till vad ni använder kvantfysik till? Du kan vara teknisk om det behövs, gjorde mitt examensarbete på KTH kring filtrering av inhibitorer (det via kvantkemi) som idag är en vanligt metod vid framställning av vaccin.

Vad är det för fel på "ls, tar, xz, cp, ..." etc? Är ju bara montera EC2-instanserna (det även med Google Cloud) m.h.a. sshfs. Långsammare än lokalt filaccess, men det är ju inget som ditt hemmasnickrade system hjälper med heller. Nu går att använda standardverktyg.

Att starta, stoppa och hantera EC2-instanser går ju också att scripta med awscli.

Så är inte riktigt med på varför AWS skulle vara en flaskhals. Börja använd VS Code så blir det inte heller något problem att jobba/utveckla/debugga mot EC2 (eller vad som helst som är nåbart via SSH) på ett sätt som känns rätt mycket på samma sätt som att sitta lokalt. Det oavsett om jobbet är med nakna pekare i C++ eller "amatörprogrammering" i Python (det skrivet, här finns fördelar med Rust och Go för de har top-notch "language-servers" mot VC Code, C++ är "OK-ish" medan Python är "riktigt bra")

Lite on-topic igen. Snubblade över denna
https://cispa.de/en/research/publications/84651-await-a-secon...

"Code reuse attacks exploit legitimate code sequences in a binary to execute malicious actions without introducing new code. Control Flow Integrity (CFI) defenses mitigate these attacks by restricting program execution to valid code paths. However, new programming paradigms, like C++20 coroutines, expose gaps in current CFI protections. We demonstrate that, despite rigorous standardization, C++ coroutines present new vulnerabilities that undermine both coarsegrained and fine-grained CFI defenses. Coroutines, widely used in asynchronous programming, store critical execution data in writable heap memory, making them susceptible to exploitation. "

vilket är relaterat till det jag postade tidigare i tråden då man kan gå runt en del av säkerhetsförbättringarna som kan göras om C++20 coroutines används (de relaterade till "kontrollflödesintegritet")
#20826868

Och givet diskussionen i denna tråd. Vid en första anblick kan man tycka att den attack-typ som beskrivs i rapporten, Coroutine Frame-Oriented Programming (CFOP), borde gå att använda i t.ex. C# async/await mekanism som likt C++20 coroutines också är "stack-less" och håller tillstånd på heap:en (Go är by-design inte påverkat då goroutines använder en stack).

Men C# (och andra som implementerar async/await på liknande sätt) är inte påverkade då man inte har rätt typ av access för att utföra attackerna. I C++ blir tillgång på råa pekare och att man kan hantera heap:en "hur som helst" en säkerhetshål här.

Så tyvärr fortsatt uppförsbacke för C++ om målet är att "programmera minnessäkert".

sshfs är en standardfunktion i Linux (specifikt FUSE är det, sshfs är en variant som använder FUSE).

sshfs finns även till MacOS, i.e. man kan montera ett delträd via SSH på sin lokala MacOS-maskin. Finns varianter till Windows, har aldrig använt dem så kan inte säga något om det. Men finns ju också WSL2 som standardfunktion i Win10/11, då har man ju sshfs den vägen.

Att göra sig beroende av awscli är en vendor-lockin, men det är ju för att hantera AWS-resurser (och den komplexiteten är just komplexitet, t.ex. Hashicorp gör ju produkter för att hantera denna komplexitet, Terraform). Det du specifikt gör kräver i sig bara standardfunktioner i Linux (för utgår att ni kör Linux-instanser i "molnet").

Handlar det "bara" om att ladda upp/ned filer går det ju att göra enbart med ssh+tar/gzip/bz2/xz. Då kan man även göra saker som att komprimera data "on-the-wire" om man har mer beräkningskraft jämfört med nätverksbandbredd.

Grundaren(?) av cURL, Daniel Stenberg, skrev för några dagar sedan inlägg om att skriva säker C-kod för cURL med kort inslag om just minnessäkerhet, så nästan enligt trådämnet? Kanske han till och med smygläser denna tråd till och från?!

Mvh,
WKF.

En annan sak som hänt i dagarna är inte direkt relaterat till C++ och minnessäkerhet, men definitivt relaterat till flera saker som diskuterats i denna tråd runt vad som eventuellt gör C++ unikt.

Nvidia har precis lanserat stöd för att skriva CUDA-kernels i Python!
https://thenewstack.io/nvidia-finally-adds-native-python-supp...
https://developer.nvidia.com/cuda-python

En viktig orsak är att de ser stora begränsningar i hur pass populärt något kan bli idag om det bara finns till C och C++. Totala antalet programmerare växer fortfarande mycket snabbt, på senare tid är det Afrika, Sydamerika och Asien tillväxten är störst.

C och C++ är inte speciellt populärt i dessa grupper. Samtidigt växer Pythons popularitet väldigt snabbt, det har nu även passerat JS som mest använda språk på github (d.v.s. det är #1 där).

Så hur är det relevant här? Att skriva CUDA-kernels gör man primärt för att få upp prestanda rejält, något "vanliga" Python inte direkt är känt för att vara jätte bra på. Vidare kräver effektiv användning av GPU förståelse för "host memory", "global device memory", "shared memory" och "local memory". Det är något man behöver hantera explicit i CUDA och det är exponerat även i Python.

I just detta fall tror jag faktiskt det kan bli riktigt bra med Python. Vissa användningar av Python list-comprehension är en väldigt bra match i hur man vill jobba med GPGPU för att det ska bli effektiv. Och om det blir bra kan rätt mycket exakt samma teknik användas för att då kraftigt SIMD-optimera Python kod (GPUer är rätt mycket väldigt breda SIMD maskiner).

För att ta ett enkelt konkret exempel på hur en CUDA-kernel kan se ut
https://nyu-cds.github.io/python-numba/05-cuda/

from __future__ import division
from numba import cuda
import numpy
import math

# CUDA kernel
@cuda.jit
def add_one_kernel(io_array):
    pos = cuda.grid(1)
    if pos < io_array.size:
        io_array[pos] += 1

# Host code   
data = numpy.ones(256)
threadsperblock = 256
blockspergrid = math.ceil(data.shape[0] / threadsperblock)
# Launch kernel
add_one_kernel[blockspergrid, threadsperblock](data)
print(data)

Och detta är motsvarande "vanliga" CUDA, misstänker att det inte finns någon prestandaskillnad i GPGPU-kernel (PyTorch gör liknande saker "under huven" och ger extremt effektiva GPU-kernels trots att man skriver logiken i Python)

#include <stdio.h>
#include <cuda_runtime.h>

// CUDA kernel in C
__global__ void add_one_kernel(float *io_array, int size) {
    int pos = blockIdx.x * blockDim.x + threadIdx.x;
    if (pos < size) {
        io_array[pos] += 1.0f;
    }
}

int main() {
    const int N = 256;
    // Allocate host memory
    size_t size = N * sizeof(float);
    float *h_data = (float*)malloc(size);
    for (int i = 0; i < N; ++i) {
        h_data[i] = 1.0f;
    }
    // Allocate device memory and move from host to device
    float *d_data;
    cudaMalloc((void**)&d_data, size);
    cudaMemcpy(d_data, h_data, size, cudaMemcpyHostToDevice);
    int threadsPerBlock = 256;
    int blocksPerGrid = (N + threadsPerBlock - 1) / threadsPerBlock;
    // Launch kernel
    add_one_kernel<<<blocksPerGrid, threadsPerBlock>>>(d_data, N);
    cudaMemcpy(h_data, d_data, size, cudaMemcpyDeviceToHost);
    // Print result
    for (int i = 0; i < N; ++i) {
        printf("%.1f ", h_data[i]);
    }
    printf("\n");
    // Cleanup
    cudaFree(d_data);
    free(h_data);
    return 0;
}

Korrekt eftersom Python är ett programmeringsspråk. Om Python inte är programmering så är inte C++ programmering.

Python är ett imperativt språk och konkurrerar inte med andra språk. Det är ett språk och inte ett företag. Lite som att säga att svenska konkurrerar med spanska ... Vad innebär det ens?

Jag kodar C och har haft givande diskussioner med en kund som enbart ville ha en lösning i Python eftersom det var deras gemensamma kompetens i teamet som skulle ta emot leveransen. Det fungerade fint så detta låter som ett "you problem".

Nu snackar du i nattluvan igen...

Nu gör du en vild tolkning...

Kunden säger att dom har en delat kompetens inom teamet gällande Python och några kodar C++, några kodar C#, några kodar Ruby men den gemensamma nämnaren är Python. Dom vill att alla i teamet ska kunna hjälpas åt med underhåll.

Du skrev att C-utvecklare och Python-utvecklare inte kan diskutera kod. Jag är C-utvecklare och kunden är i huvudsak Python-utvecklare. Vi kunder diskutera kod. Det bevisar att ditt påstående är felaktigt.

I deras team finns folk som i huvudsak kodar Python och C++ sekundärt. Utvecklare tappar inte magiskt 80 IQ för att man i huvudsak kodar Python och blir helt oförmögen att kunna skriva/förstå annan kod. Kundens Python/C++-utvecklare skriver väldigt mycket bättre C++ än vad jag gör som C-utvecklare. För att i C++ använder man bibliotek i större utsträckning än i C.

Jag drog in IQ för att överdriva det som jag tycker är tramsigt med ditt påstående. De flesta utvecklare kodar mer än ett språk och det är korkat att påstå att en person som utvecklar Python i huvudsak inte skulle kunna förstå sig på ett annat språk. Jag har bevisligen observerat Python-utvecklare som förstår sig på C++.

Nej man behöver inte bli duktig på allt men att kunna två språk är inte ovanligt och varken Python eller C++ är ovanliga språk, dvs sannolikheten är inte noll och sannolikheten är inte låg att utvecklare kan dess språken.

"Utan att grotta ner sig i detaljer", visst man behöver inte allokera och frigöra minne men man blir ju inte helt bort-abstraherad från att det finns CPU- och minnesbegränsningar och man vinner ju fortfarande på att känna till saker om filsystem, nätverk osv.

"...eller skriva återanvändbar kod, arkitektur och annat.", detta skriker också okunskap från din sida. Varför skulle generella kodningstekniker inte vara viktiga för Python?! Om nu Python är så ineffektivt enligt dig, skulle inte återanvändning av kod och arkitektur spela en ännu viktigare roll för Python-utvecklare?

Vad betyder "hårdkodade lösningar" enl. dig? Konstanter är hårdkodade och jag såg en hel del konstanter i din kod så bevisligen använder du dig av hårdkodning.