Originally posted by hubicka
View Post
Announcement
Collapse
No announcement yet.
Torvalds Is Unconvinced By LTO'ing A Linux Kernel
Collapse
X
-
Guest replied
-
Looking through that original email thread, even the proponents are saying it's going to result in negligble speed benefits, mostly just some size reduction, largely dependent on how limited your kernel config is (LTO seems to be good at not compiling unnecessary code from disabled code paths)
A few choice quotes:
Originally posted by Tim BrayLTO shows promise for allowing more automation in configuration
handling (that is, requiring less CONFIG options).
People should definitely be warned off using this in any production
setting, but I think it's valuable for developers experimenting with
tiny-size systems to have this easily available in mainline.Originally posted by Honza4) LTO brings noticeable performance wins on average, but it is largely benchmark
dependent; some see huge improvemnts, others no improvements at all.
Basic observation is there is not much that LTO can do that can not be done
by hand. Careful developer can just identify the important spot and
restructure the soruces.
The runtime benefits are more visible on bigger, bloated and less
optimized projects than on hand tuned video encoder implementation.
I believe Kernel largely falls into hand tuned category despite its size.
...
6) LTO will pay back more in long term.
It is not only because LTO implementation in GCC (and LLVM) has more room
for improvement than the per-file optimizers.
Main things is that despite the aim to be transparent to user,
LTO is invasive change. Existing programs was developed and tuned for
per-file optimization model and many of them contains a lot of hacks to
work around its limitation (such as a lot of inline code in headers, etc.)
With LTO becoming mainstream, developers will have time to work on different
hacksOriginally posted by Andi Kleen> I would be curious about the results on Kernel.
We saw some upsides in performance with some standard tests, but nothing
too significant.
Leave a comment:
-
Originally posted by Azrael5 View PostSo someone has to make tests and benchamarks to evaluate its capabilities, problems and advantages.
Leave a comment:
-
Originally posted by curaga View PostOf course it matters. In Firefox's case, it directly affects startup speed.
Leave a comment:
-
Originally posted by caligula View PostI understand that 5% off is important in 4 MB flash storage. However in desktop apps it doesn't matter at all. Hard drives are now 1 TB (ssd) and 4 TB (3.5" hdd). You can also set up raid6 or zfs. So you get tens of terabytes and it's very cheap. You shouldn't bother with binary sizes. In fact there's plenty of room for more functionality in Firefox. Luckily they're working hard at implementing more new features with each release.
Leave a comment:
-
Originally posted by tpruzina View PostActually -march=native is even more problematic than the LTO (depends on platform tho), for example, it generates sse instruction which make context switches slower since it takes a while to set them up, which is pretty bad, especially if you have realtime requirements.
LTO seems much safer, though any gain for desktop users is doubtful due to the fact that distribution kernels are super robust and have everything in modules, which is presumably least effective use-case for LTO (and yet, most widely used).
LTO is new and has issues, this is a chicken-egg problem we need to solve - because LTO now works well in tests and environment, the problems won't be hammered out effectively without feedback. The more LTO users are here, the faster it will mature.
Leave a comment:
-
Originally posted by milkylainen View PostSaying that 5% size does not matter on desktop is a misunderstanding on how computers work.
While stability is a major concern as Linus points out, smaller size generally benefits everything.
Loading times, memory contention, cache usage etc.
Just reducing size while maintaining everything else will generate a speedup.
If it is measurable in comparison to general code behavior or not, that is another question.
Leave a comment:
-
Smaller size benefits all, not just embedded.
Originally posted by caligula View PostI understand that 5% off is important in 4 MB flash storage. However in desktop apps it doesn't matter at all. Hard drives are now 1 TB (ssd) and 4 TB (3.5" hdd). You can also set up raid6 or zfs. So you get tens of terabytes and it's very cheap. You shouldn't bother with binary sizes. In fact there's plenty of room for more functionality in Firefox. Luckily they're working hard at implementing more new features with each release.
While stability is a major concern as Linus points out, smaller size generally benefits everything.
Loading times, memory contention, cache usage etc.
Just reducing size while maintaining everything else will generate a speedup.
If it is measurable in comparison to general code behavior or not, that is another question.
Leave a comment:
Leave a comment: