4,058 karma · joined September 12, 2018
On the one hand, this is a great situation to be in for Nvidia in terms of overall revenue.
On the other hand, this has allowed AMD to grab market share with the RX 9000 series launch, at least in the short term. So the narrow point that Geforce is sold out is decidedly not a flex.
This is incorrect for AMD, which has "s_waitcnt" instructions in its ISA, which is publicly documented. I believe it is also incorrect for Nvidia, but don't have the receipts to prove it.
I'm not saying that what you claim is entirely impossible, but it would require some major inventions and a very different approach to how ML is implemented and used compared to what's happening today. And I'm not convinced that the economics for that are there.
The Pentium multiplier isn't 3 bits per cycles, it's one full multiplication per cycle (though pipelined over multiple cycles).
The part that's 3 bits is the Booth multiplier trick of multiplying 3-bit digits instead of 1-bit digits, but they're all multiplied in parallel.
As such, I suspect (but don't know) that this trick or some variant of it is used even today.
The man clearly has many deserved achievements to his name, but that is true without this, and I'm confident the world would be better without this kind of statement.
"A multi-core CPU" isn't much of an invention per se. It's an idea -- one that is fairly obvious and trivial at a certain point of semiconductor history. Getting a multi-core CPU to run is not trivial, but it's not a single invention either, and by the time we got there, development teams were so large that it would be downright insulting to claim that one person solved all these problems by himself. Perhaps Kogge led the development of the first multi-core CPU, perhaps he was even visionary in the sense that he pushed for it before others thought it was feasible (I do not know if that is the case). But either way, he didn't invent it.
And I assure you GPUs do have challenges with that as well. That's just less well known because (1) in GPUs, all workloads are vector workloads, and so there was never a stark contrast between scalar and vector regimes like in Intel's AVX-512 implementation and (2) GPU performance characteristics are in general less broadly known.
That's one aspect of retirement systems that has always concerned me. Sure, it's neat to give people the control over retirement that comes with investing in an open market. But contrast this to public retirement systems where you pay in and the money is used to pay out retirement (of other people) immediately. Ultimately, both systems have to be sustained by a real economy that can provide the goods and services that folks require during retirement. But one of them puts a large amount of assets into the hands of unelected money managers, which is surely a potential source of instability.
A team that develops a user interface benefits more from "generic" cultural diversity (gender, ethnicity, social class, etc.) than a team that builds a processor microarchitecture.
But the latter team can still benefit from diversity: if it's all EEs, they'll probably do worse than a team that also has a mathematician, a physicist, a chemical engineer, a finance person, etc on it.
On the other hand, the processor team's communication might be smoother with an all EE team of high "generic" diversity than it would be with all white guys but from very different academic backgrounds.
If you have decent retention, the team will develop its own communication style anyway, so I suspect this factor doesn't matter as much.
Contrast this to people who are good at producing the appearance of an upstanding character when it suits them, but being quite vindictive and poisonous behind closed doors when it doesn't.
The neat thing about xoring with a number is simply that that operation is its own inverse.
I think what you want is to force the "initial exec" model using an attribute to get the more efficient code.
IIRC this (or something equivalent) is what libGL does because basically every OpenGL function call needs to read the thread-local variable holding the current GL context.
The downside is that dlopen()ing your library may fail.
I believe this as well, but it still baffles me. Don't people have a sense that things can always get worse?
The first part of this plan - destruction - is easier than the second half - creation. If they're successful with the second half, people will be worse off because it's a big step towards neofeudalism /strengthening oligarchy. If they fail, people will be a lot worse off because the structures they're destroying are actually doing important work.
There's this idea that sharing in illegal or socially shunned activities is an effective way to establish strong personal ties, and strong personal ties can in turn help advance careers.
Which is why there were a lot of successful secretely gay people in politics even in the 19th century.
As homosexuality became accepted, there was a shift to "harder stuff" playing this role. Not by literally the same people, mind you, but over time the composition of who's powerful shifts towards people who engage in shunned activities to form their strong personal ties. And as more activities become socially accepted, the activities that are shunned and give people a leg up become increasingly worse.
I don't like this conclusion, but it's the strongest potential argument against social liberalism that I know of.
If anything can be taken home from this article, it's that perhaps desktop environments need to do a better job helping users to understand disk utilisation.
The article's own recommendation would just make things worse. Application authors should stick to XDG standard directories.
Many projects have fairly strict rules about identifier naming conventions, so this doesn't feel so far fetched to me.
The example about if/else vs ? : is pretty damning though.
The only potential problem here is that "we owe ourselves" simplifies things given that some individuals are owed much more than others, i.e. there's inequality. Other than that? The whole debt charade is just political groups weaponizing (and perpetuating) the lack of fairly basic macro-economic understanding in the population.
Snark aside, I am somebody who is very concerned about edge cases, but those ratios seem completely wrong to me for the kind of code I write. And perhaps one should say "corner cases" instead of "error cases". Corner cases aren't necessarily errors. What I find is that a good algorithm that is properly "in tune" with the problem space will often implicitly handle corner cases correctly. While an algorithm that was hacked together by somebody who is "coding to the test" without really understanding the problem space tends to not handle corner cases, and then the developer tries to handle them by adding if-statements to patch their handling.
In the end, devoting 70% or 80% of thinking time to corner cases seems entirely plausible to me. 70% or 80% of lines of code dedicated to corner cases may be a smell.
However, they will be looking to figure out who they can rely on for technical expertise, so there's an opportunity there.