On October 20, 2015 10:10:36 Knoll Lars <lars.kn...@theqtcompany.com> wrote:
> On 20/10/15 09:59, "Bubke Marco" <marco.bu...@theqtcompany.com> wrote: > >>On October 20, 2015 08:43:26 Thiago Macieira <thiago.macie...@intel.com> >>wrote: >> >>> On Tuesday 20 October 2015 09:44:23 Marc Mutz wrote: >>>> So if deep copies loose their ineffciency myth, what reason remains to >>>>not >>>> use QSV in all functions taking QString? >>> >>> Complicating the API. >>> >>> You cannot possibly prove that doing something O(n) is as efficient as >>>doing >>> something O(1), therefore there's no way that deep copies would be a >>>myth. >> >>We both know that depends on the size. The minimal size of what the CPU >>gets from the memory is a cache line. The size of a cache line today is >>typically 64 bytes. So as a minimum you always push that much data >>around. So if you use a atomic pointer on more than one cpu this cache >>lines has to be copied all the time. If you change something everything >>which depends on it has to be wait or recompute. So if you accidentally >>have data on the some cache line it is shared too. This is not very >>intuitive. Your application can be much slower because you accidentally >>share data. >> >>Okay that is simplified but we get the picture. And the worst part is >>that memory is so much slower in relation to cache access as it was for >>the difference between memory and hard disks in the paste. Today the >>difference between caches and memories resemble more that I learned about >>databases 20 years ago. And there you learned to be careful about the >>complexity notations which doesn't reason about different memory speeds. >> >>COW with strings can lead to more coping than simply coping the string >>because most strings are small. Sharing writeable cache lines between >>different cpu is asking for trouble but I think you know Amdahl's law >>https://en.wikipedia.org/wiki/Amdahl%27s_law. >> >>So why we don't measure it? Lets compile some applications with different >>implementation. Not simple ones. Maybe qtcreator would be a good idea. > > Experimenting with that is probably a good idea, but we certainly can’t > change away from COW any time soon. Maybe not ever because of > compatibility concerns. We should be careful not to get the new motif too. ;-) I think we have to find a middle ground again and again. It's a question of how much pain our actions are producing and how much our inactions. ;-) >> >> >>> COW may have comparable performance to deep copies if you consider the >>>whole >>> picture and code written properly. Our code was written for COW, so I >>>doubt >>> that you would get the same performance by suddenly making deep copies. >>> >>> To summarise: >>> >>> 1) I'm ok with adding QStringView >>> 2) I'm ok with using QStringView in applications, no restraints >>> 3) I'm ok with exploring the use in API, in parameters >>> 4) I'm ok with exploring it in return values, in very limited >>>conditions that >>> are being studied very well, ahead of time >>> >>> Exploring does not mean you can go and start adding overloads >>>everywhere. >> >>I think that's a very good approach. > > +1. > > Cheers, > Lars Sent from cellphone _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development