If you don't have to do trig, I'd be surprised if you aren't faster by default, oddly. Indeed, if you are just adding and subtracting, it is just a number. If you are doing multiplication, it is a multiply and shift. So long as you don't try and support massive numbers of different fixed sizes, that shift is almost certainly still cheaper than float hardware. (Indeed, a lot of multiplications wouldn't even need the shift...)
Again, I do not mean this as a criticism of floats. For simulations and for numbers where you do have to support completely arbitrary values, there is a reason floats are a thing.
An integer add, sub, or shift is 1 cycle of latency; integer mul is generally 3 cycles; integer div is lol-that-is-slow. Floating-point adds, subs, muls, and fmas are generally 4 cycles, with div being lol-that-is-slow (but generally faster than integer division because your divisor and dividend have fewer bits).
So fixed-point addition and subtraction are definitely faster, multiplication is a wash if you're doing binary-based fixed point (but slower if you're doing decimal-based fixed point), and fixed-point division is definitely slower than floating-point division.
Kudos on providing the numbers. I wasn't confident in the numbers that I remembered and with how pipelined everything is, I didn't know how much to lean on them. Not exactly my standard workflow to care about this level of speed.
My gut would still be that it is typically a wash for most everyone as far as speeds go? If default libraries supported it more directly, I would think it would largely be a win for a lot of reasoning. In particular, silly stuff like 1e32 + 1e1 would not be nearly as surprising to most people. And the entire class of bugs around stuff like doing something until it reaches 0.9 would almost certainly go away if we guaranteed precision to a set number decimal places.
Alas, default libraries do not support this, though. So the above is admittedly wishful thinking on my end. And I could as easily describe a world where people insist on arbitrary numbers of fixed point values and how that would be its own set of landmines.
I very commonly see fixed-point libs be slower than floating-point (assuming floating-point hardware is available --- soft-float is slow as hell compared to fixed-point, of course).
Commonly enough that I think it's some fundamental reason (given available/current hardware as opposed to hypothetical).
Two reasons I can think of, though granted, they only apply in certain niches:
1) Floating-point SIMD extensions are far more common than integer ones. This means you can compute N (often N=4 or 8) float operations in one instruction, vs 1 integer operation.
2) For any GPGPU processing: GPUs far prefer floats, to the point where you didn't even use to have integers available (somewhat ironically, the platforms that prefer float much more strongly to int are mobile/embedded ones nowadays --- which is the exact opposite of the CPU situation). To this day, you have a `mul24` intrinsic for integer multiplication in some languages ... which converts two integers to floats, multiplies them as floats, and then converts back to integers. Yes, that was faster than direct multiplication. I'm sure many GPUs do it directly nowadays though.
It's also worth considering that a typical fixed-point multiply (as opposed to integer) is an integer multiply followed by a shift; often to a 2×-bit intermediate, if you want to preserve precision. That's a cost.
I believe Swift tends to use reference counting and copy-on-write strategies. This, like GC, is less for the programmer to think about and doesn't require the semantic checks, but sometimes the performance cost is unacceptable compared to what you'd write in Rust.
You can choose to use either refcounting or unique ownership for your types. For most use cases, refcounted (+ copy-on-write) is the best choice and is the default, but the truetype interpreter made extensive use of non-refcounted types to achieve this performance.
They have either recently added or talked about a borrow style system in the language as a way to avoid more copies and speed things up/lower memory usage/help with asynchronous programming.
You should have shown the original video and not the one from Dan O'Dowd. He is not interested in pedestrian safety in any way, he is doing this only to promote his own company, Green Hills Software. He didn't have any issues with Tesla until it stopped using his software.
Ah yes, consistently, correctly, and truthfully highlighting serious safety defects and unacceptable design oversights for years in the products of a trillion dollar company with a rabid fanbase well known for running smear campaigns is "not interested in pedestrian safety".
I imagine everybody relishes the opportunity to get smeared by entirely false accusations by Tesla promoters with a conflict of interest. You can tell the Tesla promoters running the smear campaigns are worth listening to because their smears keep getting disproved by video evidence.
Please point at any clearly visible video evidence that their whistleblowing is inaccurate. No "shaky cam" "Bigfoot" evidence where you point at something blurry and falsify a claim to fit your desired narrative.
Your job would have been a lot easier if any of those Tesla Promoters accepted the Dawn Project's offer to attempt the tests themselves with their own Tesla's and their own cameras giving them the perfect platform to debunk the Dawn Project's claims. Weird how they all chickened out on that slam dunk.
In this case, the whistleblowing was done by DirtyTesla (as credited by Dan). Respect to him for that. Dan has created proven fake videos where Tesla is allegedly unsafe, but got caught. So he has lost his credibility.
It's very important to call out these issues AND to do it honestly.
Nope. Those accusations were proven false and the people who made them have lost all their credibility. It was just a smear campaign by Tesla promoters so effective that here you are parroting it against reality to protect a trillion dollar company that actively lies and promotes illegal and dangerous behavior. They really outdid themselves with that smear campaign.
If you disagree, I presented the criteria for evidence needed to support your case. Remember, no shaky cam.
Do you mean FSD or Autosteer (or Autopilot or whatever it's called now). I think Tesla left Autosteer purposefully crappy. FSD is excellent at keeping the lane, way better than what your Škoda can do.
I agree it is intentional. They haven't updated autosteer, as far as I can tell, since the Model 3 was released. Certainly my 2023 (sold a couple weeks ago) was no better than my 2019 was, and notably worse than my Ford Lightning. Outside of FSD, most everyone else makes superior TACC & lane centering now.
There should be a path for local building as well. Node.js is being used on a lot of embedded systems. I’d imagine there are also lots of other reasons for local builds.
there's fallback to build from source but it would require the builder to have all the toolchain installed (whatever the library is using: could be gcc, python, rustc....)
China and India signalled to Russia that nukes are big no-no.
Reason is simple - using nukes when you can't win a conventional war will degrade them from strategic asset into tactical one and whole nuclear proliferation flies out of the window and everyone will have nukes.
reply