devit

Yes, Zen 2+ can execute 4 two-operand LEAs per cycles (according to Agner Fog), and apparently Sapphire Rapids can execute 5 LEAs of any 32/64-bit kind per cycle (according to Intel).

Why does Ocaml need to tag types? (as opposed to statically knowing the type of everything)

Do they not monomorphize generics?

Apparently the perpetrator who sold out their users to the highest bidder is named Benjamin Kramser and they even freely admit the deed on their homepage! (https://www.kramser.xyz/)

The author doesn't seem to have much experience in writing Rust.

For instance, passing RefCell<u32> by value as their code does makes no sense (just use u32...), and the code seems to have a lot of clones, most of which are probably unnecessary, while not having a single instance of the "mut" keyword.

In fact, I'm pretty sure it's completely broken, since their gensym doesn't do what they want, due to their wrong use of clones and refcells (it should take an &mut u32 and just increment it).

And definitely not idiomatic at all.

It's just Perl 6 renamed.

It seems you can get a diagram of the actual circuit like this:

1. Go to https://edaplayground.com

2. Paste the code in the right pane labeled "design.sv"; it's probably a good idea to reduce the number of registers to 2 to make the output more readable

3. On the left, select "Yosys" in tools and simulators (it seems to be the only one that works without additional configuration or fiddling) and enable "Show diagram after run"

4. Click "Run" and it should open an image with a graph rendering showing the circuit. If it doesn't work, try to disable adblockers or popup blockers (it opens the output as a pop-up apparently)

You can also presumably run yosys locally.

In this case, it implements every register as a D flip-flop; the rs outputs are implemented with muxes from the flip flops, and the D flip-flop value is set to either the current value of the register or to data depending whether write_ctrl is set and rd is equal to the register number.

Do they offer shared IPv4 addresses with routing by HTTPS SNI?

Not the crypto, but rather the getpass() function, which simply reads a password from standard input without echoing it.

Since the function uses a static buffer, there is a limit on the password length, which apparently on Solaris was set to the absurdly low value of 8 (glibc uses a more reasonable value: 8192).

Wouldn't it have the opposite effect, of massive centralization?

If you can make a perfectly superconducting electric grid, then it's better to build power plants in a single optimal location (e.g. nuclear power plants in an isolated area with no environmental risks) and deliver to the whole world via superconducting wires.

In case it's not obvious, here is how the attack works:

1. The attacker manufactures a device, such as a smartphone, generates a keypair for it, stores it on an HSM on the device (generally called a "trusted enclave"), and signs the public key of the keypair with a master key

2. The device runs the attacker's software and is designed so that whenever non-attacker software is run with elevated privileges, the HSM is informed of that fact in a way that can't be reset without rebooting (and starting again with the attacker's software). For instance, the device might use a verified boot scheme, send the key the OS is signed with to the HSM in a way that is unchangeable until reboot, and it might employ hardening like having the CPU encrypt RAM or apply an HMAC to RAM

3. The HSM produces signatures of messages that contain statements that the device is running the attacker's software, plus whatever the attacker's software wants to communicate and it won't produce them if it's running software of the user's choice as opposed to the attacker's software as established above. It also includes the signature of its public key with the master keypair, allowing accomplices to check that the device is indeed not under the user's control, but rather under the control of someone they trust to effectively limit the user's freedom

4. Optionally, that attestation is passed through the attacker's servers, which check it and return another attestation signed by themselves, allowing to anonymize the device and apply arbitrary other criteria

5. Conniving third parties can thus use this scheme to ensure that they are interacting with a device running the attacker's software, and thus that the device is restricting the user behavior as the attacker specifies. For instance, it can ensure that the device is running the accomplice's code unmodified, preventing the user from being able to run software of their choice, and it can ensure that the user is using device as desired by the attacker and their accomplices.

This attack is already running against Android smartphone users (orchestrated by Google, in the form of SafetyNet and the Play Integrity API) and iOS smartphone users (orchestrated by Apple) and this extends the attack to the web.

In a lot of places there is either a formal ban on phones and cameras or at least of taking photos, or people simply are used to live simply or in the moment and don't use them (at least not for non-essential things).

This holds for writing and stories as well, so it's best to rely on personal experience and not assume that you can use the Internet to predict the details of the experiences you can have in the world.

Google Pixel, install GrapheneOS on it

LineageOS, GrapheneOS and others will mantain those apps or a replacement, so this is a non-issue.

As long as you have two metal end caps connected by metal poles, and you lay the carbon fiber in the direction that connects the end caps, then it seems that the hull would become concave/"bulge inward" and the fiber would hold pressure by tension.

Not sure whether this would actually work in practice though or whether it would be better than the simple metal sphere design.

You can implement such a system-wide undo with filesystem snapshots using LVM2 or btrfs (or with backup/restore).

However, you also need to properly isolate software in containers or VMs since of course doing a system-wide undo on a system that is running a server will also revert the server state, which is usually disastrous.

People act based on their beliefs, and their beliefs are not necessarily related to reality; in fact, they usually aren't.

The 128 bytes of RAM seems quite easy (game state is 32 bytes for chessboard + 1 byte for side-to-move+castling+en-passant plus 2/3 bytes per move in the search stack + 1 byte to record the depth at which castling was disrupted = 54/64 bytes with depth 10, leaving a luxurious 64/74 bytes for call stack and local variables).

The problem seems to be more the 4KB of ROM, but only if one is trying to make it actually somewhat good, and also perhaps using 1979 tech for programming.

Use pgbouncer

There probably should be a toggle or a separate brightness control (i.e. "maximum brightness" and "default brightness") if something like that is exposed to the web.

Letting content be arbitrarily much brighter than what the user expects seems a terrible design, easily exploitable by advertisers and all sorts of attention thieves.

Seems kind of pointless, since the implementations for different languages are independently written and thus the results depend mostly on the skill of the programmers who wrote them (at least for languages that are efficient), and on the quality of the specific standard library features being used if any.

Well, that's accurate and indeed a major problem.

Subreddit moderators, like unfortunately usually moderators everywhere, can act arbitrarily and there is no way for users to remove or punish moderators.

So this means that /r/$FOO is not actually a subreddit about $FOO, moderated so that exactly any non-spam discussion about $FOO is allowed, but rather a dictatorship ran by whoever happened to grab the name first.

So for instance if a company creates a subreddit about their product before it's announced (which they are guaranteed to succeed at) or perhaps buys or acquires it afterwards, they are allowed to censor it arbitrarily to remove negative opinions or anything they don't like. Amateur moderators can instead moderate according to their personal agenda.

The advantage that something like Reddit can have other normal forums is the existence of an higher authority that users that are banned or censored can petition to to have them ban the moderator instead, and it was pretty absurd that there used to be no way to do that.

What? Prompts are natural language, so I don't see how they can possibly become obsolete.

It looks like the reason this apparently weird instruction exists is that AArch64 has a zero register, meaning you can use csinc with two zero register operands to represent cond ? 1 : 0.

Given that AArch64 has/had no 16-bit instruction support, it probably made sense to provide a generalization of a setcond instruction to make use of the encoding space of 32-bit instructions, and that's one of the most obvious (the other ones being cond ? imm : 0 or cond ? imm : reg).

The fill algorithm is far from being properly optimized:

1. Use pointIdx instead of a string for fill keys. That's going to be way faster and memory efficient

2. There's no need to have separate added and visited. Just keep added and continue checking it before adding to the queue, and don't delete added entries

3. Even better, don't even use added but instead just check the output image data

4. Compute pointIdx incrementally by adding or subtracting 1 or width, only do a multiplication for the first point

5. Don't keep y coordinates in the loop, instead store the minimum and maximum pointIdx and then divide at the end to find the y coordinates (you still need to keep x to compute the x minimum and maximum if you need it, unless you can make the image have a power of two stride, in which case you can just mask pointIdx to compute x)

6. Use a black border instead of doing boundary checks

7. The % 5000 check is horribly slow since division is horribly slow. Use a power-of-two size and a bitwise and to be safe

8. Doing an update every 5000 pixels seems absurdly low. CPUs do billions of operations per second and a pixel should not take more than 100 CPU cycles with proper optimization, so even at around 100 fps you should be able to do in the magnitude of 100K pixels per frame, which means you shouldn't even need to do it incrementally or pre-process. If you really need incrementality you should use both a pixel number check and a timer and adaptively double or halve the pixel number if the timer check gives a too low or high time elapsed.

9. Using "chunks of pixel" is probably faster than single pixels and using horizontal groups of chunks even better, although that requires significantly more code

10. WebAssembly, with SIMD if available, is going to be faster than JavaScript

In general, this code has clearly not been written by someone experienced in writing optimized code, so I assume the pre-processing can also be greatly optimized (if it's even necessary after optimizing the filling code).

Also, there is no need to limit to 256 areas since you can use multiple images and all channels to store larger integers.

The article claims that an allocator that splits memory based on allocation size is called a "buddy allocator". That's misleading: an allocator that allocates an area for each size class is usually called a "slab allocator", while a "buddy allocator" is one that when needed subdivides a memory area with a power of two size into two half-sized areas that are "buddies", does so recursively to satisfy allocations, and coalesces them again when they are free.

E.g. the Linux kernel used (not sure if it's still like this) a buddy allocator to allocate pages and power-of-two blocks of pages and slab allocators to subdivide those pages and allocate data structures.

Another thing that the article doesn't mention that is important is that most production allocators make use of thread-local storage and either have per-thread caches of free blocks or sometimes whole per-thread memory regions. This is to reduce lock contention and provide memory that is more likely to be in the current core's cache.

It works like this:

First, convert the input text to a sequence of token numbers (2048 tokens with 50257 possible token values in GPT-3) by using a dictionary and for each token, create a vector with 1 at the token index and 0 elsewhere, transform it with a learned "embedding" matrix (50257x12288 in GPT-3) and sum it with a vector of sine and cosine functions with several different periodicities.

Then, for each layer, and each attention head (96 layers and 96 heads per layer in GPT-3), transform the input vector by query, key and value matrices (12288x128 in GPT-3) to obtain a query, key and value vector for each token. Then for each token, compute the dot product of its query vector with the key vectors of all previous tokens, scale by 1/sqrt of the vector dimension and normalize the results so they sum to 1 by using softmax (i.e. applying e^x and dividing by the sum), giving the attention coefficients; then, compute the attention head output by summing the value vectors of previous tokens weighted by the attention coefficients. Now, for each token, glue the outputs for all attention heads in the layer (each with its own key/query/value learned matrices), add the input and normalize (normalizing means that the vector values are biased and scaled so they have mean 0 and variance 1).

Next, for the feedforward layer, apply a learned matrix, add a learned vector and apply a ReLU (which is f(x) = x for positive x and f(x) = kx with k near 0 for negative x), and do that again (12288x49152 and 49152x12288 matrices in GPT-3, these actually account for around 70% of the parameters in GPT-3), then add the input before the feedforward layer and normalize.

Repeat the process for each layer, each with their own matrices, passing the output of the previous layer as input. Finally, apply the inverse of the initial embedding matrix and use softmax to get probabilities for the next token for each position. For training, train the network so that they are close to the actual next token in the text. For inference, output a next token according to the top K tokens in the probability distribution over a cutoff and repeat the whole thing to generate tokens until an end of text token is generated.

It's more efficient, both in time (optimized character parsing, no repeated work if parser backtracks) and memory usage (store identifiers as an interned byte string instead of a tree of character tokens).

It also makes it easier for some tools to only use the lexer, which makes them more likely to work even if code is not syntactically correct or written for a newer language revision than the tool.

Radio towers are at much lower altitude, so you need way more of them than satellites to cover the whole planet. Also you need permission on land and you need a boat in addition to the tower on the sea. Plus always having line of sight to the tower is harder unless you make them extra tall. I assume that makes them much more expensive and is why cell phone coverage is not global.

Looks like the actual threat is that it's hard to get currently known chemical weapons synthesized because labs will refuse to do so, while it could be much easier to have some novel AI-generated molecule synthesized because the labs don't know what it does.

Seems easily countered by using the same toxicity prediction software when evaluating synthesis requests (but I'm not sure whether this actually matters, or whether skilled chemists can easily synthesize anything themselves anyway).

Well, the safe approach is to either have the user provide their own API key, or to perform requests on the backend (after verifying the user has an account, correctly authenticated, has paid and deducting from their quota).

Or you could generate a per-user subkey with a quota if the upstream service supports that.