Update: The current settings of 1.9 should run at least as fast as the previous Kotlin 1.6.
Dear codeforces and MikeMirzayanov,
Please restore Kotlin 1.6.
This issue could be serious enough to end my CP career.
The short story is that Kotlin 1.6 is the only 32-bit version. Without Kotlin 1.6 we must submit in 64bits, and in many situations this will be too slow.
As the only 32 bits version available of the language, it should not have been removed to begin with.
After using the exact language version on Round 920 (Div.3) having decent success, I found that I was unable to submit in Kotlin 1.6: It seems that Kotlin version 1.6 had been removed.
If this is a mistake, please restore it. If this is simply the result of having three languages versions being too much: You could probably remove 1.7.20, as 1.9.21 seems to be superior in every way.
The version 1.6, — more precisely, the 32 bits environment and the associated JVM settings/ versions etc.. Are critical to viability to use Kotlin on codeforces. I still find 1.6 to be consistently the fastest version, and will only use 1.7/1.9 on specific situations (e.g. during 64 bits operations). On solutions that heavily uses boxed integers i.e. MutableList (which is necessary for the most convenient solutions), Kotlin 1.6 runs two or three times faster. Even without those, the solution could still be anywhere from 20% to 50% slower.
This has been pointed out in a comment I wrote earlier, link. It had always been a serious fear of mine that codeforces would just drop Kotlin 1.6 randomly. I hope that codeforces can recognise how much differences this little bits of speed make: With 1.6, even if solutions that got TL can probably pass under a small optimisations. If 1.6 is not available, I can imagine situations where it is seriously difficult to pass an intended solution (especially when the TL was not made lenient for one reason or another), at least, without having multiple TLE penalties. An example that comes to my mind is 241859779 : my contest submission is 600ms, submission in 1.9 is 950ms, awfully close to TL.
I don't believe Kotlin 1.6 and 1.9 have the same speed: For a simple example, the solutions I submitted in the div3 round toady:
For most submissions they run in ~200ms, so the speed difference probably won't matter much as it is a constant initiation time. For the two problems that run more than that:
Problem F: 1.6, 1000ms 241743081, 1.9 , 1400ms 241859276 Problem G: 1.6, 400ms 241772417, 1.9 , 700ms 241859263
In conclusion, please restore Kotlin 1.6.
MikeMirzayanov
why did you removed java 8? It's the best version of the best programming language on this earth. The other versions of java are really slow and take almost 100-200ms more and as a beginner my codes are not very optimised, those 100-200ms more will cost me unnecessary TLE's. Please give back java 8 for submissions and remove java 21 if you want. More people use java 8 than any other versions of java available to submit.
It's like forcing people to use c++ and sometimes when I get tle I am not sure whether there's a problem in my approach or there's a problem with the language as I am a beginner, Java 8 prevented this situation. Please give back java 8. Majority of the java coders above 1500+ use java 8. Instead of giving extra time limit you are removing the optimised version.
A simple O(n) solution in java 17 takes 200ms while in java 8 it took 124ms.
I am only a noobie that uses kotlin but I submitted the same answer to a problem — 1.6 accepted, 1.7 and 1.9 TLE errors on both :( with exact same code. This problem wont garner much attention because kotlin is not too popular for competitive programing I think, but I for one will chip in with please please drop 1.7 and reinstate 1.6.
I have switched Kotlin 1.9 to use the JRE 8 32-bit. Now, all your example submissions on 1.9 are as fast as on 1.6, or even faster. Please conduct your benchmarks and share the results.
Additionally, I will reinstate Java 8 32-bit but will remove Java 11 and 17.
You see, I prefer not to maintain more than two versions for a single language (ideally, just one). Supporting additional versions introduces complexities. C++ is an exception due to its popularity. However, even with C++, when adding new versions, I find it necessary to phase out the oldest ones.
Thank you for the quick reply.
I have resubmitted about 30 solutions and they all seem to run slightly faster/ equally as fast in the new 1.9 compared to the old 1.6. There is only one exception and I could not figure out why (242001772, update: this is just due to uphack data). Anyways, it is consistent enough and I am very happy to use the current 1.9.
I agree that two versions should be enough, it just seems that for the particular case of Kotlin (and therefore I assume Java as well), having two versions is really needed: One in 32 bits, One in 64 bits. I have made many examples where 32 bits would be faster. For future reference, this FFT code (1e5 convolution 50 times, based on atcoder library) runs 4 times faster on 64bits (current Kotlin 1.7): (1.7, 1668ms 242002780), (1.9, 5974ms 242002776): Though, it is hard to say how much of the speed difference is exclusively due to 32 vs 64, as JVM versions definitely makes a difference.
All these is of course coming from my gut feeling that most of the speed differences can be explained with 32 vs 64. I did not actually seriously prove this so I could be wrong.
Can you add "64-bit" to the language name of Kotlin 1.7, and "32-bit" to the name of Kotlin 1.9? It would be useful to know which is which without having to refer to this blog post.
For reference, my submission 236811431 from the recent Kotlin Heroes round ACs in 3.5s on the old Kotlin 1.9, but resubmitting it (242017576) causes it to TLE (over 6s). Submitting on Kotlin 1.7 (242018008) still ACs with similar performance, so I think it would be useful to maintain one 32-bit version and one 64-bit version.
My testcase that TLE with 1.9 and was ok with 1.6 now runs almost half the speed of the 1.6 solution.
woop woop \o/
Thank you