[Qt5-feedback] Real 64 Bit support ?

[André Pönitz]

On Thursday 12 May 2011 14:53:28 ext Yves Bailly wrote:
> Le 12/05/2011 14:42, André Pönitz a écrit :
> > On Thursday 12 May 2011 13:58:48 ext Keith Gardner wrote:
> >> I would also like to see this. On top of a 64-bit build, I would like to see
> >> the container classes (QVector, QList, etc...) have a qint64 to index the
> >> values instead of a qint32.
> >
> > qint64 is expensive on (at least some) 32 bit machines.
> 
> True.
> 
> > Having _different_ sizes (32/64 bit) depending on architecture spoils
> > cross-platform data exchange using e.g. QDataStream. So that's even
> > less of an option.
> 
> Data exchange implies serializing things in a very controlled way, isn't it?
> I avoid sending a mere "int" through a QDataStream, I always cast it to a
> known-size type, e.g. int32_t or int64_t (depending on the needs). I would
> treat "size_t" just the same way, so no data exchange problem.

Right now we can push in a QVector on one side and pull it out on the other
side without problem, and without caring who the other side is. That is _very_
convenient, especially when the "other side" is some file on some file server
that is accessed by machines with different architectures.

With different size types we would end up in a situation where one machine
can push data that can't be handled by the receiver side. Not Nice(tm)

> > Having 31 bit for sizes is definitely "good enough" for all kinds of
> > "mainstream" use cases.
> 
> True (mostly).
> 
> >>> For what it worths, I totally second this: true 64bits support is a real
> >>> need, having to manage really huge datasets - here "huge" can mean
> >>> far more than 4GB.
> >
> > On a quick glance, I think the limit can be raised to only affect the item
> > count, not the size by changing two lines in QVectorData::malloc and grow.
> >
> > For 'double' data the size limit would be 16 GB then, and I am pretty sure
> > you would have switched to non-shared container long before that.
> 
> Actually it wasn't about the index type, just about the memory available to
> the running program. Imagine a big hash table, a deep bounding volumes hierarchy,
> to operate on millions of triangles: for sure 32bits is enough to index each
> object, but the whole complex, cross-inter-related structure can eat lots of
> GB of RAM - more than a 32bits program can handle.

For total memory there is no conceptual restriction at all. Pointers are 
already 64 bit on the supported 64 bit architectures.

Having 32 bit indices on 64 bit architectures even has "non-historical"
benefits. A struct { T *data; int size; int alloc; } nicely fits into 16 bytes.
Three pointers do not.

Andre'