"The law is antiquated and should be repealed. The framers could never have envisioned Our Supreme Lord AI and how irrelevant individual compute is today when writing that law."
I do scientific computing, and even I rarely have a situation where CPU SIMD is a clear win. Usually it's either not worth the added complexity, or the problem is so embarrassingly parallel that you should use a GPU.
Interesting, in what domain? My work is in scientific computing as well (finite elements) and I usually find myself in the opposite situation: SIMD is very helpful but the added complexity of using a GPU is not worthwhile.
No, because as I commented in another subthread, `-ffast-math` is:
1. dangerous assumptions hidden behind a simple, attractive-looking option [1]. It should be called -fwrong-math or -fdangerous-math or something (GCC does have the funnily named switch -funsafe-math-optimizations – what could go wrong with fun, safe math optimizations?!)
2. Translation-unit scoped, which means that dependencies not consented to "fast math" can break your code (as in UB land) or make the optimizations pointless, and your code can break your dependencies' semantics too via inlining. On the other hand, a library author must think very carefully what float opts to enable in order to be compatible with client code.
Deciding how the scoping of non-IEEE float math operations should work is a very nontrivial question. The scope could be a translation unit, a module, a type, a function, a block, or every individual operation, and none of those is without issues, particularly regarding questions like inlining and interprocedural and link-time-optimization, as well as ergonomics. In other ways, it's yet another function coloring problem.
There are currently-unstable "algebraic_add/mul/etc" methods for floats for letting LLVM treat those particular operations as if floats were real numbers [2]. They're the first step towards safe UB-free float optimizations, but of course those names are rather awkward to use in math-heavy code, and a wrapper type overloading the normal operators would be good to have.
No it doesn't. A global flag is a no-go as it breaks modularity. A local opt-in through dedicated types or methods is being designed but it's not stable.
Particularly if a school of knowledge is at all dangerous. To the body or the mind. For instance trying to cure an infectious disease, which is both every time you fail.
Corporate R&D dies under the short-term thinking of quarterly profits. The best pure R&D seems to be coming from private companies that are able to sustain losses for long periods of time until a significant breakthrough is achieved (e.g. SpaceX, OpenAI, etc.).
Sounds like this advice will be expiring along with the next Windows update, so if you want a local account your window of opportunity may be closing. (What happens when you need to get a new PC?)
This is a weird story. If I were the dad, I would've preferred to tell my daughter myself. And a Nobel winner being overjoyed to get a free parking pass is borderline dystopian.
Berkeley gives dedicated parking spots to Nobel laureates. It’s not about having a place to park. It’s about being in the same category as all of those greats.
1. Very few people these days understand the difference between hyphens, en-dashes, and em-dashes. And then converting fonts and character sets on the internet adds another layer of error generation. We could settle on using a single '-' for hyphen and en-dash and a ' -- ' for em-dashes in fonts that don't have a ligature, but that hasn't carried down from the typewriter days for some reason. Microsoft Word is probably a big part of why.
One example: ICUs typically monitor a dozen or so of these traces per nurses station, so having an automated system for detecting codes would speed up response and avoid missed cardiac events.
reply