### clyring's blog

By clyring, history, 7 weeks ago,

I haven't seen any announcement about this and only found out when I saw that my stupid non-Int64 submission 137642072 to problem C in today's round didn't fail pretests. But maybe some of you would like to know.

Performance-wise, I think it's probably a nice win for some problems but not that significant overall. The convenience of not having to import Int64 and fiddle with explicit conversions or so frequently ask myself if one of the 'unimportant' constraints I don't have at top-of-mind will cause Int overflow will definitely be appreciated, though.

On the plus side: Arithmetic with large integers is presumably 2-3x faster now. Also, in my experience, Int64-related class methods often lack the performant specializations and rewrite rules available for their Int counterparts, and Int64 values tend to be unboxed less aggressively on 32-bit systems, all of which made awkward using efficiently the type. GHC's pointer-tagging magic will also probably work better for some types now, but I think this is uncommon.

On the minus side: The higher memory use that comes with 64-bit is probably relatively pronounced with Haskell. Typically, only ByteString and UArray contents (and similar) are actually stored in a packed unboxed format, and these are quite limited in what they can store. (StorableArray is more flexible in this regard, but it doesn't come shipped with an immutable wrapper, so it's inconvenient to use outside of an IO context. And unboxed Vectors are just not available on Codeforces for now.) GHC prior to 9.2.1 doesn't have any built-in support for user-defined fields smaller than the machine word size, so almost everything else will double in size. (And the same goes if your UArrays are storing Int instead of Int32.)

Thanks to the Codeforces team for making this happen!

• +70

 » 7 weeks ago, # |   +22 It's great that 64-bit upgrades are silently coming for different compilers. The newly added "Rust 1.56.1, edition 2021" appears to be 64-bit too.
 » 7 weeks ago, # |   +8 I also noticed this ~2 weeks ago in a similar way. I wish Codeforces had a public tracker/changelog so that changes didn't go unnoticed by users.Another minor point on the plus side is that we can now store 64-bit ints in IntSet or IntMap.In case someone from the Codeforces team is reading, I would also like to request adding the vector, vector-algorithms and random libraries. For instance, AtCoder supports these, and a few more. In any case, thank you for this update, it makes a lot of things faster.
•  » » 7 weeks ago, # ^ |   0 Oh, yeah. Now that you mention the IntSet and IntMap issues I recall the maxBound :: Int limit on the size of some containers is also sometimes inconvenient. I remember failing 1360H - Binary Median in a virtual contest because I couldn't create a Data.Sequence.Seq with length $2^{60}$. Now that same hastily-written code can pass. Compare 81330206 with 137740360.
•  » » » 6 weeks ago, # ^ |   0 That's neat :D
•  » » 7 weeks ago, # ^ |   -11 Also can we have atcoder library for c++? Three Revolutions of AtCoder / AtCoder Library