atq2119

The RSI thing is real. Until my late 20s I would type blindly with what I jokingly called 5 and a half fingers. But I did start to notice some strain, which is when I decided to finally teach myself "proper" touch typing. I don't think my typing got meaningfully faster, but it got smoother, and the strain went away.

Maybe it takes less than 2 hours to add such a configuration knob?

This is one those cases of "why not both"?

I totally agree that we need technical solutions. We have no hope without them. But it's also naive to think that endless growth without lifestyle changes is possible.

That said, if you really think about it, the most important lifestyle change of all is happening, and quite dramatically so: People are having fewer children.

Note that 14nm processes (which are quite old by now) are not the same as 14nm feature sizes. I'm not sure what these machines are capable of, since some details may well be lost in translation in this kind of publication. And I'm only an interested enthusiast, I don't work in the field directly.

But towards the end of the article they talk of targeting 8nm line width in 2028, which is impressive. Maybe this time around NIL actually becomes real for high-end processes?

"Nobody", really?

As a bare minimum, many people can choose to take more environmentally friendly vacations. You don't have to go on a cruise, and yet that's a booming industry. You don't have to fly across an ocean. Almost everybody who does these things has the option to go on perfectly fine, perhaps even better, less carbon intensive alternative vacations.

And yes, there are people who consciously make that lifestyle change. Not enough, of course. But only a Sith deals in absolutes.

Not in relative terms, which is what people usually measure. And yes, the gap has been increasing in relative terms.

And I wonder what's behind that rhetoric twist in your second sentence. Was that on purpose or do you not even notice?

Because no, somebody creating more wealth than me does not hurt me by itself (I might even benefit!). Somebody accumulating and being able to command more wealth than me can hurt me, among other reasons because it gives them political power, which they can wield to hurt me and others. Inequal wealth accumulation taken to its logical extreme is undemocratic because it violates the principle of one person one vote.

(Some wealth accumulation is okay. There's room for nuance here.)

Your optimism about how secure network-connected devices are against e.g. being added to a bot net in the status quo seems misplaced.

I agree with your concern not just for the future but for today. Something like TPMs could help attest that that example TV is running the software you think it is.

Of course, that would require manufacturers to care about security for their customers, which they currently don't. And the average person doesn't care enough, so the only way to change this is legislation/regulation.

The solution is to make summary statistics available to the public but no names.

Just publicize that there have been 471 citations for rollerblading without listing the names of those affected.

To expand on this a bit, the hypothesis stated elsewhere is that the register renamer stores "physical register + 11-bit signed immediate".

It should be possible to construct scenarios where a logical register is mapped to "physical register + immediate" where the immediate depends on the path taken through the program so far. The easiest example would be an if-statement that optionally adds 1023 to a register, and then an add of 1 after the if-statement. The add of 1 overflows the immediate stored in the register renamer if and only if the if-condition was true.

As you said, that requires taking different control flow paths through the program, which is something to be avoided by constant-time algorithms anyway.

One potential twist: This shows that it may be important that the interface between the constant-time algorithm and the rest of the program goes entirely through memory and not through registers. If the interface does go through registers, it's possible that variable register-renamer-immediates leak from the outside world into the constant-time algorithm. (This admittedly feels like a bit of a stretch, but who knows.)

I don't know about "too rich", but if you're looking at the distribution of income and wealth, you'll find an increasing divide between poor and rich over the last decades in pretty much all western countries at least.

Societies have made the poor better off by preventing people from becoming too wealthy, though. Specifically, I'm thinking of the very high high-end tax rates that were common 60 years ago.

> I'm curious to learn what they did differently.

Being 20 years later than the original version of that article.

Silicon process improvements since then have been wild.

VLIW means Very Large Instruction Word. It is a property of the instruction set, not of the processor that implements it.

You could have a VLIW ISA that is implemented by a processor that "unrolls" each instruction word and mostly executes the constituent instructions serially.

Re Wayland: Regardless of whether you use Xlib or XCB, your application will use the X protocol, which means it won't run natively on a Wayland desktop but only via Xwayland. Real GUI toolkits nowadays have separate backends for X and Wayland, defaulting to the Wayland backend when run on a Wayland desktop. So while XCB is better than Xlib, you really shouldn't use either.

Re offscreen rendering: This is orthogonal to double buffering but refers to the way modern compositing desktops (including Wayland) work. The application renders the window image into an offscreen surface which is then handed off to the compositor, which blits it to the screen.

Re GPU rendering: You can draw rectangles on a surface on the CPU by simply setting pixel color values in a loop, or you can draw them on the GPU by sending a list of rectangles and have the GPU do the rasterization of the rectangles. Toolkits like Qt or Gtk can do both, depending on the backend that is selected, and will typically default to GPU rendering on modern desktops.

Another helpful tool that should be mentioned in this context is the idea of merge trains, where a thorough test run is amortized over many commits (that should each have first received lighter selective testing).

This doesn't necessarily reduce the latency until a commit lands, though it might by reducing the overall load on the testing infrastructure. But it ensures that all commits ultimately get the same test coverage with less redundant test expense.

That avoids the problem where a change in component A can accidentally break a test that is only tested on changes to component B.

(It also eliminates regressions that occur when two changes land that have a semantic conflict that wasn't detected because there was no textual conflict and the changes were only tested independently.)

> To make matters worse if your project grows so large that your hypothetical tests take over an hour to run, it sounds like the project would already be broken down into modules.

Story time so that you can revisit your assumptions.

Imagine your product is a graphics driver. Graphics APIs have extensive test suites with millions of individual tests. Running them serially typically takes many hours, depending on the target hardware.

But over the years you invariably also run across bugs exposed by real applications that the conformance suites don't catch. So, you also accumulate additional tests, some of them distilled versions of those triggers, some of them captured frames with known good "golden" output pictures. Those add further to the test runtime.

Then, mostly due to performance pressures, there are many options that can affect the precise details of how the driver runs. Many of them are heuristics auto-tuned, but the conformance suite is unlikely to hit all the heuristic cases, so really you should also run all your tests with overrides for the heuristic. Now you have a combinatorial explosion that means the space of tests you really ought to run is at least in the quadrillions.

It's simply infeasible to run all tests on every PR, so what tends to happen in practice is that a manually curated subset of tests is run on every commit, and then more thorough testing happens on various asynchronous schedules (e.g. on release branches, daily on the development branch).

I'm not convinced that the article is the solution, but it could be part of one. New ideas in this space are certainly welcome.

Props to you for making a cool little project, but as somebody who's been involved in Linux graphics a bit: please just let Xlib die. It's an outdated API, even if you ignore the existence of Wayland. For something like fast visualizations, you should really go with something that does offscreen rendering and then blits the result. As long as you're just drawing a bunch of rectangles, even CPU software rendering may be the better solution, though obviously modern tools should use GPU rendering.

I see your journey and how you ended up with Xlib. But I think that's really more of an indictment of the sorry state of GUI in Rust.

I know that's not your job, I just couldn't let this use of Xlib stand uncommented because it's really bad for the larger ecosystem.

> 60% of gen Z men are single, 30% women

I always do a double take when I read such statistics. How can they possibly add up? Are gen Z men considered particularly undesirable leading to lots of relationships with large age gaps? Is there a ridiculously large overhang of gay women (over men)? Is there a huge number of men with multiple partners?

These gender disparities are difficult enough to believe when they come to sexual relations, it gets even harder when talking about relationships.

I guess what I'm saying is: I don't believe those numbers as stated and would be interested in an explanation or at least a source.

You make it sound like that's a sure thing, but I doubt it. A lot of this is about processes, team structures and incentives, all those fuzzy things between the people.

Remember, most acquisitions fail. For the same reason, the likelihood of failure with your scenario seems high.

Do you really think nobody at AMD is aware of all the points made in this thread? That seems too bizarre to be true. There are probably some issues in upper management which could perhaps be fixed with some targeted hiring decisions, but do you really believe some random person on here would have a chance making that call?

The size of company you work in doesn't matter beyond a certain fairly small size. The only way anybody could work with hundreds of people at all (and have a justified informed opinion about them) is to have a long career in a place or places with very high turnover.

Professors might hit those numbers because having informed opinions about their students is a large part of their job and they see large turnover by definition. Directors could have a chance, but even there I'd say hundreds is actually unusual, unless your standards for quality of opinion are low.

And then that's all people, not just H1-B holders.

Paul Graham is a major Lisp advocate, attributing a non-trivial part of his own early success to it.

So there are all those good reasons for it, but it's still a little weird.

The point is that the C standard does guarantee that the function returns 1 if the program is a valid C program - which means there is no UB.

For example: If the oracle function returns an invalid pointer, then dereferencing that pointer is UB, and therefore the program isn't a valid C program.

As a layperson with a math background who has dabbled in quantum computing, I agree.

It would help to call the "Everettian" interpretation by the original title given by Everett: the theory of the universal wave function.

Ignore the techno-babble about the multiverse. The way I understand Everett is simply as taking the math literally and seriously to its logical conclusion.

Moving across Europe may be harder than moving across the US. But moving across Europe (at least the EU) today is much easier than it was 40 years ago, pre-EU.

The 3rd step can flush out compiler bugs, as follows.

The 1st step uses gcc, so it's not going to find any bugs in this compiler.

The 2nd step uses the compiler as compiled by gcc. That will find some bugs, such as crash bugs or missing features (like your for loop example). However, it does not find bugs that lead to generating incorrect code.

The 3rd step uses the compiler compiled by itself. If there is a bug in code generation that led to the stage-2 compiler being compiled incorrectly, that is likely to lead to some error during stage-3 compilation, such as a crash. And if it doesn't crash outright, it is very likely to cause the resulting executable to differ between steps 2 and 3. The incorrectly compiled compiler is surely even worse at compiling correctly than the compiler that was presumably compiled correctly (using gcc)!

So, this 3-step process is a pretty good way of finding bugs, especially if you compare the stage-2 result against the stage-3 result.

The full bootstrapping process starts with entering instructions in binary (or hex or octal) to build an assembler in the first place :)

ARM does not inherently have "massively lower power consumption and waste heat", though.

Market forces have traditionally pushed Intel and AMD to design their chips for a less efficient part of the frequency/power curve than ARM vendors. That changed a few years ago, and you can already see the results in x86 chips becoming more efficient.

And by "are generally switching" you're really trying to say "generally switched a decade ago".

Judging from the diagrams, the loop buffer is using the same storage as the micro-op queue that's there anyway. If that is accurate (and it does seem plausible), then the area cost is just some additional control logic. I suspect the most expensive part is detecting a loop in the first place, but that's probably quite small compared to the size of the queue.

Open market operations are the mechanism by which the interest rate is controlled.

Basically, the central bank sets an interest rate target and then performs open market operations until the interest rate matches the target.

That obviously affects the quantity, but the point is that the target is the interest rate. The quantity just ends up being whatever happens to be necessary to hit the interest rate.