Author malte
Recipients andrew.coles, erez, florian, jendrik, malte, silvia
Date 2016-12-12.13:14:08
So some good news and some bad news, then!

I assume the second "v1: m32-vs-m64" line should be "v3: m32-vs-m64"?

I understand the desire to make the new m64 version look good, but a base-m32
vs. v3-m64 comparison is not meaningful for the decision we have to make in this
issue. We want to make the m64 compile competitive with the m32 compile. It
doesn't really matter if the m64 compile of revision X is competitive with the
m32 compile of revision Y.

Regarding the coverage drops for bjolp and seq:

The drop for seq may be CPLEX's fault, so not sure if we can do much about it.
Still, this probably warrants a closer look. I'd be a bit surprised to see the
32-bit version of CPLEX do massively better than the 64-bit version. Are these
otherwise identical versions of CPLEX and OSI? Are these the versions we recommend?

The drop for bjolp surprised me a bit, so I had a look how it stores a landmark
data, and it uses a PerStateInformation<vector<bool>>, which is very wasteful
because we pay the vector overhead for every single state. For our state
representation, we moved from SegmentedVector to SegmentedArrayVector for this
reason, and it made a big difference. We should probably do a similar thing
here, i.e., have something like PerStateInformation optimized for same-size
arrays. (And because this is a vector<bool>, we additionally need to pack
individual bits.)
Date User Action Args
2016-12-12 13:14:08maltesetmessageid: <>
2016-12-12 13:14:08maltesetrecipients: + malte, erez, andrew.coles, silvia, jendrik, florian
2016-12-12 13:14:08maltelinkissue213 messages
2016-12-12 13:14:08maltecreate