There isn't a language that achieves C's performance, access to hardware and portability while also having superior syntax. The reason C is hard is because it makes sacrifices to enable the above. A Rust (for example) compiler targeting many microcontrollers (8/16-bit word size (not all), Harvard architectures like AVR, non-8-bit byte) simply can't be written due to assumptions made by the spec. Many such architectures are still in use.
This is interesting. I wonder who the "other allocator" was. I think this would benefit from direct comparison with jemalloc, glibc and others. It would also be interesting to observe the effects of different "page" sizes (a better name than "pages" wouldn't go amiss either).
The developers of each have engaged in a few flamewars and the commenter I replied to was critical of GrapheneOS using similar language, so I made a (tongue in cheek comment) implying the commenter was starting the flamewar back up
The EU's proposed system uses ZK proof. You get a PGP signed message from "someone" who knows your identity (government or private agency) then store it on your phone to pass to websites that need your age. It does have an obvious flaw in that whoever you give the token to has no proof it's actually yours.
Fair point that binary search causes a lot of branch mispredictions. Did you ever measure whether the unrolled linear search with 8 elements outperforms a "rolled" one? Because with instruction level parallelism I wonder how much difference removing 8 mostly easily predicted (in the linear search) branches makes.
Interesting, thanks for sharing. I actually assumed ?: desugared to an if-else and never checked. I was a bit confused by the if-else chains you have e.g. on line 111 where it looks like you could just use the else branch for every case?
You could circumvent the counter issue by pinning to a specific core, otherwise you'd have to use scheduler events (ftrace/perf on Linux) to know which CPU you were running on at specific times and when so you could subtract the right counters (I've had to do this before and it isn't pretty). It would also prevent issues where your task gets preempted and moved to another core and you have to warm the caches again. If you use Linux, options like isolcpus and nohz_full ensure you're not measuring the scheduler/other tasks but have to be set at boot. But if your loops between clock_gettime take substantially more than clock_gettime itself then at least the timer overhead is probably not that important.
As for the branch prediction, I would think most of the branches would be predicted correctly because usually you'll have runs of "not x" before each "is x". Switching between many loops of course hurts the prediction.
My SIMD knowledge only extends as far as which compiler options make my code faster.
No shame using LLMs, I use them extensively, but I find I have to write some code yourself because I make noticeably more mistakes coding if I have let the LLM do everything for a couple of weeks.
How did you do it? Hopefully you generated thousands of such arrays and measured the cost of searching all of them as a single iteration? Because depending on what you use to measure time, the overhead of reading the timer would likely dwarf the cost of searching such a small array. The best case is a dedicated cycle counter instruction/register (e.g. rdtsc) and even that may cost hundreds of cycles. Cache hits cost less than a cycle so if your timing code gated a small number of searches you essentially didn't measure the search at all.
That aside your findings point to the prefetcher having identified your linear searches as sequential access so practically every single access was a cache hit (you effectively measured the latency between a CPU and its L1 cache). If you wanted to test this you could do something like make each element some number of cache lines wide. Stream prefetchers have a maximum stride, so variables more than that many bytes apart won't be prefetched. Google's multichase benchmark uses 256 bytes IIRC.
I'm guessing you don't really do this for users since the response for all of them should be 401 on any user that you aren't logged in as? I would argue even for IDs that don't exist, you should get the same error whether they don't exist or you just aren't authorised to see them. It's been a few years since I worked in web but I think that's what I would have done, GitHub does similar for private repos.
Considering they knew these failure modes in advance, would it not have been prudent to put some sort of self-righting mechanism on the lander? Something like the mechanical arms you see in Robot Wars.
Well, almost. I use a lot of assertions to check the obvious (value out of range, null pointer, etc.) and test the happy path(s) to prove the code at least works in the cases I can anticipate. I add unit tests for complex algorithms, and to prove a reported bug is what I think it is and that it has been fixed. Otherwise, I think using unit tests to find bugs is mostly busywork.
For even a fairly trivial piece of code, the search space for bugs can be vast or even infinite. Writing unit tests to find bugs within that space is like throwing darts at an infinitely large wall and trying to hit an unknown number of invisible targets. You can only write tests for the potential bugs you anticipate - if you could anticipate a bug, you wouldn't write it, right? You end up with dozens or hundreds of tests that probably never failed, except when you have to change something. Such was my experience when I tried to maintain high code coverage. When I switched to writing assertions and acceptance tests, my rate of bug reports did not change, and I was more agile.
What is your opinion of code coverage requirements now? I have been in a "phase" of seeing them as "code quality theatre". Considering that a function which takes a single 8-bit integer as an argument already has 256 unique inputs, and may bug only on 1-2 values, 100% statement coverage can be very misleading. A typical function has billions or trillions of unique inputs and 100% statement coverage could be very nearly 0% state space coverage. I'm 5y into my career (but 15y into programming) and aware that my opinions will change and develop as I progress. This one has been stable for a while though.
I think the best way to achieve this is by providing an OS API that results in the files always being created in the same place. Applications/libraries could still choose their own filenames and syntax, just the location would be OS controlled. I think there is room for a new desktop/laptop OS to emerge and one good idea from mobile OS design I would like to see is having everything be an API call that allows the OS to impose standardisation, permissions and user preferences rather than the free-for-all desktop OSes have (though I propose letting the user run non-compliant applications, and not porting the iOS app store only model into the OS).
At 29, I don't feel like I was "basically finished" until 25 or so, and feel significantly more mature than I was even a year ago. I'm very interested to know why you think 13 year olds are mostly finished developing.
I was talking about the posts/linked articles rather than the comments. I counted six in the first 20 posts, and the titles are mostly quite ad-like.
While I was initially interested by the announcement, the size, lack of internal battery and price makes this a hard no for me. Idk what they were thinking - doesn't anyone remember Google Glass? That was half the price and size and nobody wanted it.
No! Since I made a new email account with email aliases allowing me to give a unique address to every company I haven't received a single spam email (apart from advertising from said companies) in over a year.
I have however been getting spam WhatsApp and Telegram messages claiming to be from recruiters. These are quite obvious though as they lack any of the details recruiters usually include when they reach out on LinkedIn.