Jump to content
funtoo forums

uxcn

Members
  • Content Count

    4
  • Joined

  • Last visited

2 Followers

About uxcn

  • Rank
    Newbie

Personal

  • Location
    Seattle, WA
  1. No worries :). There are actually a couple reasons why you want to add -flto at compile time (e.g. CFLAGS). With LTO, the compiler typically wants to use an intermediate format instead of its normal format to preserve information for optimization later on. Generally the compiler also wants to delay any optimizing until the link stage as well since an optimization might not make sense in the library or whole program context. When you use -flto the optimizer essentially assumes one large compilation unit at link time and can do IPO over that. However, since optimization is normally done per compilation unit, -fwhole-program is sometimes a necessary hint that the optimizer can consider the compilation unit the whole program. With LTO, it's unnecessary though and it would most likely pessimize the result. Hope this helps...
  2. uxcn

    GCC 5

    I appreciate the offer for the ebuild. It's honestly just been easier for me to download source and compile/install raw for a while. Long term it's not exactly maintainable, but it's all only under my user account anyway. From the server perspective, I'd probably argue keeping the older GCC version is less conservative than upgrading... but that's just my opinion. There are non-trivial compiler bugs that have been fixed between the major and minor revisions. Admittedly, there are probably new bugs introduced, but those should be fewer. If someone depends on the older version, why not lock it in? If the GCC devs can't be trusted, I'm not sure who can be.
  3. You might want to check the S.M.A.R.T. attributes on the disk... # smartctl -A /dev/sda You also might want to run a selftest on it to see if there are any other issues... # smartctl -t long /dev/sda FYI, sometimes you can force a drive to reallocate bad blocks by writing zeros to the disk, but there are limits. The way a disk typically works is that it reserves a certain amount of space it can reallocate bad blocks from. Generally you only start seeing bad blocks once it runs out of that reserved space.
  4. uxcn

    Clang and Portage

    Technically it's UoI-NCSA licensed, which essentially is BSD-3. Clang/LLVM is still a newer compiler, and GCC is generally still more mature particularly where optimization is important. Although, my experience is that compiling against more than one compiler tends to improve overall code quality, generally regardless. Actually, I had noticed a funtoo wiki page on it (also gentoo), so I was curious if there were plans going forward. I've personally been experimenting with it on my laptop, and I've had somewhat stable results so far. There are some blockers and show stoppers though, I'm submitting what I can upstream as I have time. If anyone is curious or wants to experiment, I'm keeping track of issue packages here, generally including versions.
  5. I'm curious if there is any current effort to track packages not building under Clang/LLVM. FreeBSD switched as a default, and I've heard that Debian was considering a switch at one point. Gentoo seemed to have an effort to track packages, but it seems like it may have fallen off the radar. There are some major blockers, like glibc, but the list already seems fairly small. Are there any formal plans for support Clang/LLVM as a system compiler going forward?
  6. I hoped the files might be helpful. You're definitely welcome to copy any of them, I'll try to answer any questions. ICC (Intel Compiler Collection) can also optimize extremely well, but it's proprietary (you need a license). If you're interested in seeing some of the differences between generated binaries, you might want to try benchmarking something like transcoding video with ffmpeg. Since transcoding is CPU intensive, it's a good way to get an idea of the performance of the code a compiler generates. Not just Clang/LLVM, it's for LTO (link-time optimization). Since optimization is done when the compiler links instead of when it compiles, the linker needs the optimization arguments. GCC with LTO is similar. It's not a problem :).
  7. I haven't had any performance problems with Clang, particularly using LTO. On the theory side of things, I think Clang and GCC perform better for different things. I have noticed that Clang tends to do better constant folding and strength reductions in the generated code that I've looked at. That may have changed with more recent GCC releases though. If you're interested in performance, LTO with the same compiler will probably give a better performance increase than switching to another compiler. I know the binary Clang emits for vlc using LTO is more than 100KiB smaller than without LTO. It might be worth benchmarking. It's a few versions behind for Clang and GCC, but one of the better compiler comparisons I read was for compiling Firefox. GCC with LTO did generate a smaller and faster binary than Clang with LTO, but again it's a few versions behind for both compilers. Grazie... although my Italian is honestly worse than my Spanish :).
  8. I switched to Clang as a default on my laptop when I had to rebuild it a while ago. It was mostly just an experiment, but I have noticed that Clang compiles a lot faster than GCC. Actually, it catches a number of optimizations GCC misses as well. I tried switching to LTO recently, and the binaries it emits are even cleaner. I haven't tried comparing to GCC 5.2 though. I think FreeBSD switched to Clang as a default recently too. I think you're right, -mtune is completely redundant. It's harmless though, so I've just left it in the configs. It's a four core smt (i7-3632QM), but I use ccache and distcc too. The "cluster" I compile against adds another eight processors. I use a tmpfs for portage as well, which generally keeps things CPU bound. No problem :).
  9. Here's my current laptop make.conf. USE="clang c++0x c++11 c++14 cuda gold graphite jemalloc aio nptl threads numa udev acpi bluetooth usb wifi caps inotify ipv6 avahi zeroconf X wayland xkb dri gl glamor opengl gles2 uxa vaapi vdpau xvmc gtk3 pulseaudio mpd alsa bluray dvd matroska mpeg x264 x265 vpx xvid dts aac mp3 ogg flac opus theora vorbis cdparanoia musicbrainz cairo jpeg jpeg2k png webp xpm lz4 lzma lzo xz zip sasl ssl tls gnutls dbus cups snmp syslog nfsv4 nfsv41 spice nsplugin libnotify otr vim-syntax" CPU_FLAGS_X86="aes avx mmx mmxext popcnt sse sse2 sse3 sse4_1 sse4_2 ssse3" ABI_X86="64" VIDEO_CARDS="modesetting intel nvidia" ACCEPT_LICENSE="FraunhoferFDK NVIDIA-CUDA Google-TOS AdobeFlash-11.x Oracle-BCLA-JavaSE" FEATURES="ccache buildpkg candy compress-build-logs fail-clean" EMERGE_DEFAULT_OPTS="--usepkg" MAKEOPTS="-j16" CC="x86_64-pc-linux-gnu-clang-3.7" CXX="x86_64-pc-linux-gnu-clang++-3.7" BUILD_CC="x86_64-pc-linux-gnu-clang-3.7" BUILD_CXX="x86_64-pc-linux-gnu-clang++-3.7" CFLAGS="-O3 -march=ivybridge -mtune=ivybridge -flto" CXXFLAGS="${CFLAGS}" LDFLAGS="-march=ivybridge -mtune=ivybridge -O3 -flto -Wl,--as-needed" HCFLAGS="-O3" CCACHE_PREFIX="/usr/bin/distcc" CCACHE_DIR="/var/ccache/portage/clang-3.7" CCACHE_SIZE="32G" CCACHE_COMPRESS="1" PKGDIR="/var/pkg/ivybridge/clang-3.7" PORTAGE_TMPDIR="/var/tmp" PORT_LOGDIR="/var/log/portage" EMERGE_LOG_DIR="/var/log/portage" source /var/lib/layman/make.conf
  10. uxcn

    GCC 5

    I was wondering if there are plans to merge gcc-5.1 and gcc-5.2 into Funtoo Portage. As a C/C++ developer, having the latest compilers is helpful for me. I know the ebuilds are a bit less monolithic than the Gentoo ebuilds. What would be involved if someone wanted to try to maintain them?
×
×
  • Create New...