TIL `Math.hypot(x, y)` in JS is waaaaay slower than `Math.sqrt(x*x + y*y)`.

[evilpaul_atebit@icosahedron.website]

@jonikorpi TIL: `Math.hypot(x, y)` exists

[lisyarus@mastodon.gamedev.place]

@jonikorpi I'm using the same method (I think) in my C++ engine, but I guess the perf cost in JS is somehow much higher due to dynamic typing or smth?

[aeva@mastodon.gamedev.place]

@lisyarus @jonikorpi also js means doubles

[lisyarus@mastodon.gamedev.place]

@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@mastodon.gamedev.place]

@lisyarus @aeva some background links for the interested:

https://www.reddit.com/r/javascript/comments/1rf99ak/til_about_mathhypot/

https://issues.chromium.org/issues/42203737

https://bugs.webkit.org/show_bug.cgi?id=284631

[lisyarus@mastodon.gamedev.place]

@jonikorpi @aeva Ohhh it also supports arbitrary number of arguments. Yeah, makes sense

[sinbad@mastodon.gamedev.place]

@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”

[aeva@mastodon.gamedev.place]

@sinbad @lisyarus @jonikorpi yeah I gues I am using them everywhere in mollytime lol

[aeva@mastodon.gamedev.place]

@sinbad @lisyarus @jonikorpi though that might eventually be problems for simd reasons

[sinbad@mastodon.gamedev.place]

@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@mastodon.gamedev.place]

@sinbad @lisyarus @jonikorpi that shit adds up though

[sinbad@mastodon.gamedev.place]

@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