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 Vector
s 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 UArray
s are storing Int
instead of Int32
.)
Thanks to the Codeforces team for making this happen!
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.
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
orIntMap
.In case someone from the Codeforces team is reading, I would also like to request adding the
vector
,vector-algorithms
andrandom
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.Oh, yeah. Now that you mention the
IntSet
andIntMap
issues I recall themaxBound :: 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 aData.Sequence.Seq
with length $$$2^{60}$$$. Now that same hastily-written code can pass. Compare 81330206 with 137740360.That's neat :D
Also can we have atcoder library for c++? Three Revolutions of AtCoder / AtCoder Library