Oddbean new post about | logout
 i guess that's a "no i'm useless to you if you need me to write memory handling" i have a vague concept of how to do it, and i can probably write it really well but it will take me at least 10x longer to do anything, and 100x longer to actually debug it

seriously, i'll just say no, i can build components especially microservice type things and servers in general, code generators, such like tooling, i can invent APIs and codecs, but memory management at that level of irritating detail is just inhuman 
 https://i.imgflip.com/8vh5r1.jpg 
 😂 
 brk(), sbrk() lmfao 
 Actually fun part. My noscrypt makes no calls to allocate heap memory. So much C work can be done on the stack or in the data segment. 

I do maintain forks of mimalloc and rpmalloc for my C# framework  which is fun. 

Take a look into the Cosmopolitan libc and APE loaders which is a pretty awesome project I like to hang out around 
https://github.com/jart/cosmopolitan
 
 i am aware of the uses of stacks

i generally try to use stacks and even registers, it's one of the things i loved about the m68k architecture, so many registers you didn't even need a stack to make many calls, a large number of the improvements that have occurred in the Go compiler output have been achieved through more use of registers, they are the fastest memory in a computer and it's insane how a register-poor architecture like intel has come to dominate, just a reflection of how much abstraction and the bloat it causes is the norm 
 CISC generally does not benefit on a larger register file due to deep pipelines and hyper-threading. Stuff needs to get in and out of registers fast, it also helps with context switching and branch prediction. Again for deep pipeline times L1 is only a few cycles if that.  
 yeah, that's further parts of the reason why i prefer the AMD Zen architecture, because they have simplified the units so much they are literally little sub-dies across the chip instead of a complex whole design as is the norm with intel's engineering

the trend is towards more parallelisation, this helps with latency as well (lower distances of travel) and simplifies manufacturing (less risk of errors in the design due to a simpler design)

as we have seen also, where for a long time intel, notably with the Atom, was getting a better watt/compute ratio 10 years ago, this is now moving in favor of the simplified, parallel architecture of the Zen chips, and i expect the same trend is happening with ARM and MIPS processors as well, with their lower overall engineering budgets versus intel

the difference between SIMD performance on wide bit sizes is phenomenal, i am hoping that some day soon someone makes an secp256k1 signature function in AVX 
 Good chance I will soon :). Likely some ASM because supporting the cross-arch SIMD instructions is a pain in itself. AVX is pretty old now 
 i'm sure i could do it given a month time window, i have reasonable familiarity with assembler syntax in general, and have done a lot of work with iterative operations

just haven't had the time to actually sit down and do it, if you get going on it, i'm keen to follow and if i can, help out

i'm already ridiculously curious about what AVX assembler ops look like 
 Sounds good I'll count you in! 
 gotta follow ya then lol 
 Okay, fair answer. 🫂