🇨🇦 vexatious litigant

@saltyAom That is like saying you need concrete proof that "something break" when I fire all the senior engineers. Look, you can live in a shanty town or you can have concrete buildings and plumbing. Either way nothing break right? The bun port is 60% pointless garbage, bruh.

I think a lot of people are overreacting about Bun Rust rewrite I do understand the concern of vibe coding a million line and it’s good to be skeptical But as an engineer, I’ll need a concrete proof that something break before I make a strategic move

@bunjavascript Here is a diff from your zig -> rust port. These don't look like adult programming languages... They way you are using them. 50% of the port looks like Claude reinventing a kooky version of the standard library instead of calling it.

🤏 update:

@jarredsumner I spend 50% of my C++ programming time telling Claude to clean up after itself... I spend the other half reminding it how to be a senior software engineer. By my calculations you have 6 months left of cleaning up slop.

We’re treating this codebase like it’s under way more scrutiny than before, because it is. A year ago, rewriting an entire 700k LOC codebase in a new language in 6 days was impossible. Today, it doesn’t sound like it should work. And yet, it works well.

Bun in Rust is better than the original, and it’s going to keep getting better. We fixed a lot of bugs inherited from the original. We’re fuzzing a lot more.

@lauriewired This is exactly the same as mmap()'ing your whole harddrive at the block layer and then hacking your ssd's firmware to offload operations. And no, you are talking crazy about a "remote atomic." Either your cores need to sync or they don't.

I just can’t get over how neat CXL type 3 is. Imagine having a 1TB bucket of memory. But! Instead of 1TB of DDR5, you have a tiered CXL accelerator. To the OS, it *looks* like regular memory, you address it in the same way. Maybe your accelerator is actually 100GB of DDR5, and ~1TB of high bandwidth flash. The first 100GB is your buffer, and a little controller slowly flushes it out. Many, many workloads are not hammering RAM enough for you to notice. Wait! You could get even more clever. With regular memory, bouncing cachelines between CPU cores is annoying. Often, you’ll program your way around this (avoiding a shared counter) by having each thread maintain a temporary local state with occasional global syncs. But, if we have a custom CXL 3 memory device, that slow global merge could be implemented in hardware instead. You’d never have to have cores fight over the same cacheline, because the shared-counter would be local to the CXL device! Aka, a remote atomic! This is essentially the concept of NDP (near-data processing), and of course there are much, much more fancy algorithms you can do with it, that’s just one example. But you can imagine, especially with database-style operations, how much bandwidth you could save not having to round-trip to the CPU and back for every operation. Imagine if your RAM could run a regex for you! We’re getting really close to that world.

@fluxdev3 @yutongwu111140 oh wow, clang is a lot better than gcc at that code:

@ajohnston97629 @yutongwu111140 `isxdigit` is very likely using a LUT. The main memory fetch would be punishing but you would only pay this cost very occasionally and most of the time you'd have a <5 cycle cache fetch. I benchmarked isxdigit vs manually implemented LUT and the results are pretty much the same

This code could be optimized into pure arithmetic, but I'm too lazy to change it

@fluxdev3 @yutongwu111140 That version has assembly set up and tear down that should go away in an inlined loop. The actual per character cost is 5 cpu cycles. (vpextrb is 2 cycles and "and" is free.)

@fluxdev3 @yutongwu111140 MUSL libc doesn't use a LUT: git.musl-libc.org/cgit/musl/tree… glibc was written by hippies for desktop processors. if you are processing hex in a tight loop try this. let me know if it is faster.

@FFmpeg The linux foundation has sponsors, it sounds like they can pay. linuxfoundation.org/about/members I can easily triage/fix all your bugs not for free. I'd love to set up an AI to try to reproduce all your AI generated reports.

FFmpeg is critical infrastructure for a lot of big companies. The security-report workload is rising fast. It would be nice if donations, sponsorships, and code contributions kept pace.

@fluxdev3 @yutongwu111140 This avoids a 10 cpu cycle pipeline stall from using a logical operator or a 100 cycle main memory cache miss from a lookup table. BUT IT DOESNT MATTER BECAUSE THE *LINKER* CAN INLINE THE STANDARD LIBRARY WHICH IS WELL WRITTEN: int isxdigit( int ch );

@yutongwu111140 For ASCII, just use a LUT. You won't miss 128 bytes of memory needed to store it.

Fun fact for a Friday: Once your metadata has been preserved under Bill C-22 the Lawful Access Act (arguably to protect the children and find ticking bombs), it will be available for ANY kind of investigation and compellable in connection with civil litigation.

@kmcnam1 all corporate logos end up resembling buttholes in the end.

@valigo please don't post about how we should just do dumb stuff because it hurts your fingers to type smart stuff.

Ok here's real hot take - mmaped files are highly overrated, because modern OSes aggressively cache files in RAM for both read/write, so for most use-cases just reading entire file all at once is better than trying to be smart. With that said (lowering the hottness of the take I know weak Twitter game), I'm not saying that mmapping files and doing these page cache tricks is always useless - it just has more niche use cases than many people think. Dmitriy works on highly advanced batshit crazy file searcher, and if he uses memory mapped files it doesn't mean you should!

@yutongwu111140 I rewrote the standard library so i could use hxnull and hxnullptr. Except you can't export "#define hxnull 0" from a C++ module so hxnullptr is going to have to be it in client code going forward. github.com/whatchamacalle…

null nullptr monostate nullopt void 0 empty_view Write whichever one you use

@sudox7 you missed an optimization:

every for loop in C is syntactic sugar. the compiler sees a while loop. they produce identical machine code C has three loop constructs: for, while, do-while. at the assembly level there is one: a conditional jump the compiler doesn't care which one you wrote. it cares what the condition is and where to jump. every loop you've ever written becomes CMP, JNE, and a label

@0xglitchbyte Object oriented programming redistributes code and data around process memory in order to ruin processor cache coherency. Freedom for Ukraine 🇺🇦.

Wise words

@neogoose_btw operating systems are for losers. github.com/whatchamacalle…

when you need to allocate a huge chunk of memory you can just ask your system to allocate the memory *the way OS expected it to be done* and not use a multi-thousand line stateful dependency that you call "allocator" because it will never return it back after you free

@Boost_Libraries Ok cool, you are just trolling until you provide data that includes: __attribute__((hot)) __attribute__((flatten))

Boost.Container benchmarked segmented deque algorithms across six compiler configurations The spread: 1.71x to 5.93x geomean speedup The surprising part: adding #pragma unroll(4) boosts GCC by 60%. Clang regresses. MSVC ignores it entirely Your compiler choice matters more than you think

Same segmented algorithm. Same deque. Same data Six compilers. Wildly different results 🧵👇

@pskocik Here is my non-allocating version of the standard library that does just that: github.com/whatchamacalle…

Worst way to do linked lists/data-structures. If you must do linked datastructures like lists or trees, make it Linux-style intrustive linked structures, decoupling the linking from node de/allocation.

@mu_chrinovic I consider it good practice to explicitly use the "ternary operator" when you are expecting branchless operation. This is because the most basic compiler should have explicit branchless support for that operator.

didn't actually check the instructions generated by the compiler because they don't know assembly, computers nor understand anything they post about award.

@sysxplore Linux developers have officially dropped support for 32-bit x86 CPUs, specifically the Intel 486 (and early 586/Pentium) processors.

Minimal System Requirements