Somewhere in the docs they state that they must also recreate whatever bugs the API has, otherwise applications written with those bugs as an (implicit) assumption could misbehave.
its worse than that, Windows activates/deactivates "bugs" based on the compatibility profile of the app.
so you can set an app to use a Windows XP compatibility profile, and this will simulate Windows bugs which were fixed in more recent versions of the OS
Wow, I have no idea how accurate it is, NFL is not in my country, but google says there is about 11-16 minutes of actual play??
Commercials, 45 – 60 mins
"Standing Around" & Stoppages, 65 – 75 mins
The Halftime Show, 25 – 30 mins
Replays & Commentary, 15 – 20 mins
Actual Football Action - The ball is live and in play, 11 – 16 mins
versus what it says about AFL,
Actual Football Action - The ball is live and in play, 80 mins
"Time-Off" Stoppages, 30 – 40 mins
Commercials, ~15 mins
Scheduled Breaks, 32 mins
Wonder how that effects the social dynamic of watching games, I imagine you have more time to "shoot the breeze" during an NFL game. It's also not apples to apples comparison as my understanding of NFL is that it's probably shorter but more packed intervals, setup -> crunch, setup -> crunch. AFL can have a bit of back and forth to it maybe.
Also this says nothing of on-ground and around-ground ads which I always found depressing, which I guess must exist in all sports.
A game is 60 minutes, broken into 15 minute quarters. The play starts, the clock starts. The televised game is almost 3x that, but at least most of that is actually part of the game flow. Each play is basically a 15 second sprint.
The stat you read is flat out inaccurate. There are 60 minutes where the clock is running, and the vast majority of that is with the ball live and in play. I would say something like 45+ minutes out of the 60. Also, in fairness I've been to a couple of NFL games, and the commercial breaks tend to happen when the game clock is paused by the flow of the game anyway (team calls timeout, referees are reviewing a play, and so on). It's uncommon for the game at the stadium to be stopped waiting for the broadcasters to show their commercials.
> The stat you read is flat out inaccurate. There are 60 minutes where the clock is running, and the vast majority of that is with the ball live and in play.
You are completely wrong. I know that's what your intuition feels like from watching games, but if you actually get a stopwatch out and clock it, you'll see it's much closer to op than what you posted. Very close in fact.
If you don't believe it, find a actual game and time it. I did this on a game.
For example from the 8min mark to the 2min warning (6 mins of clock time) there were only 2m15s of action. Only 37.5% of the clock time was action. And that was an extremely conservative time. It was the 4th quarter, had multiple scoring plays, and multiple timeouts - essentially everything possible to do to stop the clock and still it maxed out at < 38% of the clock was actual game time. If you instead do this for a full game (not the end of the 4th quarter), and especially games that aren't close and you'll see it's way less. Definitely not what you're expecting.
Football is a tiny amount of "action time" as compared to "clock time".
Imagine the in-person experience. While the long stoppages for the benefit of TV advertisers are taking place, absolutely nothing is happening in the stadium. Untelevised sports offer a far superior in person experience in the US, but most people don't even think about this entertainment option.
The math alone doesn't do it justice anyway because the context switch is terrible. Why can't I just think about the play that just unfolded and discuss with others? Basketball has the same clock mechanics too and it is nowhere near as tainted with ads.
For reference, soccer matches have traditionally been 45 min half, 15 min commercials, 45 min second half.
American football is unwatchable to me for that reason. It’s so stop-start. 30 seconds of play followed by 3 mins of ads. It’s just insane. Feels like the entire game was designed around maximizing commercial sales heh
The point on exceptions I think is also misleading. Compilers typically make throwing an exception the expensive part, and the happy path inexpensive (not more expensive than a branch checking for errors, which should be the baseline for comparison, not an implementation with zero error checking.) So to say that they are "expensive" doesn't really make a useful argument.
And there are more things that could be done in this camp, like proposing a set of compiler flags, and a linter to enforce the subset you are subscribing to. Unfortunately the post offers none of that.
> <deque>: Needs a major performance overhaul", acknowledging that the standard's mandated block size is too small and the design needs to be rebuilt at the next ABI break
Except of course the standard does not mandate a block size. That's purely msvc picking a wrong block size and being stuck with it.
> There are many more things to avoid than just iostream.
But even "avoiding iostream" is stupid. The author presumably really means "avoid operator>> and operator<< for I/O". Even using type-safe printf-like stuff ultimately still sits on top of iostream.
If you want to see it where? If you want a string you've got a string. If you want to write text to something resembling file I/O (e.g. stdout) then std::print and std::println are what you need instead of std::format
Stroustrup's I/O Streams is a weird dead-end C++ technology. Bjarne is probably never going to get over it, but everybody else should forget about it ASAP.
Worth pointing out that the iostreams library is the work of many hands, so Stroustrup is not solely to blame. I just found this old SO question which I answered many years ago (I am anon/Neil) which addresses this:
I'm not wrong. It's been removed elsewhere for being LLM generated. This discussion has already been had multiple times.
The author used Claude to generate it and instructed it to intentionally insert mistakes. They had comments posted on Reddit that discussed doing this and their account is a slew of AI generated responses. The short responses where it appears they didn't use AI don't reflect the behaviour you'd expect from somebody that claims to have over 30 years of experience in HFT but rather point toward them being a teenager or somebody rather immature. They also make a number of wild claims that when put together, are unlikely to be true.
Sorry if you can't recognise it for what it is and shame on you if it's your website, given that you've previously submitted content from there.
It's a tiny website with low value AI generated content and a very quick look revealed that you've linked to multiple articles from there. It's a fair enough observation that you might be affiliated. I don't think you are, though, hence the 'if'.
Indeed. It is rare to encounter a webgl/gpu visualization that doesn't rev up the fans at 100% while sitting idle, let alone to have this low latency handling input. Virtually all web demos I have seen run terribly because literally 0 attention is paid to actual rendering. The other day somebody submitted one here and admitted they didn't know backface culling was a thing. They also almost universally have no sort of frame pacing.
I go through that exercise of visualizing the void and it is fascinating and terrifying at the same time, especially if you do it before going to sleep.
That being said, you can't just assume that existence is bounded by your living memories. You might as well have been everything instead of nothing prior to being spawned and you just don't remember it.
> you can't just assume that existence is bounded by your living memories
I was going to raise that, but couldn't find a short enough way to describe it properly. Something like:
Existence beyond what you can actually remember doesn't matter because it's outside any bounds of practical discussion; it should be excluded from consideration. The same way it's impossible to predict anything 'before the big bang' because we only have 'after the big bang' as useful evidence. There is no way to verify any continuity if you can't remember it or if there is no evidence of it. There's no guarantee you can even comprehend what it could be, 'you' as a concept may not even exist and it's unlikely to be relate-able to anything in this living world. Maybe you return to being 0.00001% of the collective consciousness of the universe, or any other crackpot thing anyone wants to suggest. Flying Spaghetti Monster.".
It may as well be outside our bounds and unverifiable, but that doesn't mean it doesn't matter or that it shouldn't be part of "practical" discussion, whatever you consider "practical" there. You still have a brain to think about these things.
I do personally believe the latter part. I did not mean to suggest the before/after experience was going to look anything like your current one.
If you're a materialist and you think there is no afterlife then I don't believe there would be a void. There's no mechanism for "you" to perceive a void or perceive time.
Its the difference between:
"I see nothing when I close my eyes"
(actually you 'see' darkness over time)
and...
"I see nothing through my elbow"
(You really don't see anything through your elbow because the capacity for it just doesn't exist.)
Even our basic perception of time is mediated by the structure of our brains... and without that there's no difference between one second and a trillion^trillion years.
Being a materialist and claiming that everything is the consequence of physical phenomena is great, but then you have a lot of homework to do. So I see no more strength in its claims than in the contrarian ones.
I believe the fact that it is night time does a lot to it, since we're just wired for a healthy fear of the dark. Coupled with consciousness fading into sleep, it seems to open up a lot of dread.
Certainly check the assembly, but loop invariant code motion and strength reduction are basic optimizations. C compilers tend to be good at optimizing indexing patterns even at -O1.
Take a look, GCC and Clang go further than these suggestions by adding screenRect.w to the pointer each iteration to avoid the multiplication: https://godbolt.org/z/YfroqK7T6
Writing anything but pixels[y*screenRect.w + x] in an attempt to be faster, without checking the assembly first, is obfuscation.
(For what it's worth, you can beat the compiler by using *pixels++. I didn't profile the code to check it actually was faster in practice however.)
reply