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
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
Thanks to the Codeforces team for making this happen!