Hi,
Am 26.09.20 um 19:22 schrieb Michael Meeks:
>> With the expense of overhauling the whole package, merging all those
>> libs into
> Yep, would suck. Of course if it is 2x as fast perhaps worth looking
> at but we need numbers.
Yeah, and then it works only on amd64 and has problems on ot
On 26/09/2020 08:24, Rene Engelhard wrote:
> Am 25.09.20 um 12:54 schrieb Michael Meeks:
>> I wonder if, ABI-wise, we could static link sal with libmerged for the
>> purpose of LTO and get away with it =)
>
> I disagree.
=)
>> Since there is no real C++ ABI, and no exported s
Am 25.09.20 um 12:54 schrieb Michael Meeks:
> I wonder if, ABI-wise, we could static link sal with libmerged for the
> purpose of LTO and get away with it =)
I disagree.
> Since there is no real C++ ABI, and no exported symbols, particuarly
> exceptions there - that could work across
On Fri, 25 Sep 2020 at 17:20, Luboš Luňák wrote:
> On Friday 25 of September 2020, Michael Meeks wrote:
> > resolve those through the symlink to the same library loaded once -
> Yes, that would work on Linux. Not on Windows though, it seems symbols
> get
> bound to a specific DLL name.
>
>
The
On Friday 25 of September 2020, Michael Meeks wrote:
> I wonder if (assuming we still believe that C++ UNO plugins exists as a
> 'thing' ;-) We could try on Linux increasing libmerged to include all of
> the lower base code - too - and (perhaps) - symlink it to all of the old
> library names.
Hi Michael,
Michael Meeks wrote:
> I wonder if (assuming we still believe that C++ UNO plugins exists as a
> 'thing' ;-)
>
They _do_ exist. ;)
> We could try on Linux increasing libmerged to include all of
> the lower base code - too - and (perhaps) - symlink it to all of the old
> library
On Friday 25 of September 2020, Tor Lillqvist wrote:
> Would it be simpler if we didn't have a separate gb_LTOFLAGS but simply
> added the LTO flags into $CC and $CXX (or $CFLAGS)?
>
> I think that at least with Apple's linker, using "Thin" LTO (
> https://blog.llvm.org/posts/2016-06-21-thinlto-sca
>
> No, just the merged library. Would be nice to use it in externals too, but
> that would probably require fiddling with the
> various external build systems to pass in the necessary flags and
> workaround the consequent bugs.
>
Would it be simpler if we didn't have a separate gb_LTOFLAGS but si
On 2020/09/25 9:49 am, Luboš Luňák wrote:
On Friday 25 of September 2020, Noel Grandin wrote:
No, just the merged library.
So we do not use LTO even for our other libraries? Building all of them with
LTO would be most probably a waste of time, but e.g. for things like libsc it
could very
On Friday 25 of September 2020, Noel Grandin wrote:
> On 2020/09/23 3:49 pm, Tor Lillqvist wrote:
> > By the way, did you manage to get all external libraries to get built
> > using LTO, too? Or just what goes into our merged library? As far as I
> > see, we use gb_LTOFLAGS only in three ExternalPr
On 2020/09/23 3:49 pm, Tor Lillqvist wrote:
By the way, did you manage to get all external libraries to get built using LTO, too? Or just what goes into our merged
library? As far as I see, we use gb_LTOFLAGS only in three ExternalProject_foo.mk files. Should it be used in them all?
Should we
Hi,
Am 23.09.20 um 15:49 schrieb Tor Lillqvist:
> By the way, did you manage to get all external libraries to get built
> using LTO, too? Or just what goes into our merged library? As far as I
> see, we use gb_LTOFLAGS only in three ExternalProject_foo.mk files.
> Should it be used in them all? Sh
By the way, did you manage to get all external libraries to get built using
LTO, too? Or just what goes into our merged library? As far as I see, we
use gb_LTOFLAGS only in three ExternalProject_foo.mk files. Should it be
used in them all? Should we append gb_LTOFLAGS to CC and CXX instead of
keepi
On Wed, 23 Sep 2020 at 11:08, Tor Lillqvist wrote:
> I am a bit disappointed that you didn't see more speedup, but that depends
>> on the input data surely.
>>
>
>
>
Yes, the loading for that particular test file has already been pretty
thoroughly optimised.
But then it's good to see that LTO c
>
>
> I must admit, I'm a little surprised the code is larger, I would have
> thought LTO would have had more opportunity to merge code.
>
But it also has the opportunity to inline code from other compilation units.
I am a bit disappointed that you didn't see more speedup, but that depends
on the
Hi
On Mon, 21 Sep 2020 at 08:22, Miklos Vajna wrote:
> Do you have any numbers on if this helps e.g. startup performance?
>
>
instdir/program contains
merged 368M
LTO375M
size of mergedlo.dll (in bytes)
merged 79 109 632
LTO82 043 904
loading fairly large calc file
time OOO_DI
Hi Noel,
On Fri, Sep 18, 2020 at 09:59:37AM +0200, Noel Grandin
wrote:
> LTO with --enable-mergelibs is now working (for me) on Windows.
>
> This is with
> current master
> Windows 10 19041.508
> Microsoft Visual Studio Community Edition 2019 16.7.3
>
> Note that the peak memory usage is
Hi
LTO with --enable-mergelibs is now working (for me) on Windows.
This is with
current master
Windows 10 19041.508
Microsoft Visual Studio Community Edition 2019 16.7.3
Note that the peak memory usage is around 12G when linking the merged DLL.
Might be worth switching daily builds to use
18 matches
Mail list logo
