I'm pretty sure that most cases of x86 reordering issues are a matter of the compiler reordering things, which isn't (afaik) solved with just "volatile". Caveat - haven't dealt with this for at least over a year (multicore sync without using OS primitives in general).
Literally the volatile keyword in Java is to make the Java compiler aware in order to insert memory barriers. That only guarantees consistent reads or writes, but it doesn't make it thread safe (i.e. write after read), that's what atomics are for.
Also not only compilers reorder things, most processors nowadays do OoOE; even if the order from the compiler is perfect in theory, different latencies for different instruction operands may lead to execute later things earlier not to stall the CPU.
Note that this is only true of the Java/C# volatile keyword. The volatile keyword in C/C++ is solely about direct access in hardware to memory-mapped locations, for such purposes as controlling external devices; it is entirely unrelated to the C11 memory model for concurrency, does not provide the same guarantees, and should never be used for that purpose.
x86 has a Total Store Order (TSO) memory model, which effectively means (in a mental model where only 1 shared memory operation happens at once and completes before the next) stores are queued but loads can be executed immediately even if stores are queued in the store buffer.
On a single core a load can be served from the store buffer (queue), but other cores can't see those stores yet, which is where all the inconsistencies come from.
Would you mind linking some articles or hinting towards techniques used to "coerce" the choosing of ray sample directions so that noise is minimized even in very "specular" scenes? Sorry for the lack of proper terminology on my end, I've been out of the loop for a very long time, but I assume that's where the majority of the tricks are - I suppose the rest is mostly intersection check accelerations (i.e. BVH).
The modern state of the art for realtime is ml denoisers, taking noisy pixel data from multiple frames, plus other associated data eg velocity vectors of geometry, depth data etc. and using it to produce a perfectly denoised image.
Right now, I'm heavily into Cyberpunk 2077. I've got an RTX 5090, so I can turn all the details, including the ray tracing, to their maximum settings. It's absolutely gorgeous (Especially on my 4K HDR OLED monitor), but if you look really closely, you can still see the evidence of some shortcuts being taken.
Some reflections that are supposed to be a bit rough (like a thin puddle in the road) may appear a bit blurry as I'm walking, but will come into better focus when I stop. My guess is that as I'm moving, the angles of the rays being reflected change with every frame, making the data very noisy. Once I stop, they become consistent, so the reflection becomes clear.
I always move the taskbar to the right on any remotely wide setup that I have - including my 21:9 main. Had it at the top on my sp3. On my current portable (spectre 13.5) it's at the bottom, since I kind of have to use win11 due to the heterogeneous cpu arrangement (how "hard" could it be to port the scheduler to win10... yeah yeah we know), and while it annoys me when I dock it at work, the system (win11 pro, with MS account) absolutely does suck in a lot of other respects.
Right click latency in explorer is annoying.
Opening the settings "app" after first boot takes several seconds because who the hell knows - I personally blame it on moving everything to some thousand layers JS framework since I like being grumpy about that. This is a core part of the OS, FFS. Fairly certain that they have the talent to pull it off properly.
Search has been fine for me.
Language switching almost always breaks during updates - "ghost keyboard layouts" and such. Has been the case for a few years now.
General "we'll shove down whatever we feel like on you" BS.
Just let us pay for "ultimate" (a.k.a. end-user enterprise) and be rid of all the BS.
Getting WSA back (yes, I have the community version) and expanding on connected standby or however they call it now would've been neat, especially on a convertible, but it is what it is, I guess. WSL2 is also quite the improvement. Lots of other small little things like the task manager (not using procexp too often nowadays).
> Just let us pay for "ultimate" (a.k.a. end-user enterprise) and be rid of all the BS.
This would do it for me, and probably many others. People would still complain, but at least it'd be offered.
They can keep the home editions as the adware and copilot editions, just let us buy "Ultimate" without all that (or just leave it as opt-in/toggleable). If the new snapdragon X Elite 2 chips pan out like the early benchmarks show they do (almost on par with the M5 in the new iPad), and if Windows encourages more ARM adoption they could seriously have a legitimate macbook competitor finally.
But that would require MS to divert efforts away from "AI, AI, AI, AI!" so they won't do it.
Be careful with that feeling and don't underfuel, or at least keep it at "sane" levels. I feel pretty amazing and full after 62km/2700mD+ XCMs as well, as an extreme example... which is at least partially due to the immune system (and resp. inflammation/etc) being suppressed. Long, light/moderate efforts without adequate food intake and rest can lead to the same thing.
Stress hormones. Read up on cortisol's effects. XCM - cross country marathon (MTB race). 2700mD+ - 2.7km of vertical gain. A reduction of inflammation is a general effect of anti-inflammatory drugs, which tend to make you feel better. There's a LOT more than that (i.e. say, all the things that fall under the umbrella of "runner's high"), but the TL:DR is that significant physical activity / energy expenditure, combined with a lack of proper rest & nutrition leads to long-term undesirable effects that can definitely be masked and/or disregarded.
I guess you meant to say "only the people working on the software coupled to the tooling will use it". It's not just FDB & Amazon that are using something like this, and it is a ridiculously powerful type of tool for debugging distributed systems.
I wonder how strong the driveshafts would have to be to handle all the braking torque transmitted through them. Dissipating the heat would also be an interesting problem. Also reduced clearance and/or increased drivetrain complexity and a million other things.
There are good reasons why people haven't moved away from old school rotors, pads & calipers right at the wheel hub, for basically any application.
My guess is torque isn't as big of an issue since on acceleration you break traction before anything snaps. The big issue in my mind is technically cooling and practically packaging since you already have the space inside the wheels.
I know inboards are used on some formula student cars in the rear (on some karts as well?) but I haven't looked up the issues they have with them.
Brake torque is far higher than engine torque and can be applied at speeds where tire traction is far greater - at least at the front. The rear makes far more sense for this application - assuming a performance RWD or AWD vehicle, the rear driveshafts already handle most of the acceleration load, and max rear braking load is practically severely limited by the load transfer to the front.
Formula student cars and other open-wheelers have far greater packaging flexibility as well. A quick search doesn't bring up a whole lot of encouraging discussions on FSAE and related places re: inboard brakes, please share if you've seen such.
Not too different from, say, any of Toyota's hybrids (and the TLC100 / GS430 / others using "electronic brakeforce distribution")? Same with almost every EV out there, same with MB's SBC, etc. I really don't see why this counts as a big leap - all I see is the removal of the backup direct hydraulic lines, which doesn't exactly sit well with me.
I mean it's not like hydraulic lines can't fail catastrophically as well though. History has given us somewhat unrealistic ideas about what is and isn't safe - it all comes down to the design, not the underlying technology.
The major "sudden" failure mode of pretty much all those systems has so far been the (brushed!!!) electric motor eating through its commutator (with the brushes still relatively intact) and stopping relatively suddenly - at that point, you'd better not ignore the lights on the dash, as it means there's only what's left in the hydraulic pressure accumulator in terms of assistance - afterwards there's almost nothing. The backup hydraulic lines have never really been an issue with this setup - the backup lines are two and directly go to resp. the front left and right calipers, and the only time they see pressure and fluid movement is during the brake bleeding procedure. The rest of the hydraulic circuits are somewhat safer as cars with such systems can absolutely detect and isolate a "misbehaving" circuit - i.e. if a flex hose is punctured, the rest of the system will work.
-Rim brakes means ever so slightly bent rim = SOL.
-There are some decent internal cable routing setups. The newest fad (through-headset), though...
-Comfort has a ton of variables, of which tyre volume/pressure/type/details(inserts/etc) are a major part of, but not the be-all-end-all. Grips, handlebars, saddles, pedals, crank length, etc, etc, etc, etc...
Rim breaks are fine for most people. your wheel has to be very very visually out of true to cause problems and thats only a $20 fix at the local bike shop. A little cathunk in the hands during braking never hurt anyone. Source: rode $40 bikes through college. Most of the comfort stuff is not applicable unless you are spending hours and hours in the saddle. You aren’t going to notice the crank arms are too short or your reach is too long commuting 30 mins to work.
Truing a wheel is something that for 100 years avid cyclists (riding multiple times per week) could do with nothing but a single $3 truing wrench. If you were very poor like me in college you did it by pushing the rim brakes to one side or another and then truing against the rim hitting the pad. We used to do this on the trail, ride mates amiably sitting by why the whacked wheel gets put into "enough" true.
Nowadays of course I have the whole kit, the Park truing stand, various truing wrenchs... and that's it. Oh right I use painter's tape to mark problematical spokes. I've built three sets of fabulous wheels that take a lot of abuse but let me still set personal records at (say) TdT.
Now we get to the flame wars. I've been endurance cycling 50 years, since I was 14 or so. I completely understand the arguments for disc brakes for tandems and touring setups. What the disc brake people are not telling you is that the hand fatigue problem was solved by $40 Avid Single Digit rim brakes 25 years ago. I have a set on my mt bike that are truly single digit sufficient for most rough descents up to say 3000' and maybe an hour. Probably you need to do some exercises if you're doing those and having fatigue. I have been at Moab doing an insane gonzo abusive descent and noticing that hmm might be having safety issues soon with my forearms, and hmm, I need to get this descent done... but that was before the Avid brakes. My 20 yo Specialized frame FrankenBike with Avid SD brakes is not being replaced in I guess forever because it is gonzo abusive ready and it just works.
Edit: Oh if anyone has a nice set of used Avid SD brakes I'd really like to replace the way too sensitive Paul sidepull brakes on my gravel bike. I put the dumbest pads possible on them and they're still too sensitive. I'd happily trade if I could fully refurb the functionality of the Avid brakeset.
Hand fatigue is a real issue if doing big off road touring, but that’s not most people.
Yes rim brakes are worse in the rain, but they’re not that bad! I wonder if people who say this have tried a modern dual pivot road caliper or decent v-brakes. They have easily enough stopping power for commuting in rain.
Everything sucks in the rain. They still work alright they just take a single rotation to squeegie water off the rim then they grab stronger than the tire can hold the road.
Anyways, nice engines, but you don't need something to be exceptionally reliable to keep it in production for 25 years.
reply