HN user

jcranmer

35,436 karma
Posts4
Comments8,221
View on HN

The data center construction boom has precipitated a lot of inflation in electronics and related fields, because the data centers are buying out all of the silicon manufacturing and RAM manufacturing and etc, and all of this stuff is horribly supply-limited. And the people pushing for data center construction are proudly telling us that we need to support this so that we can put half of the population out of work, oh, and we just need a small trillion-dollar subsidy or five to pay for it all (because demand for AI isn't high enough to pay for all of it themselves).

There's no need to invent some malign foreign conspirator to generate unpopularity for this stuff. No, the AI companies are led by unpopular CEOs, who are making unpopular statements (almost cartoonishly so). And opposing a data center is the kind of action that regular people, upset about this sort of stuff, feel that they can actually meaningfully effect. So of course it was going to balloon like it has.

The Roman Republic notably granted citizenship status to most of the socii during the Social War in the early first century BC. Even discounting one-off mass citizenship grants, Roman citizenship was much easier to obtain than pretty much every other Mediterranean polity (in large part by dint of it being even possible in the first place).

Before language was invented the only way information could be passed down from ancestors to offspring was via mutations in our DNA.

Language (in the sense of "use of language appears around 100,000 years ago") is not the only way to communicate information, and many animal species are perfectly capable of communicating information despite not having evolved what is being called "language" in this sense.

The fundamental problem that most people want free software to solve isn't the user-level problem of "I want to tinker with all of the software I run," but the community-level problem of "I want to use the results of other people in getting software to run on my setup." In the context of a compiler, that's support for more esoteric architecture; in the context of a kernel, that's support for drivers for hardware.

The GPL doesn't actually solve the community-level problem very well (which is the basis of Linus's complaints about GPLv3--it positions the license much more directly in the direction of the user-level freedom rather than the community-level freedom). But the solution for the community-level problem involves a lot of social pressure, and it turns out that for a large open-source project, commit velocity means that most proprietary companies find the easiest way to deal with the open-source upstream is to contribute their code to the community to make it everybody else's problem to maintain.

You can see this in the development of LLVM, e.g.: almost all of the proprietary compilers are LLVM-based (especially as EDG has finally thrown in the towel, everyone using EDG is going to look to rebasing onto clang instead). And yet the companies with their proprietary forks of LLVM are still major upstream contributors.

You have a neighborhood with three dozen people in it

The average household size in the US is about 4. Three dozen people means 9 houses. That's not really a neighborhood, and most people don't live in that kind of low-density.

Picking a random cul-de-sac street somewhere in North Carolina (ended up being near Cary, NC), as representative of what a suburban/exurban density environment would look like, it has 22 houses on it by itself. Just guessing where I'd plop a bus stop on a collector road, there's 4 similarly-sized cul-de-sacs within walking distance, and a similar number of houses on the collector road. So that bus stop is going to have 100 houses it can service, or about 300-400-ish people.

One of the primary problems with transit discourse in the US is that people (on both sides!) tend to view transit as a Manhattan-or-Cimmaron-County density dichotomy, thinking that transit is unviable except in the highest density regions. But my point is that transit is absolutely viable at the density available in exurban, even a lot of "rural" regions (although that's rural more like Berkshires rural rather than Oklahoma rural). And because not a lot of people actually live in the lowest density regions where public transit is unviable... it doesn't actually matter: most people live some place where public transit is viable.

If you look at the "natural" disposition of the time zones, Chicago is very near the appropriate longitude (90 W) for the median of the time zone. The border between Eastern and Central time zone should be about halfway through Ohio; instead, the Eastern time zone is skewed westward, since Indiana, Ohio, and Michigan wanted to be in the same time zone as NYC.

Permanent DST sounds good to a lot of people, until they actually experience it. The US went on permanent DST in the 1970s and support plummeted after the first winter in DST (which is why we're not on it anymore). Of course, since it was 50 years ago, that means most people alive in the US don't remember the days of permanent DST.

The problem, I think, is that what a lot of people want is they want the sun to set quite late, like it does in summer time. But DST isn't going to give you those long summer afternoons in winter, because the sun just isn't up long enough; and the trade-off you'd make for maybe coming off work into the start of dusk is that dawn would start after you start working, which turns out to be pretty bad for your circadian rhythm.

Okay, so you travel from, say, Washington DC to NYC and then you have to set your clock back by... I think it's like 13 minutes?

Which is why railroads started instituting time zones in the late 19th century: because it turns out having to recalibrate your watch every hour or so is a recipe for creating train crashes. Railroad time didn't become standard time until the early 20th century, in large part because a lot of the smaller cities were pretty irate at having to adjust their clocks. (It also doesn't help that coincidentally, places like Chicago and New York City are very near the center meridian of their time zone).

Almost all of the new highway construction is for passenger cars. Yes, the interstate highways were built in part to facilitate intercity truck traffic, but the reason for building yet another beltway around, say, Houston isn't for trucks but for all of the passenger cars in the region that are congesting the roads.

I've been traveling around in Europe without a car for several days now, including several fairly rural areas.

There's a distinctly American trope in play, that if the bus or train doesn't stop more or less exactly at your destination, then it's going to be totally useless. Except, you look at the rural European countryside, and there is still a fairly reliable--and well-used, certainly not "only one rider on the bus"--bus system. And this is in the countryside that is less densely populated than most American suburbs or exurbs. It is totally possible to make mass transit work, even in the car-oriented hellscape of most American cities.

The main thing that American public transit systems seem to be really allergic to is the concept of frequency--a high frequency transit system is generally necessary for usability, but your typical American transit system responds to a perennial funding crisis by cutting frequency, which tends to lead into a ridership death spiral--cutting frequency cuts ridership, loss of ridership leads to loss of funding, which they respond to by cutting frequency.

The book of Joshua details the supposed conquest of Canaan by the Israelites, which archaeological evidence rather disfavors--there's no discontinuous horizon in cultural adaptation between the supposed Philistines and the Hebrews following Jewish dietary laws, for example, and the settlement sites just are not inhabited during the time period that they were supposedly conquested.

If we're being pedantic, investment income comes from a bunch of people who trade pieces of paper for a living deciding that a particular piece of paper is now worth $1 more today than yesterday. Well, okay, it's not paper anymore, just entries in some computer database in New Jersey or Delaware or something.

Investment income--in the form of capital gains--isn't coming from profits, it's coming from the mass delusion in the value of stock assets (which is somewhat correlated with profits, although the existence of stocks like SpaceX or Gamestop show the possible disconnects).

If you wanted to complain about the salaries of billionaires, or the stock grants on the other hand... but you said investment income!

My Chipotle meal cost $17 yesterday. It used to cost $8. [...] make my Chipotle meal $8 again or double my salary

I don't know what the date brackets are for your meal ranges there, but the largest component of the price increases in things like takeout meals over the past few years has in fact been wage increases for low-wage workers like the people making your Chipotle meal. In other words, it's more expensive because their salaries have doubled.

I mean, a virtual ISA (think PTX, LLVM IR, WASM) is going to do a better job of giving you an abstract machine than something like MMIX. Virtual registers and call arguments/return values as nary arguments rather than fixed registers give you most of what you want, and it's easy to augment it with a large slice of primitive operations that is a superset rather than subset of assembly languages.

(There's another criticism to level at pseudo-assembly language, which is that modern high-performance processors are superscalar with cache hierarchies, which makes the analysis of execution time itself difficult from the kind of first principles that Knuth is working at. I can appreciate why Knuth is working differently from the more traditional big-O notation of typical algorithms classes, but it does need to be acknowledged that it does sap the treatise of its supposedly timeless quality.)

Well, even as-is, it turns out that the kind of assembly language that Knuth originally wrote it in itself had a very short lifespan. MIX assumes a single accumulator register for arithmetic, which hasn't been a common processor architecture since around the 1980s. MMIX is redesigned to be more RISC, but it also uses a dynamic register window concept (which itself I think was only used on Itanium, and we all know how that architecture went down).

And unfortunately, for a lot of modern algorithms, you're going to have dive into SIMD-like algorithms, something MMIX doesn't have. Also, a lot of modern processors have a decent suite of bitwise operations (e.g., count leading/trailing zeros/ones, popcount) that is also missing from MMIX.

The programming languages that are in favor may change from decade to decade, but so to does most of the assembly language techniques.

Upward mobility still occurs in the US, at all levels. While the advice is difficult, almost impossible, for most to apply, it is sometimes applicable.

One of the main issues is that a lot of advice is presented as an unconditional, absolute guarantee to success. A college degree was never a guarantee of future success (contrary to great-grandparent's assertion), but the push to get everyone to get a college degree has rendered its utility as a helpful marker much more useless. Similarly, the ability to start your own business is difficult for most people, but even for poorer individuals, it is possible to start, say, a cleaning service with very little assets. (At the same time, such businesses are unlikely to make a whole lot of money at the end, but you might be able to move from working class to middle class, e.g.). A lot of contractor businesses--your plumbers and the like--are going to be from the lower middle class or middle class, and you can make some good money there, although that is also likely to be at the cost of your health much sooner than you expect.

People tend to rely on air temperatures when in reality the lethality of heat is probably more linked to the wet-bulb temperature.

The human body has a natural resting temperature of about 37°C, and metabolism of course generates more heat constantly, so we constantly have to shed that heat. When the temperature is low, we can rely purely on conducting the heat into the atmosphere to shed the heat (which is probably why internal body temperature is higher than the atmosphere!). At higher temperatures, conduction is less efficient, or sometimes even adds heat load into the system (at above 37°C, obviously), so we start relying on evaporative cooling (i.e., sweat) to cool us down.

The wet-bulb temperature is the minimum temperature that can be reached by evaporative cooling. So when the wet-bulb temperature is in the mid-30s °C… people start to become literally unable to regulate their core body temperature, and the heat is lethal. Wet-bulb is largely a combination of the temperature and humidity, but unfortunately, it's not typically reported in most weather reports, so people go off of the air temperature (and the humidity) that is reported.

Which is a long-winded way of saying "the humidity matters a lot for how much a given temperature is bearable." I don't know what environment you come from purely by rural New South Wales, but my first guess is the semi-arid and thus low-humidity bush regions of the state, which means the apparent wet-bulb temperature of 37-40°C would be a lot lower than the equivalent 37-40°C for most of the humid continental climates of Europe.

The author is comparing a 1990 hypothetical compiler to a 1970-ish compiler. The late 1960s and early 1970s are essentially when all of the foundational parser theory gets laid down. By the late 1970s, we're getting into autoparallelization and autovectorization research. Monotone dataflow analysis was developed in the 1970s as well. To be a little bit glib, basically what happened is compiler theory is really birthed starting in the 1970s; if you wanted to track down most of the techniques in the Dragon book, I suspect the vast majority of them originate in that timeframe.

There is a second shift that occurs around 2000-2005-ish, which is the transition of optimizing compilers from an instruction-based semantics to a more value-based semantics, in that modern optimizers make no real attempt or guarantee to preserve the structure of code. For example, an if statement may happily be converted into an expression lacking an if entirely.

The chief criticism lies in the "Greenspan put"--the idea that the Fed would just never let asset prices fall, a policy which both bears his name and is noteworthy enough to have a detailed Wikipedia article on it.

I disagree.

For all of Iran's supposed mastery of drone warfare, do note that the damage those drones have done to the US military is... essentially nil. No ships have been sunk; no aircraft have been lost. There have been some lives lost due to a drone attack on a facility troops were staying area, but at first read, I'm going to chalk that up more to the US military generally not planning for Iran to respond at all to a bombing raid rather than drones per se being particularly effective. Where the drones have been effective have been as a form of precision bombing--exactly the same kind of missions the US military has achieved with its regular air forces, albeit at a considerably greater distance from its homeland than any drone-based force has been able to achieve.

I think many people are way too quick to point to drone warfare as the obvious future of warfare, without considering the environment in which wars operate and how it might play out differently for different combatants. The US has a general assumption of complete and total air superiority in its conflicts--and the last time it didn't have that was over 70 years ago--and the number of countries that can meaningfully contest US air superiority is unknown but very few. The lessons of the Russo-Ukrainian War--a conflict where neither side has air superiority--are thus somewhat limited for a US conflict against most of its enemies. (Although I do agree that the US military is too sanguine about not learning from the Russo-Ukrainian War).

The US military executed nearly flawlessly

The US military exhibited numerous flaws. To cover numerous flaws not yet covered by other replies:

* Required the deployment of assets beyond their useful operational capability (which caused the aircraft carrier to catch fire).

* Demonstrated that their targeting list is not only based on outdated information, but failed to update that information when informed it was outdated (which led to the bombing of the elementary school).

* Failed to anticipate literally the one military contingency everyone expected Iran to do--close the strait. Hell, even after it was clear that was happened and everyone was screaming "what are you going to do about it?" the answer was, shockingly "absolutely nothing."

* Failed to adequately secure supply lines to ensure that military units in the area have sufficient food. This is literally logistics 101 stuff.

* Defined operational success criteria not based on results achieved but on effort spent--in other words, how many bombs you launched rather than whether or not the targets you wanted destroyed were destroyed.

* Definitely several C2 issues we're not entirely privy to, given the midair collision that cost a tanker, and the loss of an AWACS unit.

The strategic issues are even more myriad, but since strategy is supposed to be largely a civilian, not military, decision, it's not really the military's fault. Except I will note that a lot of civilians in this field do come from ex-military background, and there does seem to be a major recurring problem that CENTCOM is producing a lot of people with really bad strategic judgement that is partially responsible for this debacle in the first place. Really to the point that we should consider blackballing everyone from CENTCOM from ever having a military or civilian defense job of importance ever again.

An integer add, sub, or shift is 1 cycle of latency; integer mul is generally 3 cycles; integer div is lol-that-is-slow. Floating-point adds, subs, muls, and fmas are generally 4 cycles, with div being lol-that-is-slow (but generally faster than integer division because your divisor and dividend have fewer bits).

So fixed-point addition and subtraction are definitely faster, multiplication is a wash if you're doing binary-based fixed point (but slower if you're doing decimal-based fixed point), and fixed-point division is definitely slower than floating-point division.

The TraceMonkey paper was on my qual reading list, and my quals happened to be around the time TraceMonkey was ripped out of SpiderMonkey. I was talking with one of the developers at the time (I think it was Jason Orendorff?), who said that tracing just doesn't work out, but there was limited circumstances where he thought it might work out... but I've completely forgotten what those circumstances were.

Well, course numbers are regular enough that you can look up what the "intro compilers" course is: https://www.cs.cornell.edu/courses/cs4120/2026sp/?schedule

The short answer is that compilers is basically broken up into two courses, with the first course largely being the minimum necessary to build a compiler (lexing, parsing, codegen, register allocation), and the second course being how to build an optimizing compiler.

So far as I'm aware, we don't know that inference for free users is counted as cost of revenue as opposed to sales and marketing.

With sales and marketing at 5.7b, which seems unusually high compared to cost of revenue, I think it's deeply irresponsible to ignore that when considering how profitable OpenAI may be. Even taking a charitable interpretation, OpenAI is having to spend considerable budget (more than their gross profit!) to keep people paying for using their services. The less charitable interpretation is that they're deeply unprofitable and they're pulling every legal accounting trick to hide the sources of unprofitability.

People have been saying that self-driving cars are so imminent that we don't need to bother making any improvements to public transit for... at least 10 years, probably closer to 15 years at this point. It's still too premature to shape your entire land use planning around still largely theoretical predictions of how the technology could evolve.

In the US, when you start to get to planning to have a larger family, especially the size of family that would necessitate 4 bedrooms (multiple children, or maybe having a parent live with you), most people expect to move out of an apartment building into a house anyways (maybe detached single-family home, maybe duplex, maybe condo). So there's just not the demand for 4-bedroom apartments or even 3-bedroom apartments to a large degree.