I think GP is pointing out a legitimate asymmetry between the "two sides": there's one* way for a conservative to do things the way they've always been done, and there's an infinite* number of ways for a progressive to change things to do something different, for better or for worse. The Paradox of Choice affects one side much, much more than the other.
It's not "8-wide", it's "512-bits wide". The basic "foundation" profile supports splitting up those bits into 8 qword, 16 dword, etc. while other profiles support finer granularity up to 64 bytes. Plus you get more registers, new instructions, and so on.
Not OP but for me it's not about what sources to trust (blindly? literally none of them), but what type of information you can trust. Naked facts seem to be safe for the time being, context should be assumed to be heavily biased in a particular direction, and opinions are worse than worthless.
Slight tangent: does anybody know how these models are tuned to censor certain topics so precisely? I thought it was a bit of a black box how things worked internally?
I was thinking about this last week[1] and I think that both the "math" people and "common sense" people are correct in a sense, and talking past each other. The math people are of course mathematically correct within the limits of the constructed model, given all the assumptions of perfectly random sampling, no systemic error, etc. Meanwhile common sense people are correct in a practical sense: small samples are vulnerable to sampling error, p-hacking, outright fraud, etc. Even before you're aware of the exact mechanisms by which things can go wrong you intuitively know that small/cheap studies are more vulnerable to some kind of honest human error or dishonest... shenanigans.
---
[1] I was listening to a podcast where trolley problems were brought up and the speaker was lamenting how clearly "unethical" and "irrational" your evolved intuition is given that most people will let the train hit 10 men working on the tracks than to divert it and kill 1 innocent. Trolley problems are intellectually interesting for various reasons but jumping to that conclusion is clearly absurd. Your intuitions are shaped by millions of years of genetic and social evolution to precisely be most rational for actual real-life problems. If you were actually standing at that switch you'd be thinking...
* do I actually trust my eyes in this situation? Are the workers on a parallel track and there's no actual problem here?
* if I pull the switch, will it derail the train and kill N+1 people instead of the 10.
* will the workers just notice the train in time and scurry off the track? Or will the train just stop? How good are brakes on a train anyway?
* how much time do judges and juries spend solving trolley problems?
... and while you were paralyzed thinking about these and a million other things, whatever was about to happen would happen and there would be no trolley problem.
I think the points he makes in the article actually perfectly match the "broscience" in powerlifting and olympic weightlifting. There it's all about long rest between sets, low reps, tracking weekly pounds lifted, hitting the same muscles many times per week, etc. I was nodding along at everything thinking "this is obvious isn't it" and had to remind myself he's writing about a different field.
My understanding is that Planck Length is not a limit to the smallest possible thing; it's a limit to the most precise possible measurement. So there could in fact be lots of things happening at sub-Planck Length scales, but we could never observe them.
If you ever end up doing this project, I find that sometimes it's hard to quantify if something is better when going in the normal-to-better direction, but it's always much easier to tell when something is worse when going in the normal-to-worse direction. So spend a few days or weeks getting totally acclimated to fast response times and then test if you can notice the difference with slow response times.
I'd be surprised if it didn't support ECC; every gen since Ryzen 2000 has supported ECC (although it's unadvertised and you have to be very careful with motherboard selection). I currently have proper ECC running on a 3000 series Ryzen with an AsRock motherboard.
> If you know the kid next door is being abused - and you do nothing about it, you are partially at fault for the violence happening to the kid.
You're doing something bad in this hypothetical scenario, but it's not violence. Maybe it's "accessory to violence" or "willful ignorance" or some other immoral or illegal thing that you should be jailed for, but it's not literally "violence". Blurring this distinction is dangerous; people will start using actual violence against figurative "violence" in a kind of aggressive "self-defense".
> but the fact that there are so many categories for east Asian... says volumes about the sexualizing gaze cast on Asian women
I think you're reading too much intent into 4 labels. From an American perspective, Japanese was the original--commercial, censored--"Asian" porn, "Chinese" is typically amateur uncensored, etc. I... won't elaborate further here, but there are stylistic differences that have nothing to do with race.
You yourself are hypocritically writing in a direct, laconic style while advising Felipe to politely tip toe around sensitivity issues. Why aren't you yourself trying to "empathize" with Felipe and whatever culture he's from?
To be clear, I obviously like direct communication. I'm just pointing out the hypocrisy of this comment chain.
I would bet good money that distrust from every ethnic group to every other ethnic group is rising due to identity politics making this a salient attribute in every discussion.
> If a game is rendering at 60fps, the combined compute time for simulation+rendering should be 16.6 ms.
It can work this way--e.g. nvidia exposes an 'ultra low latency mode' in their driver that caps prerendered frames to zero--but typically for smoother animation and higher average fps gpus will have a queue of several frames that they're working on, and this is irrespective of how many render targets you have in your swapchain. Danluu's breakdown above is actually correct for the typical case.
---
Thought I'd clarify how this works since there's lots of confusion in this thread. In the early days you would directly write pixels to memory and they'd be picked up by a RAMDAC and beamed out to the screen. So if you wanted to invert the color of the bottom right pixel it would take at most two frames or 33ms of latency if you were running at 60fps double buffered: first you set your pixel in the back buffer, wait up to 16.66ms to finish drawing the current front buffer, flip buffers, wait 16.65ms for the electron gun to make its way down to the bottom right corner, and then finally draw the inverted pixel.
With modern gpu's, the situation is very similar to sending commands to a networked computer somewhere far away. You have a bit of two-way negotiation at the beginning to allocate gpu memory, upload textures/geometry/shaders, etc., and then you have a mostly one-way stream of commands. The gpu driver can queue these commands to an arbitrary depth, regardless of your vsync settings, double/triple buffering, etc, and is actually free to work on things out of order. You have to explicitly mark dependencies and a 'present' call isn't intrinsically tied to when that buffer will actually end up displayed on screen. So there's no actual upper bound on latency here; even at 360hz if the gpu is perpetually 10 frames behind the cpu, each frame only takes 2.77ms to simulate and 2.77ms to render but the overall input lag could still be ~30ms. (In practice though, drivers will typically only render 2-3 frames ahead.)