hyperpape

You're missing the part where 25% of the problems were representative of problems top tier undergrads would solve in competitions. Those problems are not based on material that only exists in half a dozen papers.

Tao saw the hardest problems, but there's no concrete evidence that o3 solved any of the hardest problems.

Since hashes aren't guaranteed to be unique, a dictionary should use equality to actually confirm that the object with the given hash matches the key present in the dictionary.

This reads as if the required amount of management for different initiatives is constant, but it isn't.

One thing that happens is that when money is plentiful, there is a push to find new ways to generate returns. When money is tight, new bets look bad, and companies may cut new bets and work on optimizing their existing cash-cows.

Strictly, that says nothing about the number of managers needed, but I do think it's less management intensive to keep on with what you're already doing.

This seems like a non-sequitur unless you’re assuming something about the amount that people use models.

Most web servers can run some number of QPS on a developer laptop, but AWS is a big business, because there are a heck of a lot of QPS across all the servers.

I think you might be responding to a different point than the one I made. The 1% I'm referring to is a 1% variation between subsequent runs of the same code. This is a measurement error, and it inhibits your ability to accurately compare the performance of two pieces of code that differ by a very small amount.

Now, it reads like you' think I'm saying you shouldn't care about a method if it's only 1% of your runtime. I definitely don't believe that. Sure, start with the big pieces, but once you've reached the point of diminishing returns, you're often left optimizing methods that individually are very small.

It sounds like you're describing a case where some method starts off taking < 1% of the runtime of your overall program, and grows over time. It's true that if you do an full program benchmark, you might be unable to detect the difference between that method and an alternate implementation (even that's not guaranteed, you can often use statistics to overcome the variance in the runtime).

However, you often still will be able to use micro-benchmarks to measure the difference between implementation A and implementation B, because odds are they differ not by 1% in their own performance, but 10% or 50% or something.

That's why I say that Tratt's work is great, but I think the variance it describes is a modest obstacle to most application developers, even if they're very performance minded.

The basic problem is that if the compiler handles your code in an unusual way in the benchmark, you haven't really measured the two implementations against each other, you've measured something different.

Dead code elimination is the most obvious way this happens, but you can also have issues where you give the branch predictor "help", or you can use a different number of implementations of a method so you get different inlining behavior (this can make a benchmark better or worse than reality), and many others.

As for runtime, if you're creating a library, you probably care at least a little bit about alternate runtimes, though you may well just target node/V8 (on the JVM, I've done limited benchmarking on runtimes other than HotSpot, though if any of my projects get more traction, I'd anticipate needing to do more).

I think Tratt’s work is great, but most of the effects that article highlights seem small enough that I think they’re most relevant to VM implementors measuring their own internal optimizations.

Iirc, the effects on long running benchmarks in that paper are usually < 1%, which is a big deal for runtime optimizations, but typically dwarfed by the differences between two methods you might measure.

For anyone interested in this subject, I’d recommend reading about JMH. The JVM isn’t 100% the same as JS VMs, but as a benchmarking environment it shares the same constraint of JIT compilation.

The right design is probably one that:

1) runs different tests in different forked processes, to avoid variance based on the order in which tests are run changing the JIT’s decisions.

2) runs tests for a long time (seconds or more per test) to ensure full JIT compilation and statistically meaningful results

Then you need to realize that your micro benchmarks give you information and help you understand, but the acid test is improving the performance of actual code.

It really never ceases to amaze me how many basic affordances terminals lack, that we hack around with bash configuration or helper tools.

Of course, I know it's a genuine hard area, and not one I've put any time into fixing, but it's also so high leverage--so many developers spend a ton of time in this environment.

Does Ousterhout actually say modules must always have a longer implementation than their spec, or just that this is a generally desirable feature?

If he did, I agree with you, he was wrong about that. I also agree that the unix file API is probably not a good example.

But whether or not he did, I think the dissection of edge cases would be better off emphasizing that he's got something importantly right that goes against the typical "small modules" dogma. All else being equal, deeper modules are good--making too many overly small modules creates excessive integration points and reduces the advantages of modularity.

P.S. While I'm here, this is not really in response to the parent post, but the example in the article really does not do justice to Ousterhout's idea. While he does advocate sometimes just inlining code and criticizes the pervasive idea that you should shorten any method of more than n lines, the idea of deep modules involves more than just inlinining code.

> Land of free speech? Maybe in like a John Wayne movie was this ever true…

What country would you say has stronger free speech protections than the US? I won't say there's none, because there are roughly 200 countries, and I don't know enough about many of them, but I cannot name one.

Not the UK, France or Germany, and I'd be surprised to find any other European country.

For a sampling of other laws/measures:

  - https://en.wikipedia.org/wiki/Insult_(legal)
  - https://en.wikipedia.org/wiki/L%C3%A8se-majest%C3%A9
  - https://en.wikipedia.org/wiki/Blasphemy_law
  - https://en.wikipedia.org/wiki/Freedom_of_the_press#/media/File:World_Map_of_the_Freedom_of_the_Press_Status,_OWID.svg

Now...if this ban sticks, it will make your snark a lot more valid, starting with the year 2025.

There's disagreement about what exactly makes you a systems programmer, but dealing with the reality that memory is finite is definitely a requirement.

You need mutation or garbage collection (and systems programming is the kind of environment where that's not just "someone else's problem").

This title needs to be fixed.

It should include "DSQL" because AWS Aurora is an already existing managed Postgres from AWS that has pretty strong Postgres compatibility.

DSQL is the new thing with much more limited Postgres compatibility.

I get that you're asking honestly, but it shouldn't be a surprise that academics might sometimes have higher standards than businesses.

Unclear to me why you're being downvoted. I previously knew non-US people refer to rates as "tariffs", but I never heard it in a US context. It's not rare, it's just not a meaning of the word Americans typically know.

As an engineer, if you don't qualify whether your answer is average or max, you've messed up.

It’s amazing that this commentary on the value of prediction markets was written in 2001.

This is technically true, but the kind of comment that muddies the waters. It's true that GM performance is better in realistic games.

It is false that GMs would have any trouble determining legal moves in randomly generated positions. Indeed, even a 1200 level player on chess.com will find that pretty trivial.

> Chromium

> What did Microsoft and Apple gave us

Chromium was in the wild for five years running on WebKit, and the Blink engine they use today is an evolution of that codebase, not a rewrite. Of course, Apple did not create WebKit from scratch, it was based on KHTML/KJS, but it was WebKit that Google Chrome was built on top of, not the previous project.

I immediately jumped to a commentary on the impacts of AI, but really it's probably a bit of a Rohrschach test.

> I always thought "The Onion" was just like Alex Jones in that they call out all the insanity being done by a certain "ilk" of our society which has indeed gone insane thru over-consumption and over-believing in the lies the MSM tells daily, in their failed attempts to slander the political party they've decided to side against. -- You

> Instead, the publication portrayed Biden as a blue-collar "average Joe", an affable "goofy uncle", a muscle car driver, an avid fan of 1980s hair metal, a raucous party animal, a shameless womanizer, a recidivist petty criminal, and a drug-dealing outlaw. --https://en.wikipedia.org/wiki/Joe_Biden_(The_Onion)

I also prefer Fischer, but I think that like most rules discussion, the passion for arguing about it mostly comes from a drive towards simpler systems as an aesthetic preference, not major problems with the status quo.

> If I had one euro per each time I heard a clock saying "30 seconds one time" I'd be rich.

Fun diversion. I figure 10 clocks in the room, a generous estimate is that they alert an average of 50 times per player per game, 4 games per day. A very solid day's work, but most weeks you can only attend a tournament on Saturday/Sunday.

I don't think you'd end up rich, but you could probably make a living.

The article stipulates that 5 is the value that minimizes execution time.

It could have put that on the y-axis, and labeled the left “extremely rushed” and the right side “extremely careful”. Maybe that would’ve been clearer, though I really think it’s clear if are charitable and don’t assume the author has made a mistake.

The article stipulates that 5 is the value that minimizes execution time. So the value between 0 and 5 would’ve been higher. It doesn’t intersect the x-axis because you can’t finish the task in zero time.

See the quote below.

That said, while I didn’t think it was a confusing drawing, I now wish he’d drawn the rest of the parabola, because it would’ve prevented this whole conversation.

> EM: Woah! That’s no good. Wait, if we turn the carefulness knob down, does that mean that we can go even faster?

> TL: If we did that, we’d just be YOLO’ing our changes, not doing validation. Which means we’d increase the probability of incidents significantly, which end up taking a lot of time to deal with. I don’t think we’d actually end up delivering any faster if we chose to be less careful than we normally are.

And I've done high school calculus. It's a picture of a parabola, the derivative is very small near the minimum, and it can look kinda flat if the picture isn't perfectly drawn.

Principles of Product Development makes the point that a lot of real world tradeoffs in your development process are U-shaped curves, which implies that you will have very small costs for missing the optimum by a little. A single decision that you get wrong by a lot is likely to dominate those small misses.

Almost all the big tech companies have had layoffs over the past several years. I think it’s safe to say cost cutting is very much part of their goal.

I appreciate the effort to collect the data, but I think the rotating globe is an idea that looks cool, but makes the visualization harder to use. If I click on us-east-1, there's a 229ms line to...somewhere that I can't see. Meanwhile, I can't see the latency between us-east-1 and us-east-2.

Perhaps if you selected a datacenter, and it switched to a 2-d projection with that datacenter at the center of the map, it would be better?

Or perhaps augment the visualization with a table?

It's worth noting that the benchmark has not been updated as frequently for the past several years, and some versions of compressors are quite far behind the current implementations (http://www.mattmahoney.net/dc/text.html#history).

The one instance I double-checked (zstd) I don't recall it making a massive difference, but it did make a difference (iirc, the current version was slightly smaller than what was listed in the benchmark).

It was also reported by much more reliable sources, and was a statewide project.