Message6675

Author malte
Recipients atorralba, florian, guillem, jendrik, malte, silvan
Date 2017-12-01.12:00:56
Content
Jendrik, we have long decided that the 32-bit build will go away. It is just a
question of when. Indefinite deprecation is not an option. We are happy to hear
everyone's concerns about this decision and discuss how to address them, but
this is not going to change the decision.

The most critical reason why we made this decision was that 32-bit CPLEX has
been discontinued, and it is not really possible to continue using the old
versions unless you already happen to have a working old version of the code
lying around on some machines and are happy to never touch the software stack of
these machines (or move to newer machines) ever again. This is by far not the
only reason (others include the huge effort needed to support 32-bits especially
with the library dependencies and cross-platform builds and the way they
complicate the build instructions by requiring obscure cross-compiling
libraries), but it was the straw that broke the camel's necks.

I should also point out that the reason we still have a 32-bit build is not
"mainly because of the memory performance", but *only* because of memory. The
64-bit build was already faster than the 32-bit build in 2011, and the numbers
I've seen since then have agreed with this. (However, I haven't seen many
numbers, something we should perhaps address.)


Alvaro, the core data structures within Fast Downward used to heavily rely on
pointers, but we have started to replace them one by one by things that are less
wasteful with memory when compiled in 64-bit mode. More details on this are in
issue213. It's been a large effort (issue213 is now six years old, and we've
been chipping away at it for a good chunk of that time), but we're now mostly there.

One of the early examples of this was the mechanism for storing state data,
which used to be based on individual vectors of state data for each state and is
now based on large contiguous bins of packed integers. Another example of this
are the hash tables used to store the state registry, where we have to stop
using std::unordered_map and roll our own instead.

I hope that memory-efficient BDD libraries for 64-bit builds already exist,
given that 64 bits are now ubiquitous. It's been a while since I last looked
into BDD library implementations, but back then the ones I looked at didn't use
pointers internally anyway and would have been fine in 64-bit builds. If this is
no longer case, it is really up to the people providing these library
implementations to step up and modernize their code. "If you want to use our
library, don't compile a 64-bit executable" is not an acceptable stance any more
these days.

When our own changes to make the code more 64-bit friendly are done and we are
happy with the memory performance, we will remove the 32-bit options from cmake.
The removal will perhaps not happen overnight, but I don't think we will wait
for a long time before doing it. Of course it will be possible for forks of  the
code to keep these options in, and they will continue to work for the
foreseeable future if the LP code is not used.

The only scenario where I can see this decision changed is if someone interested
in championing 32-bit builds step up to take over the support of 32-bit builds.
This mainly entails taking charge of the cmake files, documentation, and 32-bit
build slaves.
History
Date User Action Args
2017-12-01 12:00:56maltesetmessageid: <1512126056.09.0.62056896931.issue754@unibas.ch>
2017-12-01 12:00:56maltesetrecipients: + malte, jendrik, silvan, atorralba, florian, guillem
2017-12-01 12:00:56maltelinkissue754 messages
2017-12-01 12:00:56maltecreate