Re: port:libclang (and libLLVM)

[Jack Howarth]

On Thu, Mar 10, 2016 at 4:47 PM, René J.V.  wrote:
> On Thursday March 10 2016 14:24:00 Ryan Schmidt wrote:
>
>> > CMake does something similar for all 4 built-in presets, so the only way I 
>> > know to control the exact compiler flags is to set CMAKE_BUILD_TYPE to a 
>> > custom value. Debian/Ubuntu do that in their packaging scripts 
>> > (-DCMAKE_BUILD_TYPE=Debian); I've proposed a modified CMake PortGroup that 
>> > uses -DCMAKE_BUILD_TYPE=MacPorts (and parses configure.cppflags because 
>> > CMake doesn't have a dedicated variable for preprocessor options).
>>
>> If so, that would be yet another bug, or yet another broken-by-design 
>> feature, of cmake.
>
> I tend to agree, but it depends on how you look at the concept of presets ...
>

From http://opensource.apple.com/source/clang/clang-700.0.72/Makefile,
it appears that Apple builds llvm/clang at -O2 rather than -Os.

>> > Here's something much more interesting though: I just discovered that llvm 
>> > and clang 3.8 are both about TEN times smaller than they were in 3.6 and 
>> > 3.7:

The difference is that the builds of llvm prior to 3.8 release was
done with the configure based build system. The configure based build
was deprecated out in favor of the cmake build starting with 3.8.

$ du -k /opt/local/libexec/llvm-3.7/lib
...
1675924 /opt/local/libexec/llvm-3.7/lib

$ du -k /opt/local/libexec/llvm-3.8/lib
...
16 /opt/local/libexec/llvm-3.8/lib

This bloat in the prior releases is due to the default usage of
--enable-debug-symbols  in the configure build whereas the cmake build
defaults to the -debug variant.

> ...
>> >
>> > What's going on here??
>
>>
>> My llvm-3.4 is 436MB, llvm-3.7 765MB.
>
> Are those the tarball sizes, or the unpacked sizes?
>
>>
>> I don't know why mine are the size they are and yours are the size they are.
>
> Differences due to OS version and thus the used compiler?
>
>> You could untar your llvm-3.7 and llvm-3.7 and compare them to see where the 
>> size difference lies.
>
> You did notice that I repackaged the images as xz'ed tarballs, right? That 
> does make a considerable difference for llvm and clang.
>
> According to xz, the llvm-3.7 tarball is 1628.6Mb uncompressed, llvm-3.6 
> 1326Mb, llvm-3.8 107.3Mb . The llvm-3.8 destroot I just built (without shared 
> libllvm and without RTTI support, using MacPorts clang 3.7 and -O3 
> -march=native) is 387Mb.
>
> R.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: port:libclang (and libLLVM)

[René J . V . Bertin]

On Thursday March 10 2016 14:24:00 Ryan Schmidt wrote:

> > CMake does something similar for all 4 built-in presets, so the only way I 
> > know to control the exact compiler flags is to set CMAKE_BUILD_TYPE to a 
> > custom value. Debian/Ubuntu do that in their packaging scripts 
> > (-DCMAKE_BUILD_TYPE=Debian); I've proposed a modified CMake PortGroup that 
> > uses -DCMAKE_BUILD_TYPE=MacPorts (and parses configure.cppflags because 
> > CMake doesn't have a dedicated variable for preprocessor options).
> 
> If so, that would be yet another bug, or yet another broken-by-design 
> feature, of cmake.

I tend to agree, but it depends on how you look at the concept of presets ... 

> > Here's something much more interesting though: I just discovered that llvm 
> > and clang 3.8 are both about TEN times smaller than they were in 3.6 and 
> > 3.7:
...
> > 
> > What's going on here??

> 
> My llvm-3.4 is 436MB, llvm-3.7 765MB. 

Are those the tarball sizes, or the unpacked sizes?

> 
> I don't know why mine are the size they are and yours are the size they are.

Differences due to OS version and thus the used compiler?

> You could untar your llvm-3.7 and llvm-3.7 and compare them to see where the 
> size difference lies.

You did notice that I repackaged the images as xz'ed tarballs, right? That does 
make a considerable difference for llvm and clang.

According to xz, the llvm-3.7 tarball is 1628.6Mb uncompressed, llvm-3.6 
1326Mb, llvm-3.8 107.3Mb . The llvm-3.8 destroot I just built (without shared 
libllvm and without RTTI support, using MacPorts clang 3.7 and -O3 
-march=native) is 387Mb.

R.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: port:libclang (and libLLVM)

[Ryan Schmidt]

> On Mar 10, 2016, at 9:26 AM, René J.V. Bertin  wrote:
> 
> On Thursday March 10 2016 10:13:16 Jack Howarth wrote:
> 
>> A simple test with 'sudo port -d -s build llvm-3.8' reveals that -Os
>> is in fact used during the compiles on Intel. This is unsurprising as
>> MacPorts has standardized on -Os.
>> 
>> CFLAGS='-pipe -Os'
>> CXXFLAGS='-pipe -Os -std=c++11 -stdlib=libc++'
>> F90FLAGS='-pipe -Os -m64'
>> FCFLAGS='-pipe -Os -m64'
>> FFLAGS='-pipe -Os'
>> OBJCFLAGS='-pipe -Os'
>> OBJCXXFLAGS='-pipe -Os -stdlib=libc++'
> 
> Did you look at the actual compile commands? Again, cmake is used, and when 
> you generate a makefile with CMAKE_BUILD_TYPE=Release it will *append* the 
> preset compiler options to whatever is fetched from CFLAGS, CXXFLAGS, etc. It 
> is my experience that setting -O3 in CFLAGS or CXXFLAGS has no point, because 
> those presets will override it with -O2 .
> 
> CMake does something similar for all 4 built-in presets, so the only way I 
> know to control the exact compiler flags is to set CMAKE_BUILD_TYPE to a 
> custom value. Debian/Ubuntu do that in their packaging scripts 
> (-DCMAKE_BUILD_TYPE=Debian); I've proposed a modified CMake PortGroup that 
> uses -DCMAKE_BUILD_TYPE=MacPorts (and parses configure.cppflags because CMake 
> doesn't have a dedicated variable for preprocessor options).

If so, that would be yet another bug, or yet another broken-by-design feature, 
of cmake.


> Here's something much more interesting though: I just discovered that llvm 
> and clang 3.8 are both about TEN times smaller than they were in 3.6 and 3.7:
> 
> /opt/local/var/macports/software/llvm-3.6:
> total 158M
> 158M -rw-r--r--1 bertin admin 158M Nov 15 19:10 
> llvm-3.6-3.6.2_2.darwin_13.x86_64.txz
> 
> /opt/local/var/macports/software/llvm-3.7:
> total 188M
> 188M -rw-r--r--1 bertin admin 188M Jan  9 21:11 
> llvm-3.7-3.7.0_0.darwin_13.x86_64.txz
> 
> /opt/local/var/macports/software/llvm-3.8:
> total 15M
> 15M -rw-r--r--1 bertin admin 15M Mar 10 16:08 
> llvm-3.8-3.8-r262722_1.darwin_13.x86_64.txz
> 
> /opt/local/var/macports/software/clang-3.6:
> total 169M
> 169M -rw-r--r--1 bertin admin 169M Nov 15 19:17 
> clang-3.6-3.6.2_2+analyzer.darwin_13.x86_64.txz
> 
> /opt/local/var/macports/software/clang-3.7:
> total 182M
> 182M -rw-r--r--1 bertin admin 182M Jan  9 21:34 
> clang-3.7-3.7.0_2+analyzer.darwin_13.x86_64.txz
> 
> /opt/local/var/macports/software/clang-3.8:
> total 17M
> 17M -rw-r--r--1 bertin admin 17M Mar 10 16:14 
> clang-3.8-3.8-r262722_1+analyzer.darwin_13.x86_64.txz
> 
> 
> What's going on here??
> 
> If that means that building from source also takes comparatively less time 
> and resources I might be inclined to experiment with non-shared builds, or a 
> build without RTTI support (even if that apparently should account for no 
> more than 5% performance loss).

My llvm-3.4 is 436MB, llvm-3.7 765MB. 

I don't know why mine are the size they are and yours are the size they are.

You could untar your llvm-3.7 and llvm-3.7 and compare them to see where the 
size difference lies.

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: port:libclang (and libLLVM)

[Jack Howarth]

On Thu, Mar 10, 2016 at 10:26 AM, René J.V.  wrote:
> On Thursday March 10 2016 10:13:16 Jack Howarth wrote:
>
>> A simple test with 'sudo port -d -s build llvm-3.8' reveals that -Os
>> is in fact used during the compiles on Intel. This is unsurprising as
>> MacPorts has standardized on -Os.
>>
>> CFLAGS='-pipe -Os'
>> CXXFLAGS='-pipe -Os -std=c++11 -stdlib=libc++'
>> F90FLAGS='-pipe -Os -m64'
>> FCFLAGS='-pipe -Os -m64'
>> FFLAGS='-pipe -Os'
>> OBJCFLAGS='-pipe -Os'
>> OBJCXXFLAGS='-pipe -Os -stdlib=libc++'
>
> Did you look at the actual compile commands? Again, cmake is used, and when 
> you generate a makefile with CMAKE_BUILD_TYPE=Release it will *append* the 
> preset compiler options to whatever is fetched from CFLAGS, CXXFLAGS, etc. It 
> is my experience that setting -O3 in CFLAGS or CXXFLAGS has no point, because 
> those presets will override it with -O2 .


Of course I did...

DEBUG: Executing command line:  cd
"/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_llvm-3.8/llvm-3.8/work/build"
&& /opt/local/bin/cmake -DCMAKE_INSTALL_PREFIX=/opt/local
-DCMAKE_VERBOSE_MAKEFILE=ON -DCMAKE_COLOR_MAKEFILE=ON
-DCMAKE_BUILD_TYPE=Release -DCMAKE_BUILD_WITH_INSTALL_RPATH=ON
-DCMAKE_INSTALL_RPATH=/opt/local/lib
-DCMAKE_INSTALL_NAME_DIR=/opt/local/lib
-DCMAKE_SYSTEM_PREFIX_PATH="/opt/local;/usr"
-DCMAKE_MODULE_PATH=/opt/local/share/cmake/Modules
-DCMAKE_FIND_FRAMEWORK=LAST -Wno-dev -DLLVM_LINK_LLVM_DYLIB=ON
-DCMAKE_INSTALL_PREFIX="/opt/local/libexec/llvm-3.8"
-DLLVM_ENABLE_ASSERTIONS=OFF -DLLVM_ENABLE_RTTI=ON
-DLLVM_INCLUDE_TESTS=OFF -DLLVM_INCLUDE_EXAMPLES=OFF
-DLLVM_ENABLE_FFI=ON -DLLVM_BINDINGS_LIST=none
-DFFI_INCLUDE_DIR=/opt/local/include -DFFI_LIBRARY_DIR=/opt/local/lib
-DCMAKE_C_FLAGS_RELEASE="-DNDEBUG"
-DCMAKE_CXX_FLAGS_RELEASE="-DNDEBUG"
-DCMAKE_OSX_ARCHITECTURES="x86_64"
-DCMAKE_OSX_DEPLOYMENT_TARGET="10.11" -DCMAKE_OSX_SYSROOT="/"
../release_38

[  0%] Building CXX object
utils/TableGen/CMakeFiles/obj.llvm-tblgen.dir/AsmMatcherEmitter.cpp.o

cd 
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_llvm-3.8/llvm-3.8/work/build/utils/TableGen
&& 
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++
  -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS
-D__STDC_LIMIT_MACROS
-I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_llvm-3.8/llvm-3.8/work/build/utils/TableGen
-I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_llvm-3.8/llvm-3.8/work/release_38/utils/TableGen
-I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_llvm-3.8/llvm-3.8/work/build/include
-I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_llvm-3.8/llvm-3.8/work/release_38/include
 -pipe -Os -std=c++11 -stdlib=libc++  -fPIC
-fvisibility-inlines-hidden -Wall -W -Wno-unused-parameter
-Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic
-Wno-long-long -Wcovered-switch-default -Wnon-virtual-dtor
-Wdelete-non-virtual-dtor -std=c++11 -DNDEBUG -arch x86_64
-mmacosx-version-min=10.11-fno-exceptions -o
CMakeFiles/obj.llvm-tblgen.dir/AsmMatcherEmitter.cpp.o -c
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_llvm-3.8/llvm-3.8/work/release_38/utils/TableGen/AsmMatcherEmitter.cpp


>
> CMake does something similar for all 4 built-in presets, so the only way I 
> know to control the exact compiler flags is to set CMAKE_BUILD_TYPE to a 
> custom value. Debian/Ubuntu do that in their packaging scripts 
> (-DCMAKE_BUILD_TYPE=Debian); I've proposed a modified CMake PortGroup that 
> uses -DCMAKE_BUILD_TYPE=MacPorts (and parses configure.cppflags because CMake 
> doesn't have a dedicated variable for preprocessor options).
>
> Here's something much more interesting though: I just discovered that llvm 
> and clang 3.8 are both about TEN times smaller than they were in 3.6 and 3.7:
>
> /opt/local/var/macports/software/llvm-3.6:
> total 158M
> 158M -rw-r--r--1 bertin admin 158M Nov 15 19:10 
> llvm-3.6-3.6.2_2.darwin_13.x86_64.txz
>
> /opt/local/var/macports/software/llvm-3.7:
> total 188M
> 188M -rw-r--r--1 bertin admin 188M Jan  9 21:11 
> llvm-3.7-3.7.0_0.darwin_13.x86_64.txz
>
> /opt/local/var/macports/software/llvm-3.8:
> total 15M
> 15M -rw-r--r--1 bertin admin 15M Mar 10 16:08 
> llvm-3.8-3.8-r262722_1.darwin_13.x86_64.txz
>
> /opt/local/var/macports/software/clang-3.6:
> total 169M
> 169M -rw-r--r--1 bertin admin 169M Nov 15 19:17 
> clang-3.6-3.6.2_2+analyzer.darwin_13.x86_64.txz
>
> /opt/local/var/macports/software/clang-3.7:
> total 182M
> 182M -rw-r--r--1 bertin admin 182M Jan  9 21:34 
> clang-3.7-3.7.0_2+analyzer.darwin_13.x86_64.txz
>
> 

Re: port:libclang (and libLLVM)

[René J . V . Bertin]

On Thursday March 10 2016 10:13:16 Jack Howarth wrote:

> A simple test with 'sudo port -d -s build llvm-3.8' reveals that -Os
> is in fact used during the compiles on Intel. This is unsurprising as
> MacPorts has standardized on -Os.
> 
> CFLAGS='-pipe -Os'
> CXXFLAGS='-pipe -Os -std=c++11 -stdlib=libc++'
> F90FLAGS='-pipe -Os -m64'
> FCFLAGS='-pipe -Os -m64'
> FFLAGS='-pipe -Os'
> OBJCFLAGS='-pipe -Os'
> OBJCXXFLAGS='-pipe -Os -stdlib=libc++'

Did you look at the actual compile commands? Again, cmake is used, and when you 
generate a makefile with CMAKE_BUILD_TYPE=Release it will *append* the preset 
compiler options to whatever is fetched from CFLAGS, CXXFLAGS, etc. It is my 
experience that setting -O3 in CFLAGS or CXXFLAGS has no point, because those 
presets will override it with -O2 .

CMake does something similar for all 4 built-in presets, so the only way I know 
to control the exact compiler flags is to set CMAKE_BUILD_TYPE to a custom 
value. Debian/Ubuntu do that in their packaging scripts 
(-DCMAKE_BUILD_TYPE=Debian); I've proposed a modified CMake PortGroup that uses 
-DCMAKE_BUILD_TYPE=MacPorts (and parses configure.cppflags because CMake 
doesn't have a dedicated variable for preprocessor options).

Here's something much more interesting though: I just discovered that llvm and 
clang 3.8 are both about TEN times smaller than they were in 3.6 and 3.7:

/opt/local/var/macports/software/llvm-3.6:
total 158M
158M -rw-r--r--1 bertin admin 158M Nov 15 19:10 
llvm-3.6-3.6.2_2.darwin_13.x86_64.txz

/opt/local/var/macports/software/llvm-3.7:
total 188M
188M -rw-r--r--1 bertin admin 188M Jan  9 21:11 
llvm-3.7-3.7.0_0.darwin_13.x86_64.txz

/opt/local/var/macports/software/llvm-3.8:
total 15M
15M -rw-r--r--1 bertin admin 15M Mar 10 16:08 
llvm-3.8-3.8-r262722_1.darwin_13.x86_64.txz

/opt/local/var/macports/software/clang-3.6:
total 169M
169M -rw-r--r--1 bertin admin 169M Nov 15 19:17 
clang-3.6-3.6.2_2+analyzer.darwin_13.x86_64.txz

/opt/local/var/macports/software/clang-3.7:
total 182M
182M -rw-r--r--1 bertin admin 182M Jan  9 21:34 
clang-3.7-3.7.0_2+analyzer.darwin_13.x86_64.txz

/opt/local/var/macports/software/clang-3.8:
total 17M
17M -rw-r--r--1 bertin admin 17M Mar 10 16:14 
clang-3.8-3.8-r262722_1+analyzer.darwin_13.x86_64.txz


What's going on here??

If that means that building from source also takes comparatively less time and 
resources I might be inclined to experiment with non-shared builds, or a build 
without RTTI support (even if that apparently should account for no more than 
5% performance loss).

R
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: port:libclang (and libLLVM)

[Jack Howarth]

On Thu, Mar 10, 2016 at 7:33 AM, René J.V.  wrote:
> On Wednesday March 09 2016 20:48:19 Jack Howarth wrote:
>>> Why? My understanding is that the optimizations for -Os are equivalent
>>> to -O2 with the emphasis on size reduction. The additional
>>> optimizations from -O2 to -O3 would seem sufficient to produce a 10%
>>> execution optimization, no?
>>
>
> Actually, this point is moot : -Os is used only on PPC machines from what I 
> can see. Other architectures use whatever optimisation the build system 
> decides to use (which is an interesting question when that system is based on 
> CMake and you use one of the built-in BUILD_TYPE presets).
>

A simple test with 'sudo port -d -s build llvm-3.8' reveals that -Os
is in fact used during the compiles on Intel. This is unsurprising as
MacPorts has standardized on -Os.

CFLAGS='-pipe -Os'
CXXFLAGS='-pipe -Os -std=c++11 -stdlib=libc++'
F90FLAGS='-pipe -Os -m64'
FCFLAGS='-pipe -Os -m64'
FFLAGS='-pipe -Os'
OBJCFLAGS='-pipe -Os'
OBJCXXFLAGS='-pipe -Os -stdlib=libc++'


> R.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: port:libclang (and libLLVM)

[René J . V . Bertin]

On Wednesday March 09 2016 20:48:19 Jack Howarth wrote:
>> Why? My understanding is that the optimizations for -Os are equivalent
>> to -O2 with the emphasis on size reduction. The additional
>> optimizations from -O2 to -O3 would seem sufficient to produce a 10%
>> execution optimization, no?
>

Actually, this point is moot : -Os is used only on PPC machines from what I can 
see. Other architectures use whatever optimisation the build system decides to 
use (which is an interesting question when that system is based on CMake and 
you use one of the built-in BUILD_TYPE presets).

R.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: port:libclang (and libLLVM)

[René J . V . Bertin]

On Wednesday March 09 2016 20:48:19 Jack Howarth wrote:

>>> Frankly I'd be surprised if that leads to a 10% performance difference!
>>
>> Why? My understanding is that the optimizations for -Os are equivalent
>> to -O2 with the emphasis on size reduction. The additional
>> optimizations from -O2 to -O3 would seem sufficient to produce a 10%
>> execution optimization, no?

I think it's an accepted truth that using -O3 instead of -O2 rarely gives that 
kind of performance benefit, and that it's rather something that you'd reserve 
for cases where every percent gained counts (and you don't care about code 
size). That's speaking in general of course. AFAIK, -O3 also activates 
auto-vectorisation and that can indeed make a huge difference. Except of course 
the performance you can gain with that is rarely in algorithms that are the 
real performance bottleneck. A compiler is not the kind of application in which 
I'd expect to get a lot of benefit from auto-vectorisation.
There's one compiler option that has given me really surprising gains in the 
past (on top of -O2+ that is): -mdynamic-no-pic . I've seen that give 15% 
performance increases (thanks once more to Shark for pointing out the option). 
Of course that was on 32bit PPC hosts. I've never measured the option's effect 
on x86 and given how on x86_64 it can even be used for relocatable code (shared 
libraries) I tend to expect that it will no longer make much of a difference.

>The only other difference I see between the fink and MacPorts
>packaging is the use of -DLLVM_ENABLE_RTTI=ON in MacPorts. My
>understanding is that these additional virtual functions can introduce
>overhead in c++.

Yes, you're probably right. Combined with the (supposed) additional overhead of 
using a shared libLLVM that could well add up to the performance differences 
I've seen.
Except that I don't know if Apple build with LLVM_ENABLE_RTTI=ON or not; I've 
never compared Fink's clang builds.

R

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: port:libclang (and libLLVM)

[Jack Howarth]

On Wed, Mar 9, 2016 at 8:43 PM, Jack Howarth
 wrote:
> On Wed, Mar 9, 2016 at 6:36 PM, René J.V.  wrote:
>> On Wednesday March 09 2016 18:00:07 Jack Howarth wrote:
>>
>>> Have you checked to make sure that the installed llvm packages aren't
>>> built as the +assertions variant? The use of assertions will have a
>>
>> Oh yes. With that variant active the performance hit is much worse from what 
>> I recall, so I've been making a point of it only to install release 
>> versions, without assertions active.
>>
>>> 3.8.0. However, port isn't smart enough to honor that change for
>>> previous installations of llvm-3.8 so the +assertions variant will
>>
>> I wouldn't call the user who doesn't notice that all of a sudden a 
>> clang/llvm upgrade takes hours because built from source particularly bright 
>> either ;)
>>
>>> slower than the same under the fink packaging of llvm38/clang38 but
>>> the fink packaging uses the default -O3 optimization whereas MacPorts
>>> resets the build to use -Os instead,
>>
>> Frankly I'd be surprised if that leads to a 10% performance difference!
>
> Why? My understanding is that the optimizations for -Os are equivalent
> to -O2 with the emphasis on size reduction. The additional
> optimizations from -O2 to -O3 would seem sufficient to produce a 10%
> execution optimization, no?

The only other difference I see between the fink and MacPorts
packaging is the use of -DLLVM_ENABLE_RTTI=ON in MacPorts. My
understanding is that these additional virtual functions can introduce
overhead in c++.

>
>>
>>> Also, keep in mind that each release of clang has been getting slower
>>> over time as discussed in this thread...
>>
>> Indeed, which is why I compared comparable versions in the past; my "up to 
>> 50%" estimate is based on that.
>>
>>> > Is there a reason the LLVM ports build a shared libLLVM?
>>
>> ?
>>
>> R.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: port:libclang (and libLLVM)

[Jack Howarth]

On Wed, Mar 9, 2016 at 6:36 PM, René J.V.  wrote:
> On Wednesday March 09 2016 18:00:07 Jack Howarth wrote:
>
>> Have you checked to make sure that the installed llvm packages aren't
>> built as the +assertions variant? The use of assertions will have a
>
> Oh yes. With that variant active the performance hit is much worse from what 
> I recall, so I've been making a point of it only to install release versions, 
> without assertions active.
>
>> 3.8.0. However, port isn't smart enough to honor that change for
>> previous installations of llvm-3.8 so the +assertions variant will
>
> I wouldn't call the user who doesn't notice that all of a sudden a clang/llvm 
> upgrade takes hours because built from source particularly bright either ;)
>
>> slower than the same under the fink packaging of llvm38/clang38 but
>> the fink packaging uses the default -O3 optimization whereas MacPorts
>> resets the build to use -Os instead,
>
> Frankly I'd be surprised if that leads to a 10% performance difference!

Why? My understanding is that the optimizations for -Os are equivalent
to -O2 with the emphasis on size reduction. The additional
optimizations from -O2 to -O3 would seem sufficient to produce a 10%
execution optimization, no?

>
>> Also, keep in mind that each release of clang has been getting slower
>> over time as discussed in this thread...
>
> Indeed, which is why I compared comparable versions in the past; my "up to 
> 50%" estimate is based on that.
>
>> > Is there a reason the LLVM ports build a shared libLLVM?
>
> ?
>
> R.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: port:libclang (and libLLVM)

[Chris Jones]

> On 9 Mar 2016, at 5:08 pm, René J.V. Bertin  wrote:
> 
>> On Wednesday March 09 2016 08:41:56 Eric A. Borisch wrote:
>> 
>> FWIW, if compressed with HFS+ compression (afsctool with -f -6 -s 50
>> options, for reference), llvm-3.7 and clang-3.7 combined take 756MB rather
>> than 3.4+ GB.
> 
> I use a patched portimage.tcl that uses bsdtar from port:libarchive which 
> supports the --hfsCompression argument. I know the gain can be significant, 
> but never calculated it precisely.
> 
> Regardless, >700Mb is still a far cry from (>10x) what I've seen cited for 
> just libclang.
> 
>> One potential port that comes to mind would be cling
>> as dependency of (= part of) ROOT 6, but I would imagine that it would
>> need quite a bit of effort before ROOT and/or cling could simply
>> depend on "libclang"
> 
> Looks like "Cling is an interactive C++ interpreter, built on the top of LLVM 
> and Clang libraries" but is built inside *a* llvm+clang tree hosted by the 
> CERN and having a dedicated branch called cling-patches. That does seem to 
> make it a bit unlikely that one day cling could build against a stock 
> libclang ...

Well, that is true but i also know that the root team always looks to push as 
much as it can upstream, and very much work with the clang developers. So, yes, 
at the moment there are a number of patches applied, but that doesn't mean at 
some point in the future they would be removed. But i think the root team have 
a number of much more pressing things to fix first (like gcc 5 support. 
Currently on linux clang cannot be built and run against the gcc5 abi), and 
ultimately the root team might decide they only wish to support build their own 
internal clang version, for various reasons (the one you mention below for 
instance being one.)

> 
> Another potential candidate for which I already have a personal port is 
> clazy: https://www.kdab.com/use-static-analysis-improve-performance/
> 
> 
> About libLLVM: I'm told that libclang's dependency on libLLVM happens "when 
> you build enable shared libraries for libLLVM. This is not good for 
> performance, and should not be done when you want to create a libclang for 
> redistribution purposes."
> 
> I've heard that before, and wonder if it's the reason clang-mp-x.y has always 
> been up to 2x slower than equivalent Apple builds (and not just for me).
> 
> Is there a reason the LLVM ports build a shared libLLVM?
> 
> R.
> ___
> macports-dev mailing list
> macports-dev@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-dev
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: port:libclang (and libLLVM)

[René J . V . Bertin]

On Wednesday March 09 2016 08:41:56 Eric A. Borisch wrote:

> FWIW, if compressed with HFS+ compression (afsctool with -f -6 -s 50
> options, for reference), llvm-3.7 and clang-3.7 combined take 756MB rather
> than 3.4+ GB.

I use a patched portimage.tcl that uses bsdtar from port:libarchive which 
supports the --hfsCompression argument. I know the gain can be significant, but 
never calculated it precisely.

Regardless, >700Mb is still a far cry from (>10x) what I've seen cited for just 
libclang.

> One potential port that comes to mind would be cling
> as dependency of (= part of) ROOT 6, but I would imagine that it would
> need quite a bit of effort before ROOT and/or cling could simply
> depend on "libclang"

Looks like "Cling is an interactive C++ interpreter, built on the top of LLVM 
and Clang libraries" but is built inside *a* llvm+clang tree hosted by the CERN 
and having a dedicated branch called cling-patches. That does seem to make it a 
bit unlikely that one day cling could build against a stock libclang ...

Another potential candidate for which I already have a personal port is clazy: 
https://www.kdab.com/use-static-analysis-improve-performance/


About libLLVM: I'm told that libclang's dependency on libLLVM happens "when you 
build enable shared libraries for libLLVM. This is not good for performance, 
and should not be done when you want to create a libclang for redistribution 
purposes."

I've heard that before, and wonder if it's the reason clang-mp-x.y has always 
been up to 2x slower than equivalent Apple builds (and not just for me).

Is there a reason the LLVM ports build a shared libLLVM?

R.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev