Re: [Development] Why we *have to* remove codecFor... ?
On Fri, Jun 8, 2012 at 1:15 AM, lars.kn...@nokia.com wrote: Do we need this for every file, or is one entry in qglobal.h enough? One entry in qglobal.h is enough. As another solution, are there any compiler flags one can set to tell MSVC about the input encoding? If yes, we can simply add that to the qmake.conf for msvc. As far as I know, no such option exists for MSVC. -- Debao ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Why we *have to* remove codecFor... ?
On sábado, 9 de junho de 2012 01.42.21, 1+1=2 wrote: Do we need this for every file, or is one entry in qglobal.h enough? One entry in qglobal.h is enough. It's also weird. The option should be the input charset, not the execution charset. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Intel Sweden AB - Registration Number: 556189-6027 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Changing container privates again
Hello
Moving the discussion from the series of patches I've begun on Gerrit to the
ML.
tl;dr: all I wanted was to add the prepend optimisation to QVector so I could
work on QList. Then João told me of a request by Tor Arne about letting
QString have a notify of destruction function. So I changed the internals of
QArrayData again.
Current QArrayData is:
struct Q_CORE_EXPORT QArrayData
{
QtPrivate::RefCount ref;
int size;
uint alloc : 31;
uint capacityReserved : 1;
qptrdiff offset; // in bytes from beginning of header
[ member functions ]
};
Size is 3*4 + maybe padding + pointer size = 16 bytes or 24 bytes
After my changes, it is:
struct Q_CORE_EXPORT QArrayData
{
QtPrivate::RefCount ref;
uint flags;
int size; // ### move to the main class body?
// -- 4 bytes padding here on 64-bit systems --
qptrdiff offset; // in bytes from beginning of header
// size is 16 / 24 bytes
};
struct QArrayAllocatedData : public QArrayData
{
uint alloc;
// 4 bytes tail padding on 64-bit systems
// size is 20 / 32 bytes
};
struct QArrayForeignData : public QArrayData
{
void *token;
void (*notifyFunction)(void *);
// size is 24 / 40 bytes
};
The changes are:
- instead of a single bit of flags, there's a full integer now (32 bits),
which allow us to to more things.
- I've reserved 3 of those bits to indicate the type of array: raw data (like
QStringLiteral and fromRawData), heap-allocated data, foreign data.
- foreign data is like fromRawData: it comes from somewhere else, we don't
manage its memory and it's immutable. The difference is that we'll call a
notify function (see above) when our refcount drops to zero. This allows, for
example, to use QString on data managed by WTF::String or UTF-16 data stored
in an mmap'ed page.
- the alloc member is moved from the standard data to the allocated data
(it makes sense). This member should only ever be accessed in non-const
functions (more or less, there are exceptions), usually after those functions
have decided that they need to allocate or reallocate memory.
- as a drawback, the header overhead in memory allocation increases 4 bytes
on 32-bit systems and 8 bytes on 64-bit ones (due to the presence of tail
padding). It's possible to store data in that tail padding, though, but I
don't want to .
- in fact, I was thinking of changing the size and alloc members to size_t,
so this header could be used on a container supporting larger memory sizes, if
we wanted to, in the future.
- André requested that the size member be moved away from the header into the
main class body itself. I haven't done that yet and I'm not sure I should. It
would be major surgery for something that we haven't proven yet. And I don't
think we have time to prove it. But it would decrease the size of the header
by 8 bytes on 64-bit systems.
- since we stored the type of the data, we know when we allocated it. Since
we know that and we know the size of the header, the offset member becomes
the prepend optimisation: we know how much buffer we have between the end of
the header and the beginning of the data.
Besides all that, there are a bunch of small changes. Before we discuss the
minor changes and implementation details (whether we need one or two option
enums, for example), I'd like to know if anyone has more ideas relating to the
headers themselves.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Intel Sweden AB - Registration Number: 556189-6027
Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden
signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Changing container privates again
On Saturday 09 June 2012 17:45:01 Thiago Macieira wrote:
Hello
Moving the discussion from the series of patches I've begun on Gerrit to the
ML.
tl;dr: all I wanted was to add the prepend optimisation to QVector so I
could work on QList. Then João told me of a request by Tor Arne about
letting QString have a notify of destruction function. So I changed the
internals of QArrayData again.
I suggest re-ordering the offset in order to avoid padding.
struct Q_CORE_EXPORT QArrayData
{
QtPrivate::RefCount ref;
uint flags;
qptrdiff offset; // in bytes from beginning of header
int size; // ### move to the main class body?
// 4 byte tail padding on 64 bits
};
// size is 16 / 24 bytes (but really 20 bytes as we could use the tail padding
to put the payload already)
struct QArrayAllocatedData : public QArrayData
{
uint alloc;
};
// size is 20 / 24 bytes (the tail padding bytes are used)
struct QArrayForeignData : public QArrayData
{
void *token;
void (*notifyFunction)(void *);
// size is 24 / 40 bytes
};
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Changing container privates again
On sábado, 9 de junho de 2012 19.15.09, Olivier Goffart wrote:
I suggest re-ordering the offset in order to avoid padding.
It doesn't help.
struct Q_CORE_EXPORT QArrayData
{
QtPrivate::RefCount ref;
uint flags;
qptrdiff offset; // in bytes from beginning of header
int size; // ### move to the main class body?
// 4 byte tail padding on 64 bits
};
// size is 16 / 24 bytes (but really 20 bytes as we could use the tail
padding to put the payload already)
struct QArrayAllocatedData : public QArrayData
{
uint alloc;
};
// size is 20 / 24 bytes (the tail padding bytes are used)
The size here is 20 / 32 bytes. The tail padding bytes are not used.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Intel Sweden AB - Registration Number: 556189-6027
Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden
signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Changing container privates again
On Saturday 09 June 2012 19:19:41 Thiago Macieira wrote:
On sábado, 9 de junho de 2012 19.15.09, Olivier Goffart wrote:
I suggest re-ordering the offset in order to avoid padding.
It doesn't help.
struct Q_CORE_EXPORT QArrayData
{
QtPrivate::RefCount ref;
uint flags;
qptrdiff offset; // in bytes from beginning of header
int size; // ### move to the main class body?
// 4 byte tail padding on 64 bits
};
// size is 16 / 24 bytes (but really 20 bytes as we could use the tail
padding to put the payload already)
struct QArrayAllocatedData : public QArrayData
{
uint alloc;
};
// size is 20 / 24 bytes (the tail padding bytes are used)
The size here is 20 / 32 bytes. The tail padding bytes are not used.
Ah right... I tought that when inheriting, the padding was used. I was
mistaken.
Then, one can put back 'alloc' in QArrayData
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Changing container privates again
On sábado, 9 de junho de 2012 19.31.09, Olivier Goffart wrote: Then, one can put back 'alloc' in QArrayData It's not worth it. It increases the size of the 32-bit structure and leaves us at a weird boundary on 64-bit ones. 32 bytes is actually good. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Intel Sweden AB - Registration Number: 556189-6027 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Changing container privates again
On sábado, 9 de junho de 2012 21.42.55, André Pönitz wrote:
My gut feeling says there is a sweet spot at 16 byte object size,
with direct pointer to the raw data, and size member and some
sensible use of the extra bits.
Agreed, but it's 16 bytes on 64-bit architectures. On 32-bit ones, it would
have to be 8 or 12, preferably the smaller one (i.e., keep it to two
registers).
Whether this is needed, or whether the cheap substrings are a
sufficient replacement for the cases where QStringRef currently
is actively used, and what the actual impact is something that
I don't know. Spending a thought or two doesn't seem to hurt,
though.
Cheap substrings can be achieved with from fromRawData provided we also move
the size into the main class. That's relatively easy to do (compared to the
full proposal), but even this change might not be doable in the time frame we
have.
What's more, those cheap substrings, if they are still QStrings, they pose two
problems: since they become indistinguishable from regular, users may leak
them past the lifetime of the original string, and the zero termination will
not be present.
Also, I'm extremely against an encoded anything in order to save bits. Using
sign bits and other hacks will possibly bite us in our backs because it makes
other things slower.
If I had enough time to redesign, I think I'd start with:
class QVector / QByteArray / QString
{
Data *d;
uint flags;
int size;
};
struct Data
{
qptrdiff offset;
};
struct AllocatedData : public Data
{
QRefCount ref;
int alloc;
};
The unsharable and immutable types would be in the flags member in the main
class. This way, QStringLiterals and other literals would have a 4-byte
overhead.
Right now, before doing a refcount up or down, we already need to fetch the
value and verify if it's not one of the non-counted types (btw, it does two
comparisons instead of one). So checking the flags in the main object's body
would be no worse.
A drawback on this design is that both types of data produce misalignments,
but that's fixable by wasting some more bytes.
It's either this design or the one with the flags in the private, which would
produce a 8 or 16-byte private.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Intel Sweden AB - Registration Number: 556189-6027
Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden
signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] FW: Alpha 2 this week or skip it
vs2010 is OK, but vs2012 RC failed, I just want to try win32-msvc11. 2012/6/10 Thiago Macieira thiago.macie...@intel.com: On domingo, 10 de junho de 2012 01.53.10, techabc wrote: It seems that no more alpha 2 comes to the world. I wish upcoming beta would full pass compile of Visual Studio 2010 RC. What do you mean by 2010 RC? Why don't you use the released version? I compiled with VS 2010 and it worked fine. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Intel Sweden AB - Registration Number: 556189-6027 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Why we *have to* remove codecFor... ?
On Sat, Jun 9, 2012 at 1:54 AM, Thiago Macieira thiago.macie...@intel.com wrote: On sábado, 9 de junho de 2012 01.42.21, 1+1=2 wrote: Do we need this for every file, or is one entry in qglobal.h enough? One entry in qglobal.h is enough. It's also weird. The option should be the input charset, not the execution charset. Rules of MSVC's input-charset: If BOM exists, associated encoding is used as the input-chaset If no BOM exists, locale encoding is used as the input-chaset. locale encoding can be specified by @ #pragma setlocale(...) @ But there is not UTF-8 locale under Windows. Debao ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
