CmdDot

When it comes to quickly reducing the search space of possible words, it is - that’s how you solve it optimally, even if (or in fact, especially) if the word they chose intentionally does not use the most frequent letters.

The faster you can discard all words containing «e» because of a negative match, the better.

If you want to be really optimal, you’ll use their list of possible words to calculate the actual positional frequencies and pick the highest closest match based on this - that’s what «mostly» was meant to imply, but the general principle of how to reduce the search space quickly is the same

«As such, you want to pick a pair where the odds are as close to 50/50 as possible.»

This is incorrect, the correct strategy is mostly to check the most probable match (the exception being if the people in that match has less possible pairings remaining than the next most probable match).

The value of confirming a match, and thus eliminate all other pairings involving those two from the search space, is much higher than a 50/50 chance of getting a no match and only excluding that single pairing.

In addition to Mastermind, Wordle also falls into the same category.

Optimal play to reduce the search space in both follow the same general pattern - the next check should satisfy all previous feedback, and included entries should be the most probable ones, both of those previously tested, and those not. If entries are equally probable, include the one which eliminates the largest number of remaining possibilities if it is correct.

For wordle, «most probable» is mostly determined by letter frequency - while in Mastermind, it’s pure probability based on previous guesses. For instance, if you play a Mastermind variant with 8 pegs, and get a 2/8 in the first test - each of your 8 pegs had a 1/4 chance of being correct. So you select 2 at random to include in the next guess.

If you then get a 2/8 from the second - you would include 4 previous entries in the next guess, 2 entries from the first that was not used in the second, as well as 2 entries from the 2nd - because the chance you chose the correct entries twice, is less than the chance the two hits are from the 6 you changed.

I don’t see why it would be dependent on the amount of code - the amount of bytecodes is constant, and the likelyhood of bytecode B following bytecode A should remain fairly stable. Adding the bytecode equivalent of fused madd if there’s unused space would be an interesting extension - but maybe a bit unintuitive in the heuristics of how to choose good candidates - if it’s really the mispredictions that cause stalls, you’d want the ones where the split of A -> B and A -> C is fairly even, not the most common combinations. Almost worth a paper of its own to explore :)

From the post: «In the context of resource-constraint embedded devices, it may make sense to tailor an interpreter to a specific applications to gain best performance.»

The «key problems» are also discussed in the introduction of the paper at the top of page 2 - including why it’s practical in their context.

Also in the paper, they say speedups based on optimizing a subset of benchmarks generalize to other benchmarks as well, but not across environments.

Last I checked, starting with an «optimizing your environment» task, is far from being considered «not very practical»

Funnily enough, I ended up not including a PS starting with "A sufficiently smart JIT, however..." ;)

Not really, once a program is compiled with -retpoline, new hardware won't bring back reliable branch prediction.

I'd hope maybe, just maybe, this would be enough to put a focus on compilers producing code that ends up using processor-optimized paths chosen at runtime, to avoid "overheads ranging from 10% to 50%".

Though, in this case, that would essentially mean making the entire executable region writable for some window of time, which is clearly too dangerous, so I guess the 0.1% speedups from compiling undefined behavior in new and interesting ways, will continue taking priority.

I mean, it's a compiler flag right, obviously whoever's going to run a program on an unaffected platform will take the effort to recompile everything with the flag removed.

Just the same way every serious application currently provides different executables for running on systems where SSE2, SSE4.1, or AVX2 is present.