~Hello I hitting a super weird wall in Kotlin JS legacy with

Question

~Hello I hitting a super weird wall in Kotlin JS legacy with this subtraction ~ ~`1 6896646614334472 1 6893290421702434` sometimes returns `3 356192632038013E 4` like in the JVM but at other times I get `0 0003356192632038013` ~ ~I searched deep but I still have no clue as to why I m getting this anyone has an idea ~ ~I m completely lost Pure JS in Google Chrome console gives `0 0003356192632038013` which is not what IEEE 754 should give I think Kotlin code with JDK 18 gives me `3 356192632038013E 4` which is using Java s `double` which is supposed to be IEEE 754 too ~ ~It gets weirder ~ ~Here s a snippet I m running in multiple modes on <http play kotl in|play kotl in> with Kotlin 1 8 10 ~ ```fun main val a = 1 6896646614334472 val b = 1 6893290421702434 val c = a b println $a $b = $c ``` ~Here are the results ~ ~on Kotlin JS IR `0 0003356192632038013`~ ~on Kotlin JS legacy `3 356192632038013E 4`~ ~on Kotlin JVM `3 356192632038013E 4`~ EDIT This is the same number just represented differently The actual problem is that `sin 0 8314090181354269 ` gives different results on JS compared to Android and SOME JVM environments the last digit can be `7` or `8` and we still don t know why

jw · Answer

Are you saying the problem is the string representation Because those are all the same number

louiscad · Answer

Well the computations that I have afterwards drift further leading to a test that fails on some platforms

jw · Answer

But there is no drift in those numbers They are the same

louiscad · Answer

You re right now I see it so I need to look further

louiscad · Answer

I guess Kotlin JS IR is only being more consistent now by always showing it the JS way

jw · Answer

I suspect the string representation is perhaps influenced by the bit representation So perhaps it can be exactly represented in two bit forms and some quirk of the codepath results in one bit pattern over the other There s probably some normalization thing in the floating point spec

louiscad · Answer

Other operations I have further down are all using `Double` at least from a Kotlin standpoint and I have ` ` `+` `cos` and `sin` being used

jw · Answer

nevermind seems like the bit pattern is always normalized since there s an implicit 1 in the integer part that isn t encoded but is assumed

louiscad · Answer

Ok found where the ~sin~ drift starts `sin 0 8314090181354269 ` What do you get on your machine on Kotlin JVM

Chris Lee · Answer

Kotlin playground sin 0 8314090181354269

Chris Lee · Answer

jw · Answer

louiscad · Answer

On <http play kotl in|play kotl in> I consistently get `0 7388815504611167` for Kotlin 1 8 10 be it the JVM JS legacy or JS IR On machine though on the JVM I get `0 7388815504611168` notice the last digit My JDK is `64 Bit Server VM Zulu18 30+11 CA`

louiscad · Answer

Your link Jake gives me the same result as <http play kotl in|play kotl in> I don t get why at other times I get the last digit changed in Kotlin JS legacy and on my JVM blob thinking upside down

Chris Lee · Answer

the challenge is in printing it out need to find a way to dump compare the internals as the string representation is just that an alternate representation

Chris Lee · Answer

This may help ```import kotlin math fun main println sin 0 8314090181354269 toRawBits ```

louiscad · Answer

I get `4604830472895931656` locally

Chris Lee · Answer

Playground has `4604830472895931655`

louiscad · Answer

Yup one bit off

Chris Lee · Answer

yep

louiscad · Answer

heads down gun

louiscad · Answer

I m glad it s a water gun

louiscad · Answer

Google search seems empty of results for that problem which doesn t even seem to be a Kotlin JS problem now I think this is the weirdest thing I ve ever seen as a developer

Chris Lee · Answer

oh let s not get into comparing weird things not enough tumbler glass for that What is your local machine JVM

louiscad · Answer

aarch64

louiscad · Answer

JDK is `64 Bit Server VM Zulu18 30+11 CA` as stated before in the thread

louiscad · Answer

Regardless thank you very much to both of you for your help so far I already learned a few things and discovered <http kotlin godbolt org|kotlin godbolt org> as well pray skin tone 3

Chris Lee · Answer

On my MacBook M1 aarch64 Corretto 17 0 6 10 1 `4604830472895931656`

louiscad · Answer

So same as me

Chris Lee · Answer

think that s the same as what you had locally yea

louiscad · Answer

I m going to test on my phone

louiscad · Answer

My phone and my laptop agree

louiscad · Answer

Android 13 and macOS

Chris Lee · Answer

that s positive Is it just the playground that is off or other situations

louiscad · Answer

Hum I think it s worse than that

louiscad · Answer

Chrome on my laptop agrees with Kotlin Playground and JDK 17 on GitHub Actions on Linux also agrees with that

louiscad · Answer

And godbolt

louiscad · Answer

So depending on the JDK or the platform we get something different

Chris Lee · Answer

Is this an accurate summary so far ```MacBook M1 aarch64 Corretto 17 0 6 10 1 4604830472895931656 aarch64 64 Bit Server VM Zulu18 30+11 CA 4604830472895931656 Playground 4604830472895931655 Chrome on aarch64 4604830472895931655 godbolt 4604830472895931655```

Chris Lee · Answer

With github ```MacBook M1 aarch64 Corretto 17 0 6 10 1 4604830472895931656 aarch64 64 Bit Server VM Zulu18 30+11 CA 4604830472895931656 Playground 4604830472895931655 Chrome on aarch64 4604830472895931655 godbolt 4604830472895931655 Github Actions linux 4604830472895931655```

louiscad · Answer

You can just edit your previous message and remove the other one instead of pasting the same thing just to add one line

Chris Lee · Answer

looks like godbolt is Linux in Intel

louiscad · Answer

My concise summary only last digit differs JVM on macOS aarch64 Android 13 aarch64 `0 7388815504611168` JS legacy amp IR JVM on Linux x64 `0 7388815504611167`

Chris Lee · Answer

^^^ that s not the same test sin

louiscad · Answer

That s a different representation but we ve seen it s not the same number in both cases

Chris Lee · Answer

sure but trying to keep the test consistent and identify which platforms are different This is what we have so far ```println sin 0 8314090181354269 toRawBits MacOS aarch64 Corretto 17 0 6 10 1 4604830472895931656 MacOS aarch64 Zulu18 30+11 CA 4604830472895931656 Playground 4604830472895931655 Chrome on aarch64 4604830472895931655 godbolt Linux Intel 4604830472895931655 Github Actions linux 4604830472895931655```

louiscad · Answer

Please don t make me read that list again with all those digits

Chris Lee · Answer

it s just the platform and the results

louiscad · Answer

Anyway I don t know what I m going to do with that and the d mn test but it s 4 26AM I ll go where I belong

louiscad · Answer

This is the 3rd time you re copying this

Chris Lee · Answer

yes updated with information as we test

Chris Lee · Answer

it shows that the JVM on MacOS is different than all the rest

louiscad · Answer

Nope Android agrees with macOS

Chris Lee · Answer

Do we know if that Android is on an arm chipset

louiscad · Answer

Yes it is

Chris Lee · Answer

yea so it looks like the JVM ARM combo is different somehow

louiscad · Answer

I said it s my phone earlier who sports a non ARM phone these days

louiscad · Answer

Interesting Intel Mac gives the same result as Linux x64

louiscad · Answer

JVM again

louiscad · Answer

What a cluster k

louiscad · Answer

Seems to be CPU dependent

Chris Lee · Answer

yea so arm jvm is different somehow but how to take that further

Chris Lee · Answer

haven t had any luck searching on this yet

louiscad · Answer

I m wondering if ARM 32 bits CPUs would give the same difference Need to test with an old phone someday

louiscad · Answer

Or easier a watch because I ve got no ARM 32 bits phone around

Chris Lee · Answer

Here s golang on my Macbook aarch64 `4604830472895931655` Same as JVM Intel etc

louiscad · Answer

Might look into this tomorrow

Chris Lee · Answer

So not really the CPU the JVM CPU combination

louiscad · Answer

Still kinda is

louiscad · Answer

But there are other factors as well

louiscad · Answer

Interesting nonetheless

Chris Lee · Answer

well the CPU can get the right answer as shown with golang But the JVM on the same CPU doesn t

louiscad · Answer

Not just the JVM

louiscad · Answer

ART as well

louiscad · Answer

I guess it s more artsy

Chris Lee · Answer

sorry what is ART

louiscad · Answer

Android RunTime

louiscad · Answer

It s not an actual JVM

Chris Lee · Answer

yea

louiscad · Answer

A bunch of things are different in ART but not this kind of things usually

Chris Lee · Answer

Some hint here relating to precision differences between Intel ARM <https stackoverflow com questions 11832428 windows intel and ios arm differences in floating point calculations>

ephemient · Answer

funny you mention it just recently I encountered <https kotlinlang slack com archives C09222272 p1675431328423709>

ephemient · Answer

but basically you shouldn t expect the exact same bit patterns from floating point operations on different platforms

Chris Lee · Answer

yep looks that way even between JVM revisions as they may change the internals to use different opcodes which may adjust the precision

ephemient · Answer

Java has StrictMath sin that is supposed to be using the same implementation across platforms as opposed to Math sin which is supposed to be fast and close enough

ephemient · Answer

earlier versions of the JVM had a `strictfp` modifier preventing using the intermediate 80 bit x87 FPU values that s gone now SSE works better on x86 64 and isn t an oddball size

ephemient · Answer

but still there s optimizations like using FMA which can result in slightly different results

Chris Lee · Answer

Kotlin `math sin` boils down to `StrictMath sin` on the JVM It is documented as being non exact gt The computed result must be within 1 ulp of the exact result

ephemient · Answer

where do you see that it definitely goes to `Math sin` from what I can see

Chris Lee · Answer

Clicked thru from Kotlin math sin to ``` SinceKotlin 1 2 InlineOnly public actual inline fun sin x Double Double = nativeMath sin x ``` to ``` IntrinsicCandidate public static double sin double a return StrictMath sin a default impl delegates to StrictMath ``` Kotlin 1 8 10

ephemient · Answer

ephemient · Answer

```import java lang Math as nativeMath public actual inline fun sin x Double Double = nativeMath sin x ```

Chris Lee · Answer

wowsers yes that is right let me see if the click thru lies

Chris Lee · Answer

no it s right Math sin gt StringMath sin

Chris Lee · Answer

StrictMath sin

ephemient · Answer

are you looking in java lang Math that is outside of kotlin stdlib and may be implemented differently on different JVMs

Chris Lee · Answer

that s right it is documented as being non exact so precision will vary

ephemient · Answer

kotlin stdlib doesn t even promise 1 ulp

Chris Lee · Answer

nor are there cross platform consistency promises

ephemient · Answer

oh if you re looking at OpenJDK ``` IntrinsicCandidate public static double sin double a ``` that means that the JIT may produce some different native code instead of running that function normally

ephemient · Answer

and this in fact does happen e g <https bugs openjdk org browse JDK 8189105>

ephemient · Answer

so don t believe the implementation

Chris Lee · Answer

100 Even with Strictfp the results vary between platforms

ephemient · Answer

strictfp is orthogonal to this and doesn t even do anything on modern JVMs

Chris Lee · Answer

It is however consistent running it in a loop such that Hotstop will compile to native code doesn t change the results and the results are the same with without Xint to disable compilation

Chris Lee · Answer

Xint is noticeably slower

ephemient · Answer

the JVM tries to avoid the same pure function having different values at runtime

ephemient · Answer

although there s definitely been bugs in the past where constant folding could produce different results depending on the platform

Chris Lee · Answer

interestingly the same sin calculation in golang aarch64 returns a different result than JVM aarch64 Would have to wade through the opcodes to figure that out likely differences in intrinsics etc

ephemient · Answer

well that s unsurprising since they use completely different implementations

ephemient · Answer

`sin` isn t an instruction in ASM it s library code

ephemient · Answer

you re comparing to

Chris Lee · Answer

that s right go does have an architecture specific sin `archSin` internal function but of course the implementations will differ as will the compiler steps etc

Chris Lee · Answer

the results are close off by just the last bit which is fine amp expected

Chris Lee · Answer

it s all a curiosity now wink

ephemient · Answer

I didn t think Go had a ARM64 variant of sin but maybe it does and I missed it in any case yeah the details don t specifically matter to us we just have to keep in mind that the results should be close but may not be exactly equal

ephemient · Answer

some more floating point fun just in plain multiply and add no trig <https www kdab com fma woes >

Chris Lee · Answer

lol `stubs go` has the directive ```go build s390x``` indicating that most of the trig operations don t have assembly intrinsic implementations outside of s390x platform

Chris Lee · Answer

so that s the difference the JVM uses intrinsics for sin golang doesn t Well at least one of the differences there could be algorithmic or other implementation details

ephemient · Answer

Hotspot implements those intrinsics it s not like it s something magical you can see the code it produces in the link I pasted earlier plus some data tables in a neighboring file

Chris Lee · Answer

exactly

elizarov · Answer

It has nothing to do with FMA and stuff `sin` just does not and pragmatically can not guarantee that it always produces the same result The actual implementation of `sin` uses an approximate algorithm and it only guarantees that its error does not exceed 1 ULP That is it can be off from the correct answer in the last bit This especially happens when the true answer is almost half way in between neighboring double values In this case different implementations of `sin` function can get different values of the last bit This is totally inevitable The actual background here is way more complicated For example old versions of libc tried to provide correctly rounded result in all the cases That meant that sometimes when approximation is close to the half of the last bit it has to use arbitrary precision arithmetics to figure out more digits to round the result correctly It ended up causing all sorts of performance problems in games where sometimes if you are unlucky sin computations will be very slow Modern libc does not do this anymore Nobody does nor should be doing this It is perfectly fine for a `sin` value to have different value in the last bit on different implementations runtimes versions archs

elizarov · Answer

TL DR It is easy to mathematically define the correctly rounded value that `sin` should be returning so that it is always the same no matter which runtime platform you compute it with yet a fast algorithm to perform such computation does not exist So a pragmatic tradeoff is to require that the `sin` returns the correct value up to the last bit For that purpose multiple fast algorithms exist so different runtimes use different such algos producing different results in the last bit just as expected

ephemient · Answer

right I wasn t trying to say FMA had anything to do with this just that there s multiple reasons not to expect exactly equal floating point results in general

ephemient · Answer

I don t know if the JVM will perform that optimization either but LLVM seems happy to

elizarov · Answer

In fact the story with JS runtimes is way more funnier For example the initial implementation of V8 by Google wanted to claim the title of the fastest JS runtime Back then the certain benchmark that was popular to measure which JS runtime is the best basically measured how fast `sin` `cos` are working So V8 provided very fast yet very inaccurate implementation for `sin` `cos` with error not just in the last bit as customary but really being very far off Of course they had to fix it when people stared using V8 for real stuff but the title of the fastest JS engine was already won so it was not a problem anymore

elizarov · Answer

< ephemient> They just simply use totally different algorithms E g JVM runtime has its own sin cos code JS runtimes use something else Kotlin Native for example just uses the implementation from libc

ephemient · Answer

yes and I posted links to the implementations previously

elizarov · Answer

Right And the spec only requires them to be correct up to the last bit

ephemient · Answer

I am not actually sure about JS the latest spec I can find simply says that `sin` and `cos` are implementation approximated so there doesn t seem to be a guarantee about the number of bits of accuracy

elizarov · Answer

However this is not to be confused with regular arithmetics addition multiplication division These operations must produce the correctly rounded result so it will be really the same all the time and for chains of such operations whether FMA is used in the optimized code actually matters

elizarov · Answer

Yes JS spec is still loose yet in practice they ll have to provide at most 1 ulp of error guarantee or it ll be impossible to run any serious physics computation for example that s how people discovered the original V8 performance trick

ephemient · Answer

chains of regular arithmetic had observable non `strictfp` differences across platforms at some point in the past didn t they not anymore on JVM but LLVM is happy to optimize those chains to produce different results depending on optimization level and target

elizarov · Answer

Yes LLVM is basically designed as a backend for C C++ which allows for a lot of optimization freedom including judicious use of FMA reordering etc Even without FMA floating point arithmetics is simply not associative so a+b +c = a+ b+c in general case Java spec was always way stricter in what kind of optimizations are allowed thus floating point code on JVM is usually much slower than optimized floating point code on LLVM

elizarov · Answer

That is Java spec is strict even in non strictfp mode So they ve actually deprecated strictfp because nowadays with SSE instructions available everywhere it does not matter anymore