TIL `Math.hypot(x, y)` in JS is waaaaay slower than `Math.sqrt(x*x + y*y)`.
-
@aeva @jonikorpi Afaik doubles aren't much slower than floats on modern CPUs, the main difference being the memory size (so it matters if you're working with large amounts or data or you're doing SIMD)
-
@jonikorpi @aeva Ohhh it also supports arbitrary number of arguments. Yeah, makes sense
-
@aeva @jonikorpi Afaik doubles aren't much slower than floats on modern CPUs, the main difference being the memory size (so it matters if you're working with large amounts or data or you're doing SIMD)
@lisyarus @aeva @jonikorpi I just can’t get over doubles being cheap. UE defaults to them now. In Ogre we had a double precision compile flag that about 3 people with very specific needs used and for everyone else was “lol no”
-
@lisyarus @aeva @jonikorpi I just can’t get over doubles being cheap. UE defaults to them now. In Ogre we had a double precision compile flag that about 3 people with very specific needs used and for everyone else was “lol no”
@sinbad @lisyarus @jonikorpi yeah I gues I am using them everywhere in mollytime lol
-
@sinbad @lisyarus @jonikorpi yeah I gues I am using them everywhere in mollytime lol
@sinbad @lisyarus @jonikorpi though that might eventually be problems for simd reasons
-
@sinbad @lisyarus @jonikorpi though that might eventually be problems for simd reasons
@aeva @lisyarus @jonikorpi I do a lot of custom 2D calculations in our game and I stubbornly use FVector2f everywhere instead of FVector2D like UE likes to, because I just can’t make myself use a double when I don’t think I need it
-
@aeva @lisyarus @jonikorpi I do a lot of custom 2D calculations in our game and I stubbornly use FVector2f everywhere instead of FVector2D like UE likes to, because I just can’t make myself use a double when I don’t think I need it
@sinbad @lisyarus @jonikorpi that shit adds up though
-
@sinbad @lisyarus @jonikorpi that shit adds up though
@aeva @lisyarus @jonikorpi It does, but I don’t use it for smooth movement or anything, so there’s no incremental drift. It’s mostly for map data which is already approximated via the density grid - it has a max accuracy of about 7cm anyway so losing a few fractions of a cm precision at the map edges isn’t a problem
-
@sinbad @lisyarus @jonikorpi yeah I gues I am using them everywhere in mollytime lol
-
@jonikorpi @aeva @sinbad Maybe it's related to stuff like basic sin(time) noticeably loosing precision very soon in floats? I'd say for stuff like this you just shouldn't do sin(time) in the first place and compute the sine wave in some other numerically stable way.
-
@lisyarus @aeva @jonikorpi I just can’t get over doubles being cheap. UE defaults to them now. In Ogre we had a double precision compile flag that about 3 people with very specific needs used and for everyone else was “lol no”
@sinbad @lisyarus @aeva @jonikorpi I'm still sceptical, doubles use twice as much memory, that *must* result in all sorts of bad knock-on effects.
-
@jonikorpi @aeva @sinbad Maybe it's related to stuff like basic sin(time) noticeably loosing precision very soon in floats? I'd say for stuff like this you just shouldn't do sin(time) in the first place and compute the sine wave in some other numerically stable way.
@lisyarus @aeva @sinbad Could be! I was doing this kind of thing when I noticed/hallucinated it:
```
phase = (phase + frequency / sampleRate) % 1.0
sin(phase * PI * 2)
```That timestep ends up really tiny, so the precision loss must affect the resulting frequency somehow?
I also wondered if it could be related to envelopes. Lots of `amplitude *= 0.99999` type of calculations running 44000–96000 times per second. 🤷
-
@lisyarus @aeva @sinbad Could be! I was doing this kind of thing when I noticed/hallucinated it:
```
phase = (phase + frequency / sampleRate) % 1.0
sin(phase * PI * 2)
```That timestep ends up really tiny, so the precision loss must affect the resulting frequency somehow?
I also wondered if it could be related to envelopes. Lots of `amplitude *= 0.99999` type of calculations running 44000–96000 times per second. 🤷
@jonikorpi @aeva @sinbad In my lib I have a special class for that case, yeah: https://bitbucket.org/lisyarus/psemek/src/master/libs/audio/include/psemek/audio/detail/oscillator.hpp
The envelopes, though... Does 0.999999 really have a noticeable effect?
-
@jonikorpi @aeva @sinbad In my lib I have a special class for that case, yeah: https://bitbucket.org/lisyarus/psemek/src/master/libs/audio/include/psemek/audio/detail/oscillator.hpp
The envelopes, though... Does 0.999999 really have a noticeable effect?
-
@jonikorpi @aeva @sinbad Hmmm, true. Though I guess you can specify it in more reasonable units (e.g. decay per second instead of decay per sample), in which case things should be okay provided you compute exp(-k*log_decay) on each sample, hmmmmm
-
TIL `Math.hypot(x, y)` in JS is waaaaay slower than `Math.sqrt(x*x + y*y)`. Apparently it uses a more precise algorithm under the hood: something something underflows overflows numerical stability.
Time to strip them all out of my codebase. ><
@jonikorpi Huh… I often use that in various languages to save a bit out typing when dx or dy are calculated values. I assumed it was just a shortcut…
-
@jonikorpi Huh… I often use that in various languages to save a bit out typing when dx or dy are calculated values. I assumed it was just a shortcut…
@slembcke Me too. :s Hopefully the performance difference isn't as bad in other languages. Already varies quite a bit between browser engines.
-
@jonikorpi @sinbad @lisyarus i saw a thing recently claiming audiophiles couldn't tell the difference between doubles, a banana, and wet mud!