Maybe never with current technology? Looking just at the CPU and assuming you need comfortable IPC overhead for emulation, the 386 was from early in the Dennard scaling era and modern CPUs are 1000x or more faster single-thread. Since maybe 2012 that hasn't moved anywhere near that, certainly less than 10x.
For the GPU things are potentially looking better! But since distributed shaders/kernels are higher-level compiled for your specific device, there's less of a need for emulation.
I agree that drivers should know not to reverse on a highway regardless of local signage.
But in situations that could be ambiguous, I think this is a regional difference - the US, Australia, part of the rest of the Americas use lots of text on road signs (including literal "wrong way" signs); Europe and much of the rest of the world use far less text (including purely pictographic "wrong way" signs). Especially important in Europe where drivers just can't learn 20+ languages.
I really want to like QBE, but declaration blocks like this make it feel like 1970s Unix code more than a modern hackable piece of software:
int t, x, r, rf, rt, nr;
bits rs;
Ins *i, *i1;
Mem *m;
Ref *ra[4];
I think it deters some users by making it hard to read and understand the relatively subtle code in the 300 line function that follows. (Skill issue, I know)
Yeah, I tried my hand at adding amd64_win support to QBE, but going through the very dense code was a slog. I kept refactoring and commenting it just to make heads or tails of it, but ultimately realized I would never be able to minify it back to something upstreamable. I applaud Scott Graham's perseverance and tenacity.
Quentin took pity on me and let me upstream amd64_win with my lengthy variable names and including chatty comments. :)
SysV and Win x64 differ enough that the Windows code is mostly unrelated to/detached from the other backends, so it doesn't feel (too) awful for it to have its own idiosyncratic style.
I tried to look at the QBE code years ago while I was writing my own SSA code. I got approximately nowhere because I can't read code like that. Turns out that reading the SSA papers and writing the code was a lot easier than reading QBE.
Yeah that looks like they've prioritised code golfing a bit too much over code quality. Also using AT&T assembly syntax shows poor taste. Definitely 80s themed software.
It is hard for me to fully trust a compiler backend that isn't self hosted. There is a discipline that self hosting imposes that would both improve the quality of their ir as well as the backend itself. A self hosted backend can always be updated to have performance meeting or exceeding the best that llvm or any other backend can offer.
Carmack gives updating in a loop as the one exception:
> You should strive to never reassign or update a variable outside of true iterative calculations in loops.
If you want a completely immutable setup for this, you'd likely have to use a recursive function. This pattern is well supported and optimized in immutable languages like the ML family, but is not super practical in a standard imperative language. Something like
def sum(l):
if not l: return 0
return l[0] + sum(l[1:])
Of course this is also mostly insensitive to ordering guarantees (the compiler would be fine with the last line being `return l[-1] + sum(l[:-1])`), but immutability can remain useful in cases like this to ensure no concurrent mutation of a given object, for instance.
You don't have to use recursion, that is, you don't need language support for it. Having first class (named) functions is enough.
For example you can modify sum such that it doesn't depend on itself, but it depends on a function, which it will receive as argument (and it will be itself).
While your example of `sum` is a nice, pure function, it'll unfortunately blow up in python on even moderately sized inputs (we're talking thousands of elements, not millions) due to lack of tail calls in Python (currently) and the restrictions on recursion depth. The CPython interpreter as of 3.14 [0] is now capable of using tail calls in the interpreter itself, but it's not yet in Python, proper.
Yeah, to actually use tail-recursive patterns (except for known-to-be-sharply-constrained problems) in Python (or, at least, CPython), you need to use a library like `tco`, because of the implementation limits. Of course the many common recursive patterns can be cast as map, filter, or reduce operations, and all three of those are available as functions in Python's core (the first two) or stdlib (reduce).
Updating one or more variables in a loop naturally maps to reduce with the updated variable(s) being (in the case of more than one being fields of) the accumulator object.
> It's all fun and games until you realise you can't run a consumer economy without consumers.
If the issue is that the AI can't code, then yes you shouldn't replace the programmers: not because they're good consumers, just because you still need programmers.
But if the AI can replace programmers, then it's strange to argue that programmers should still get employed just so they can get money to consume, even though they're obsolete. You seem to be arguing that jobs should never be eliminated due to technical advances, because that's removing a consumer from the market?
The natural conclusion I see is dropping the delusion that every human must work to live. If automation progresses to a point that machines and AI can do 99% of useful work, there's an argument to be made for letting humanity finally stop toiling, and letting the perhaps 10% of people who really want to do the work do the work.
The idea that "everybody must work" keeps harmful industries alive in the name of jobs. It keeps bullshit jobs alive in the name of jobs. It is a drain on progress, efficiency, and the economy as a whole. There are a ton of jobs that we'd be better off just paying everybody in them the same amount of money to simply not do them.
The problem is that such a conclusion is not stable
We could decide this one minute, and the next minute it will be UN-decided
There is no "global world order", no global authority -- it is a shifting balance of power
---
A more likely situation is that the things AI can't do will increase in value.
Put another way, the COMPLEMENTS to AI will increase in value.
One big example is things that exist in the physical world -- construction, repair, in-person service like restaurants and hotels, live events like sports and music (see all the ticket prices going up), mining and drilling, electric power, building data centers, manufacturing, etc.
Take self-driving cars vs. LLMs.
The thing people were surprised by is that the self-driving hype came first, and died first -- likely because it requires near perfect reliability in the physical world. AI isn't good at that
LLMs came later, but had more commercial appeal, because they don't have to deal with the physical world, or be reliable
So there are are still going to many domains of WORK that AI can't touch. But it just may not be the things that you or I are good at :)
---
The world changes -- there is never going to be some final decision of "humans don't have to work"
Work will still need to be done -- just different kinds of work. I would say that a lot of knowledge work is in the form of "bullshit jobs" [1]
In fact a reliable test of a "bullshit job" might be how much of it can be done by an LLM
So it might be time for the money and reward to shift back to people who accomplish things in the physical world!
Or maybe even the social world. I imagine that in-person sales will become more valuable too. The more people converse with LLMs, I think the more they will cherish the experience of conversing with a real person! Even if it's a sales call lol
To say that self driving cars (a decade later with several real products rolling out) has the same, or lesser, commercial appeal than LLMs now (a year/two in, with mostly VC hype) is a bit incorrect.
Early on in AV cycles there was enormous hype for AVs, akin to LLMs. We thought truck drivers were done for. We thought accidents were a thing of the past. It kicked off a similar panic among tangential fields. Small AV startups were everywhere, and folks were selling their company to go start a new one then sell that company for enormous wealth gains. Yet 5 years later none of the "level 5" promises they made were coming true.
In hindsight, as you say, it was obvious. But it sure tarnished the CEO prediction record a bit, don't you think? It's just hard to believe that this time is different.
I would much rather work than not work. Many other people are the same. If I don't have a job, I will work on my free time. I enjoy it. I don't have to work for a living, but I have to work to be alive.
There are many people like me, and we will be the ones to work. It won't be choosing who has to work, it will be who chooses that they want to work.
It's our only conclusion unless/until countries start implementing UBI or similar forms of post scarcity services. And it's not you or me that's fighting against that future.
Looking at the source, it seems pretty easy to find Java programs that wouldn't compile correctly, but of course a fully general Java to C++ converter would be a huge undertaking. I guess with OK test coverage of the generated C++ code (which Firefox certainly has), editing the Java code remains doable.
Some laws are much easier to evade than others, and some laws have especially bad side effects when evaded. (A law about e.g. requiring a certain type of government certification before a large construction project can be undertaken, for instance, would be far harder to evade than this one, and "they can just do <x>" would probably be a bad objection)
Using non mainstream sites instead seems like a realistic way people are going to skirt this law, and those are very hard to regulate without other unpleasant side effects on Internet freedom. I think it's a reasonable concern to raise.
You can do high density without block housing! Many European cities are good examples of this. Paris, for instance, has very high density because it's packed with mid-rise (~7-8 floors) buildings[1]. Another good example is the section of Manhattan between Midtown and Lower Manhattan, which is also primarily mid-rise and very dense.
Apart from that I do think it's true that block housing separated by large parks (as shown in your picture) doesn't work well; it's discussed in e.g. Jacob's _The Death and Life of Great American Cities_.
I agree re: European examples but my argument there is many of these cities developed over long time periods with stable growth in population, stable industry etc, whereas now it seems like the idea is to simply explode urban housing capacity asap, which leads to the block style or high rise glass and steel.
and of course we can't forget that many places are at an inflection point in population growth so all of this capacity could be vacant in 15-20 years.
The issue is that people want to explode housing capacity ASAP in relatively limited geographic areas within cities. If mid rise was actually broadly incentivized, it wouldn’t be that challenging to rapidly increase that stock.
Strong towns [0] advocates a more bottom up approach to development, and is a good resource for anyone interested in how to add density in a sane manner.
How do you properly forecast housing need so your development curve (and the foundational urban planning necessary) aligns with the housing demand curve while keeping said housing affordable?
The CCP seems to have been very successful with their "build an entire city and move people into it model" (seeing the cities have filled), but I'm unsure how it works in a more capitalistic model.
Even mid-rise is kind of bad. You tend to share walls with a few neighbours still and there's no opportunity for any private garden space. It's not great for pet ownership, either. I'm not convinced it's a lot better than high rise/block housing as a space to actually live in. I say this presently living in a mid-rise in the UK. Edit: I should probably add that the leasehold system in the UK makes them a particularly bad proposition if you want to actually own your home as well.
Terraced housing has kind of okay density, at least it's not a total land crime like US suburban detached housing but affords many of the freedoms associated with it.
Figure 6 in "A New Golden Age for Computer Architecture" is a good representation of that effect: https://dl.acm.org/doi/epdf/10.1145/3282307.
For the GPU things are potentially looking better! But since distributed shaders/kernels are higher-level compiled for your specific device, there's less of a need for emulation.
reply