Compare the size of the new air-cooled 40XX cards and the iChill 4090, which is tiny by comparison. The simple answer is just to use liquid cooling if you have a card using 400w. Then all the absurdity just goes away.
The water cooling on my 3090 is heavier than the air cooling for the same card, as you need a coldplate on both sides of the thing to get rid of the heat.
Just strace (follow forks) and look what commands get exec'd.
"Why does musl make my Rust code so slow?" But he's measuring mostly the compiler performance in "cargo build". Is he writing the same amount of data to disk in the same experiments? Seems like there's a lot of opportunity for some shallow investigation to find out more.
ProxyJump was added in OpenSSH 7.3 so systems from a few years ago might not support it. It does the same thing as ProxyCommand with -W %h:%p but you can’t set custom options for the jump connection with ProxyJump.
You can use realloc. It will try to use the existing contiguous span of memory, but if it cannot, it will malloc a new span and copy the previous bytes in and return a pointer to it.
In that case, you need to test if the memory is contiguous and copy to the new pointer if not. O(N^2) in the worst case, where every memory allocation returns a distinct start pointer.
What I was getting at is that in virtual memory the heap is always contiguous (even if it isn't in physical memory, but we only need it to be contiguous in virtual memory). So one can guarantee that the solution will never require copying data if the program exclusively uses the stack, and the resultant string is the only piece of data on the heap. You always add contiguous memory so your string can dynamically grow without ever copying to a new buffer. This probably requires allocating memory through the use of OS-specific syscalls to request new memory pages instead of malloc or realloc.
Yes, the kernel will map virtual to physical however it sees fit, no guarantees there (at least not in user-space via glibc). Realloc will always return a virtually contiguous slice or NULL if it can’t. And you’re right, obviously all those potential subordinate mallocs would be inefficient. :) In this contrived FizzBuzz example case, you could pretty easily do the math and just malloc it all in one go at the start of the function. Fizz and Buzz are the same size, you would just need to add up the iota lengths and the trailing \0. If you take an arg for N (1..N) then stack allocations are not going to work. You need to statically declare their size.
What I'm getting at, though, is that it's possible to implement it without any copies even if the memory consumption cannot be predetermined. Bypass malloc() and realloc() entirely and invoke brk() to increase the program's segment size. This grows the data segment contiguously (in virtual memory), so there will never be a need to copy the result string to a different buffer. In other words point the result pointer to the start of the heap, and never put anything else on the heap.
Someone has to make a business case to get the chargers on the street. There are questions like who owns the sidewalk, how to route sufficient power there, capital outlay for digging up the street and getting the charger there. All those costs and up and the revenue for a given charger is capped. People might pay a premium over the the cost of electricity, but how much? And they have to compete with free charging in many cases.
The throughput is amazing. The screenshot shows 28,375 MB/s — the capital B typically indicates Bytes whereas a lowercase b indicates bits, so your Gb/s translation is a little confusing. The latency is still much higher than main memory or Optane, but that might be fine for many applications.
AMD calls this SEV and has shipped it for some time. It doesn't help much. Here's one of the latest attack papers also with a summary of previous work: https://arxiv.org/pdf/1901.01759.pdf
