'New PACKAGERS_BUILD option for building Calligra'

[prev in list] [next in list] [prev in thread] [next in thread] 

List: kde-kimageshop
Subject: New PACKAGERS_BUILD option for building Calligra
From: Dmitry Kazakov <dimula73 () gmail ! com>
Date: 2012-12-04 7:54:41
Message-ID: CAEkBSfW0WLn+hs8vuwiVe9yQ3czhXQUEW6ekFUw8QRytas5Pbg () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]

Hello!

As you may already know right now I am working on making vector
optimizations for Krita work on different CPUs when distributed as a binary
package. To achieve this goal I used some cmake magic (borrowed from Vc
project ;) ) to produce multi-arch builds for the hottest parts of pigment
and Krita. That is a single .cpp file is compiled several times with
different compiller flags; the resulting .o files are put into a single .so
library (libpigmentcms.so) and the choice of the exact version of the code
occurs on the fly when the colorspaces are created.

This approach has several pros and cons and we need a kind of compromise
here, that is why I would like to ask for your opinion:

Pros:
1) We can have prebuild versions for all the architectures supported by Vc
(Amd XMA4 and XOP are not supported by Vc yet), it means we can
redistribute optimized binary version of Krita.

Cons:
1) Currently the code depends on Vc's 'staging' branch, so it can't be put
in master. For now all the changes are kept in
'vector_compositioning_kazakov' branch.
2) I used fat-binary approach for code generation. It means that all the
versions of the code are put into a single binary (libpigmentcms.so) and
therefore are loaded into user's RAM on the start. This is a matter of
excessive 3 MiB of user's RAM (libpigmentcms.so grew 15MiB -> 18MiB [1])
3) If we want the binary to be redistributable, the compiler optimization
for the rest of the code (not hotspots) must be disabled. In the benchmarks
it leads to a slight (~20%) performance degradation on *some* of the tests.
This is actually not much in comparison with the gain we get from using
vector instructions, but still...

In my opinion the mentioned disadvantages are not much serious. The only
concern I have is the size of the binary. The solution for it might be the
use of separate .so libraries for each implementation, but I guess (at
least for now) we can ignore it. 3MiB is not that much.

The problem of the speed degradation, I believe, cannot be (at least
easily) solved without distributing per-architecture compiled kritaimage.so
library. Each instance of this library takes 45MiB. Which leads to
additional 7*45=315MiB in the distribution package. That is not worth it.

Taking all this into account I decided to introduce a new option for the
Calligra build system: PACKAGERS_BUILD.

When the option is ON, the per-architecture builds are activated. The
optimization for all the other parts is disabled. This is exactly what is
needed by packagers.
When the option is OFF, the whole Calligra project is optimized for the
host CPU. No per-arch build are, therefore, done. This option is the best
choice for users who build Calligra themselves.

By default the option is OFF. It means that we need to tell packagers to
activate it. Where should I write about it? Do we have any packager's
manual?

I would appreciate any comments from you about this! :)

[1] - in commit message I told about the growth 11->17MiB. I was wrong
because measured it on the wrong binary.

-- 
Dmitry Kazakov

[Attachment #5 (text/html)]

Hello! As you may already know right now I am working on making vector \
optimizations for Krita work on different CPUs when distributed as a binary package. \
To achieve this goal I used some cmake magic (borrowed from Vc project ;) ) to \
produce multi-arch builds for the hottest parts of pigment and Krita. That is a \
single .cpp file is compiled several times with different compiller flags; the \
resulting .o files are put into a single .so library (libpigmentcms.so) and the \
choice of the exact version of the code occurs on the fly when the colorspaces are \
created. This approach has several pros and cons and we need a kind of \
compromise here, that is why I would like to ask for your opinion: Pros: 1) \
We can have prebuild versions for all the architectures supported by Vc (Amd XMA4 and \
XOP are not supported by Vc yet), it means we can redistribute optimized binary \
version of Krita. Cons: 1) Currently the code depends on Vc&#39;s \
&#39;staging&#39; branch, so it can&#39;t be put in master. For now all the changes \
are kept in &#39;vector_compositioning_kazakov&#39; branch. 2) I used fat-binary \
approach for code generation. It means that all the versions of the code are put into \
a single binary (libpigmentcms.so) and therefore are loaded into user&#39;s RAM on \
the start. This is a matter of excessive 3 MiB of user&#39;s RAM (libpigmentcms.so \
grew 15MiB -&gt; 18MiB [1]) 3) If we want the binary to be redistributable, the \
compiler optimization for the rest of the code (not hotspots) must be disabled. In \
the benchmarks it leads to a slight (~20%) performance degradation on *some* of the \
tests. This is actually not much in comparison with the gain we get from using vector \
instructions, but still... In my opinion the mentioned disadvantages are \
not much serious. The only concern I have is the size of the binary. The solution for \
it might be the use of separate .so libraries for each implementation, but I guess \
(at least for now) we can ignore it. 3MiB is not that much. The problem of \
the speed degradation, I believe, cannot be (at least easily) solved without \
distributing per-architecture compiled kritaimage.so library. Each instance of this \
library takes 45MiB. Which leads to additional 7*45=315MiB in the distribution \
package. That is not worth it. Taking all this into account I decided to \
introduce a new option for the Calligra build system: PACKAGERS_BUILD. When \
the option is ON, the per-architecture builds are activated. The optimization for all \
the other parts is disabled. This is exactly what is needed by packagers. When \
the option is OFF, the whole Calligra project is optimized for the host CPU. No \
per-arch build are, therefore, done. This option is the best choice for users who \
build Calligra themselves. By default the option is OFF. It means that we need \
to tell packagers to activate it. Where should I write about it? Do we have any \
packager&#39;s manual? I would appreciate any comments from you about this! \
:) [1] - in commit message I told about the growth 11-&gt;17MiB. I was \
wrong because measured it on the wrong binary. -- Dmitry Kazakov

_______________________________________________
kimageshop mailing list
kimageshop@kde.org
https://mail.kde.org/mailman/listinfo/kimageshop

[prev in list] [next in list] [prev in thread] [next in thread] 