Hi Ulf,
On 14.11.22 17:37, Ulf Hermann via Development wrote:
> Hi Marc,
>
>> On 11.11.22 09:35, Ulf Hermann via Development wrote:
>>> There is an undeniable benefit of _offering_ QSpan, QStringView, and
>>> generator APIs in a few relevant cases:
>>>
>>> 1. Users want to pass a "foreign" container to a Qt function that
>>> doesn't only store it as QList or QString. It might merely iterate it or
>>> store it as something else.
>>
>> The assumption that there's a problem only for "foreign containers" is
>> incorrect: Take the native Qt container QString as an example. See
>> assembly in my QAnyStringView blog post:
>> https://www.qt.io/blog/qstringview-diaries-qanystringview You have this
>> problem as soon as you pass constant data, which is a common enough
>> use-case to warrant optimizing for.
>
> My point is the "doesn't only store it as QList or QString" and
> "foreign" is in quotes quite on purpose. Maybe that wasn't clear enough,
> though.
>
> So, if the method immediately converts whatever it gets to QList or
> QString, then there is no point in passing it a span or view.
My point is that there _is_. Citing my blog post:
callConsumeQStringHelloWorld():
pushq %rbp
movl $12, %esi
leaq .LC76(%rip), %rdx
subq $32, %rsp
movq %rsp, %rbp
movq %rbp, %rdi
call QString::fromUtf8(QByteArrayView)@PLT
movq %rbp, %rdi
call consumeQString(QString const&)@PLT
movq (%rsp), %rax
testq %rax, %rax
je .L834
lock subl $1, (%rax)
je .L839
.L834:
addq $32, %rsp
popq %rbp
ret
.L839:
movq (%rsp), %rdi
movl $8, %edx
movl $2, %esi
call QArrayData::deallocate(QArrayData*, long long, long
long)@PLT
addq $32, %rsp
popq %rbp
ret
callConsumeQStringViewHelloWorld():
leaq .L.str.3401(%rip), %rsi
movl $12, %edi
jmp consumeQStringView(QStringView)@PLT # TAILCALL
It matters whether the QString/QList creation is in front of or behind
the ABI boundary. The size of the tst_qsettings executable for Clang
builds went down by >10% when the API was switched over to
QAnyStringView, without any changes to the test code itself (and
QAnyStringView hasn't even got the size/tag swap that Thiago pointed out
and that would make it require less gargantuan immediate values):
https://codereview.qt-project.org/c/qt/qtbase/+/353688
Sure, the sequence of assembler instructions is the same, but improved
code locality means it'll also execute a bit faster. Also, if we can
condense user code by 10% without changes to their code, then some users
may have an easier time right-sizing their embedded hardware, e.g.
Finally, to give you the very big picture: we have a duty to avoid
inflicting such egregiously inefficient code on the world. This bloat
needs to be stored: on disk, in RAM, in cache. At each of these levels,
the extra storage causes some pJ extra energy use, billions of times
over, causing corresponding CO2 emissions.
The German government has started dealing out the well-known "blue
angel" certificates for software now. Customers will eventually demand
our help in getting the energy use of their software down so they can be
certified.
We can, of course, ostrich on. But Qt is in a unique position, as a C++
native UI framework, to assist users in meeting climate goals. Think
about it: Would projects that prefer programmer productivity over
resource use inflict C++ on their programmers? Won't such projects
rather (continue to) use Java and HTML, shipping applications with a
bundled chromium to run a few HTML/JS apps in GiBs of memory instead of
MiBs (hello, MS Teams!)? To me, it sounds more logical that projects
that inflict C++ on their developers would be those projects that need
to meet resource usage goals (because of right-sizing of embedded
hardware or because they want to get certified as energy-efficient). And
all this talk about convenience trumping efficiency is going to raise
eyebrows in such projects.
Let's make C++ easy to use, for sure. But, sorry, using spans isn't
difficult. Don't confuse familiarity with simplicity.
Thanks,
Marc
--
Marc Mutz <marc.m...@qt.io>
Principal Software Engineer
The Qt Company
Erich-Thilo-Str. 10 12489
Berlin, Germany
www.qt.io
Geschäftsführer: Mika Pälsi, Juha Varelius, Jouni Lintunen
Sitz der Gesellschaft: Berlin,
Registergericht: Amtsgericht Charlottenburg,
HRB 144331 B
_______________________________________________
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
