3,658 karma · joined May 9, 2019
My parents have formative memories of watching the moon landings as kids, and I of watching the space shuttle. As someone who ended up where I am in large part due to my curiosity about the world growing up, reading of OP's kid watching a rocket launch, thinking critically about what they're seeing, and learning more about the world from it is a joyous thing.
I assume this is referring to the tweet from the launch of the M1 showing off that retaining and releasing an NSObject is like 3x faster. That's more of a general case of the ARM ISA being a better fit for modern software than x86, not some specific optimization for Apple's software.
x86 was designed long before desktops had multi-core processors and out-of-order execution, so for backwards compatibility reasons the architecture severely restricts how the processor is allowed to reorder memory operations. ARM was designed later, and requires software to explicitly request synchronization of memory operations where it's needed, which is much more performant and a closer match for the expectations of modern software, particularly post-C/C++11 (which have a weak memory model at the language level).
Reference counting operations are simple atomic increments and decrements, and when your software uses these operations heavily (like Apple's does), it can benefit significantly from running on hardware with a weak memory model.
I've also done something along these lines myself in Super Metroid. Mother Brain's neck moves in a conceptually simple but very chaotic pattern influenced by Samus's vertical movement, and there's a cutscene during the fight where the positioning of her neck can make a difference of about 7 seconds. The TAS fight used complicated movement to manipulate her neck position developed through much trial-and-error, while the best known human-viable manips were several seconds slower.
I wrote a program to search the state space for optimal movement patterns, and working with some speedrunners we were able to come up with a new human-viable manipulation that matched the previous TAS fight, as well as a new TAS manipulation that saved an additional 41 frames.
Might be a little long for a title :)
Scaling up the math in the article, which states it would take 6 CPU-minutes to generate enough tokens to scrape 11,508 Anubis-using websites, we're now looking at 4.3 CPU-hours to obtain enough tokens to scrape your website (and 50,000 CPU-hours to scrape the Internet). This still isn't all that much -- looking at cloud VM prices, that's around 10c to crawl your website and $1000 to crawl the Internet, which doesn't seem like a lot but it's much better than "too low to even measure".
However, the article observes Anubis's default difficulty can be solved in 30ms on a single-core server CPU. That seems unreasonably low to me; I would expect something like a second to be a more appropriate difficulty. Perhaps the server is benefiting from hardware accelerated sha256, whereas Anubis has to be fast enough on clients without it? If it's possible to bring the JavaScript PoW implementation closer to parity with a server CPU (maybe using a hash function designed to be expensive and hard to accelerate, rather than one designed to be cheap and easy to accelerate), that would bring the cost of obtaining 500k tokens up to 138 CPU-hours -- about $2-3 to crawl one site, or around $30,000 to crawl all Anubis deployments.
I'm somewhat skeptical of the idea of Anubis -- that cost still might be way too low, especially given the billions of VC dollars thrown at any company with "AI" in their sales pitch -- but I think the article is overly pessimistic. If your goal is not to stop scrapers, but rather to incentivize scrapers to be respectful by making it cheaper to abide by rate limits than it is to circumvent them, maybe Anubis (or something like it) really is enough.
(Although if it's true that AI companies really are using botnets of hacked computers, then Anubis is totally useless against bots smart enough to solve the challenges since the bots aren't paying for the CPU time.)
This is not unique to Apple, it's impossible to prove any system is free of a backdoor, including Linux distributions (see: the xz backdoor, or "Reflections on trusting trust"), unless you hand-crafted your whole smartphone from raw silicon.
It's like a secondary rate-limit on the ability of scrapers to rotate IPs, thus allowing your primary IP-based rate-limiting to remain effective.
This is not completely true - modern branch predictors can recognize patterns such as "this branch is taken every other time", or "every 5th time", etc. They also can, in some cases, recognize correlations between nearby branches.
However, they won't use factors like register or memory contents to predict branches, because that would require waiting for that data to be available to make the prediction -- which of course defeats the point of branch prediction.
Fully agreed on that -- the unsafe keyword means it's unsafe.
> nor is it in any way special in being able to create statically-verifiable abstractions around an unsafe core.
This isn't really true. Rust's type system has:
- Affine types
- Lifetimes
- Borrowed and exclusive references
- Thread-safety
- Explicit delineation between safe and unsafe code -- with no UB in safe code, and a (cultural) design principle that unsafe code is not allowed to make unchecked assumptions about the behavior of safe code
Most mainstream languages do not have any one of these features, let alone all of them. Thus, Rust's ability to "create statically-verifiable abstractions around an unsafe core" is in practice far more powerful than in C, C++, or Zig. You certainly have the ability to create some such abstractions in other languages, but you cannot statically verify nearly as many properties. (And of course there are languages like SPARK that can verify even more statically than Rust.)
In my experience, as a systems programmer who heavily uses Rust to interact with FFI, hardware MMIO and DMA, interrupt handling, networking code, etc., Rust's ability to safely abstract unsafe primitives is easily the most practically useful aspect of the language. It's not a silver bullet that turns incorrect code into correct code, but it is incredibly good at verifying the correctness of a large application built from small low-level primitives. If you're interfacing with buggy C code, Rust certainly isn't going to help you much -- but it does makes a huge difference in preventing "you're holding it wrong" bugs when interacting with a C API.
An unsafe block declares an axiom: you're asserting to the compiler that you've verified (statically with the type system or dynamically with runtime assertions) all preconditions necessary for some primitive to be sound (free of UB). The compiler can then use that axiom to prove the soundness of all code that interacts with that primitive. When I write a driver to perform a DMA transfer, I only have to think through all the concurrency, alignment, lifetime, moveability, caching, and cancellation requirements once, and the compiler will check them for me every time I (or anyone else) use that driver in an application.
In addition, it's often considered permissible for C APIs to exhibit undefined behavior if their API contracts are violated. This means that a bug in Rust code that calls into a C API incorrectly can (indirectly) cause undefined behavior. For this reason, all FFI calls are marked unsafe in Rust.
The typical approach to using C libraries from Rust is to create a "safe wrapper" around the unsafe FFI calls that uses Rust's type system and lifetimes to enforce the safety invariants. Of course it's possible to mess up this wrapper and have accidental undefined behavior, but you're much less likely to do so through a safe wrapper than if you use the unsafe FFI calls directly (or use C or Zig) for a couple reasons:
- Writing the safe wrapper forces you to sit down and think about safety invariants instead of glossing over it.
- Once you're done, the compiler will check the safety invariants for you every time you use the API -- no chance of making a mistake or forgetting to read a comment.
[0]: This could be avoided/mitigated with some kind of lightweight in-process sandboxing (e.g. Intel MPK + seccomp) to prevent C libraries from accessing memory that they don't own or performing syscalls they shouldn't. There's some academic research on this (and I experimented with it myself for a masters thesis project), but it generally requires some (minimal) performance overhead and code changes at language boundaries.
It looks like a user in the HN thread noticed the irregularities on the Italian Wikipedia [0] and started the deletion discussion [1] that the article credits with kickstarting this investigation.
[0]: https://news.ycombinator.com/item?id=44035222
[1]: https://it.wikipedia.org/wiki/Wikipedia:Pagine_da_cancellare...
This means that a function that returns an uninhabited type is statically known to not return -- since there's no way it could construct an uninhabited value for a return expression. It also means you can coerce a value of uninhabited type into any other type, because any code which recieves a value of an uninhabited type must be unreachable.
For instance, in Rust you can write the following:
let weekday_name: &str = match weekday_number {
1 => "Sunday",
2 => "Monday",
3 => "Tuesday",
4 => "Wednesday",
5 => "Thursday",
6 => "Friday",
7 => "Saturday",
i => panic!("invalid weekday number: {i});
};
This means that I have a difficult time reading text with very large paragraphs. If a paragraph goes on for 10+ lines, I'll start to lose my place at the end of most lines. This is infuriating and drastically impairs my ability to read and comprehend the text.
It's interesting to me that you mention preferring a ragged right over justification, because I literally do not notice the difference. This suggests to me that we read in different ways -- perhaps you focus on the shape and boundaries of a line more than the shape of a paragraph. This makes intuitive sense to me as to why you would prefer narrower columns.
I don't think that I'm "right" for preferring wider columns or that you or anyone else are "wrong" for preferring narrower columns. I think it's just how my brain learned to process text.
I have pretty strong opinions on what's too wide of a column and what's too narrow of a column, so I won't fullscreen a browser window on anything larger than a laptop. Rather, I'll set it for a size that's comfortable for me. If some web designer decides "actually, your preferred text width is wrong, use mine instead" then I'm gonna be pretty annoyed, and I think rightfully so, because what those studies say is "optimal" for the average person is nigh unreadable for me. (Daring Fireball is the worst offender I can think of off the top of my head. I also find desktop Wikipedia's default view pretty hard to read, but the toggleable "wide" mode is excellent).
Different people process visual information differently, and people reading articles have different goals, different eyesight, and different hardware setups. And we already have a way for users to tell a website how wide they want its content to be: resizing their browser window. I set the width of my browser window based on how wide I want pages to be; and web designers who ignore this preference and impose unreadable narrow columns because they read about the "optimal" column width in some study or another infuriate me to no end. Optimal is not the same for everyone, and pretending otherwise is the antithesis of accessibility.
It's true that LLVM has restrictions on what you can do with undef/poison memory, but LLVM also supports the "freeze" operation that comes up in the Rust discussions (which transforms an undefined value into an arbitrary, well-defined value). It would certainly need to be unsafe to avoid violating invariants like you mentioned, but "LLVM" isn't the blocker to supporting this.
Rather, there are more subtle problems with reading from initialized memory -- for example on Linux, a heap allocator might use MADV_FREE on free memory, which hints to the kernel that a page contains freed memory and the operating system is not required to preserve its contents until the application writes to it again. This means the following sequence of events is possible:
- An application frees some memory, and the heap allocator invokes madvise(MADV_FREE) on the address range.
- The application makes a heap allocation, obtaining a pointer to the free'd memory.
- The application freezes the uninitialized memory and reads from it.
- Due to memory pressure, the kernel decides to reclaim the free'd memory. It unmaps it from the process and uses it somewhere else.
- The application accesses the first allocation again, and sees that its value has now changed to all-zeroes.
Thus, we can see that "freezing" arbitrary memory can't actually be implemented on real-world systems -- the contents of uninitialized memory really can change out from under you until you write to that memory.
It would be possible to implement a "by-reference freeze" that copies a MaybeUninit<T> to a new location, but introducing this functionality still has the downside that you can write a Heartbleed bug without invoking undefined behavior, which is what makes it controversial.
When you're working with anything below the application level, C's confusing and underspecified rules about UB are almost impossible to keep track of, especially when it comes to aliasing and volatile/MMIO. The spec is so difficult to read and full of complicated cross-references that to actually get a practical answer you have to look for a random Stack Overflow post that may or may not have a correct interpretation of the spec, and may or may not address your specific problem.
Rust right now feels a lot harder to work with, because the spec isn't done. When you have a concrete question about a piece of code, like "is this conversion from an &mut to a *mut and back sound", and you try to look for documentation on it, you get either "Nobody knows, Rust aliasing model isn't defined"; a hand-wavy explanation that is not rigorous or specific; or a model like Stack Borrows or Tree Borrows that's defined a little too formally for easy digestion :)
But when I really started digging, I realized just how much cleaner Rust's semantics are. References aren't actually hard, Tree Borrows basically boils down to "while an &mut reference is live, you can only access the value through pointers or references derived from that reference". Pointer operations have straightforward semantics, there's no confusing notions of typed memory, and no UB "just because" for random things like integer overflow. It's just so much less complicated to understand than C's abstract machine.
I'm really looking forward to things like MiniRust, and to an aliasing model making it into the Reference / other documentation, because at that point I feel like unsafe Rust will be way easier to write confidently and correctly than C.
Congrats on the publication, and thanks again for the work you all have put into this.
That means the 2 clock cycles could theoretically make an observable difference if they cause the CPU to miss a frame deadline and cause the game to take a lag frame. But this is rather unlikely.
In order to understand what actually happens, we need to look a little closer at the physical structure of a data bus -- you have long conductors carrying the signals around the motherboard and to the cartridge, separated from the ground plane by a thin layer of insulating substrate. This looks a lot like a capacitor, and in fact this is described and modeled as "parasitic capacitance" by engineers who try to minimize it, since this effect limits the maximum speed of data transmission over the bus. But this effect means that, whenever the bus is not being driven, it tends to stay at whatever voltage it was last driving to -- just like a little DRAM cell, producing the "open-bus reads return the last value transferred across the bus" effect described in the article.
It's not uncommon for games to accidentally rely on open-bus effects, like DKC2. On the NES, the serial port registers for connecting to a controller only drive the low-order bits and the high bits are open-bus; there are a few games that read the controller input with the instruction LDA $4016 and expect to see the value $40 or $41 (with the 4 sticking around because of open-bus).
There's also speedrun strategies that rely on open-bus behavior as part of memory-corruption or arbitrary-code-execution exploits, such as the Super Mario World credits warp, which sends the program counter on a trip through unmapped memory before eventually landing in RAM and executing a payload crafted by carefully manipulating enemy positions [1].
But there's some exceptions to the usual predictable open bus behavior. Nonstandard cartridges could return a default value for unmapped memory, or include pull-up or pull-down resistors that impact the behavior of open bus. There's also an interesting interactions with DMA; the SNES supports a feature called HDMA which allows applications to schedule DMA transfers to transfer data from the CPU to the graphics hardware with precise timing in order to upload data or change settings mid-frame [2]. This DMA transfer temporarily pauses the CPU in order to use the bus to perform the transfer, which can change the behavior of an open-bus read if a DMA transfer happens to occur in the middle of an instruction (between reading the target address & performing the actual open-bus read).
This very niche edge case has a significant impact on a Super Metroid speedrun exploit [3] which causes an out-of-bounds memcpy, which attempts to transfer a large block of data from open-bus to RAM. The open-bus read almost always returns zero (because the last byte of the relevant load instruction is zero), but when performed in certain rooms with HDMA-heavy graphical effects, there's a good chance that a DMA transfer will affect one of the reads, causing a non-zero byte to sneaks in somewhere important and causing the exploit to crash instead of working normally. This has created a mild controversy in the community, where some routes and strategies are only reliable on emulators and nonstandard firmwares; a player using original hardware or a very accurate emulator has a high chance of experiencing a crash, whereas most emulators (including all of Nintendo's official re-releases of the game) do not emulate this niche edge case of a mid-instruction HDMA transfer changing the value of an open-bus read.
Also, the current fastest TAS completion of Super Metroid [4] relies on this HDMA interaction. We found a crash that attempted to execute open bus, but wasn't normally controllable in a useful way; by manipulating enemies in the room to influence CPU timing, we were able to use HDMA to put useful instructions on the bus at the right timing, eventually getting the console to execute controller inputs as code and achieve full arbitrary code execution.
[1]: https://youtu.be/vAHXK2wut_I
[2]: https://youtu.be/K7gWmdgXPgk
The main safety benefit of Rust in a low-level environment is not that you never have to write unsafe code; it's that the language allows you to encapsulate unsafe code and express its safety invariants in the type system. My go-to example of this is the Vec type in the standard library. The language doesn't have any notion of a growable array built-in; it's defined in pure Rust code in the standard library using some unsafe code that exposes a fully safe API. And using the invariants expressed in that API, the compiler can prove the safety of any user code that uses a growable array, under the axiom that the unsafe definition of Vec was correct.
The standard library is rich enough that application developers never really have to touch unsafe, and that's great for them -- but for those of us doing systems programming, this "axiomatic safety" (as I like to think of it) is the real power of Rust. We can do complicated and unsafe things (like direct hardware access, complicated pointer tricks, concurrent data structures, etc.), write out the invariants users need to uphold in order for the code to be sound, and then the compiler can prove the program safe under the assumption that our unsafe building blocks are sound. Well-written Rust isn't "littered with unsafes" everywhere; the unsafe code only appears in low-level definitions of data structures and hardware/foreign function interfaces, and the rest of the code is written in safe Rust.
> manual memory management, manual layout control, and manual resource management to retain similar behaviors.
All of these things are manual in Rust. There's no GC and the compiler does not insert allocations or deallocations; it's all done by user or library code. Layout is entirely controlled by the programmer (the compiler does optimize struct layout by default, but you can opt out by marking the struct #[repr(C)]).
Rust is not garbage collected, and there is no automatic memory management of any kind. The philosophy is: you manage memory manually, and the compiler checks your work to make sure you didn't make a mistake. The only real difference from C (besides the safety guarantees) is that Rust has destructors, so you can use RAII to simplify cleanup/freeing.
It's also useful in more places than return expressions -- for example, you can make a function return ! to indicate that it's a non-returning function, which is useful for expressing, say, an error handler that must crash the program; or a main loop that must never return. It also can help the compiler generate more compact code when a function is known to not return.
There's currently work in progress to allow you to specify ! as a type everywhere, not just as function returns. This is useful where some generic code expects a function to return a Result with an implementation-specified error type, since an infallible implementation can specify ! as the error type. Then, the type checker can allow the programmer to unwrap a Result<T, !> without checking for errors, and the optimizer can remove the error-checking branches from generic code: https://doc.rust-lang.org/std/primitive.never.html
This has taken a very long time to implement, because of some very subtle implications on type inference that made it difficult to stabilize without breaking compatibility -- but the 2024 edition finally figured out a way to make it possible.
let day_number = match name {
"Sunday" => 0,
"Monday" => 1,
"Tuesday" => 2,
"Wednesday" => 3,
"Thursday" => 4,
"Friday" => 5,
"Saturday" => 6,
_ => return Err("invalid day")
};Does this imply that distributing open-weights models such as Llama is copyright infringement, since users can trivially run the model without output filtering to extract the memorized text?
[1]: https://storage.courtlistener.com/recap/gov.uscourts.cand.43...
.map_err(|e| format!("Failed to read file: {e}")?;
use anyhow::{Result, Context};
fn foo() -> Result<()> {
let data = std::fs::read("/some/file").context("Failed to read file")?;
// ...
}Which is exactly what Rust does -- if the error returned by the function does not match the error type of `?` expression, but the error can be converted using the `From` trait, then the conversion is automatically performed. You can write out the conversion implementation manually, or derive it with a crate like thiserror:
#[derive(Error)]
enum MyError {
#[error("Failed to read file")
IoError(#[from] std::io::Error)
// ...
}
fn foo() -> Result<(), MyError> {
let data = std::fs::read("/some/file")?;
// ...
}
fn foo() -> Result<(), MyError> {
let data = std::fs::read("/some/file").map_err(MyError::IoError)?;
// ...
}Programming involves long periods of thinking interrupted by short periods of typing. Anything you can do to reduce the mental effort of typing reduces the impact of this interruption to your train of thought.
Try programming by hunt-and-peck typing -- it's certainly possible, but having to think about putting each individual character on the screen is incredibly tedious and distracting. This is why people learn things like Vim motions or minimalist keyboard layouts -- anything that speeds up the feedback loop between your brain and your code is an improvement. It's not a drastic difference, but it's significant enough that I now feel mildly annoyed using a regular keyboard when I have to move my whole arm to reach the arrow keys rather than having them right under my fingers on the home row.
The singer produces sound pressure waves into a mic. These pressure waves are measured in dB SPL, and the microphone's specifications will tell you its sensitivity, maximum sound pressure level, frequency response, on- and off-axis response, and so on. An engineer can look at all these specs to choose a mic based on the environment, how much background noise there is and where it's coming from, the quality and character of the singer's voice, etc.
The microphone will produce a voltage, which is measured in dBV or dBu. This voltage travels to a preamplifier, which boosts the signal to a nominal level by applying a gain (in dB, with no units since it's just a dimensionless ratio between input level and output level) and converts it to a digital signal -- measured in dBFS ("decibels full-scale", signal level relative to the maximum level that can fit in the bit-width of the digital signal).
Note that all the different signals going into the preamps have wildly different voltage levels -- a kick drum produces much more sound energy than a singer. And the ratio between SPL and voltage is not fixed; different mics have different sensitivities, and an active guitar amp will generate a signal many orders of magnitude stronger than a passive microphone. For some instruments like synthesizers, "SPL" isn't even a concept that makes sense because the sound is produced entirely electronically, rather than by capturing a mechanical wave. So, the preamps are configured to normalize all the incoming signals to one nominal level for processing.
After the preamp, the signal goes through a digital signal processing chain. Most of these processing steps will affect the level of the signal, and the amount is measured in dB (without units, since this is a dimensionless ratio between input level and output level. Remember, we're dealing with a fully digital waveform, so there is not even a physical measure of "loudness" or "signal strength" that can apply to the signal at this point.)
The signals from all the different sound sources are mixed together, and the mixer's per-channel volume faders are marked in decibels -- usually from +10 to -infinity, with 0 corresponding to "unity gain" (which means the output signal should have the same intensity as the input signal). Again, no units because we aren't measuring a physical quantity, just how much the mixer should change the intensity of the signal.
Finally, the signal is converted back to an analog voltage (measured in dBu) and sent to a power amplifier. The power amplifier applies an adjustable gain, and outputs a signal measured in watts (dBm) for sending to the PA system. You might then walk around the room with an SPL meter to ensure the sound is at a safe level; the value you measure will depend on the frequency and directional response of the speakers, as well as how far away from the speaker you're measuring.
Throughout this process we had signals in the form of sound pressure, voltage, digital samples, and wattage, at power levels ranging from microwatts to kilowatts. Even a simple physical quantity like sound pressure for a single signal is not straightforward -- how far are you measuring it from, and are you talking about SPL before the microphone or after the speaker?
The fact that a single unit is used for all of these different purposes is a feature, not a bug. If my preamp is close to clipping and I turn it down by 3 dB, how much do I need to turn up the gain at my compressor to compensate? Easy -- 3 dB. If we used more "appropriate" physical units at each step of the signal chain, it would be impossible to determine this number quickly or in your head; and would involve taking into account even more factors I haven't mentioned (like input impedances). The fact that decibels are scaled differently depending on whether you're working with voltage or power means that 1 dB corresponds to the same change in loudness everywhere without having to remember whether it's 1 dB of voltage or power.