Originally posted by In_Between_Names
View Post
Announcement
Collapse
No announcement yet.
Squeezing More Juice Out Of Gentoo With Graphite, LTO Optimizations
Collapse
X
-
Originally posted by duby229 View Post
nitpick, it's the same difference.
- Likes 2
Comment
-
Originally posted by GreatEmerald View Post
I suppose it depends on the use case. Personally I don't use Gentoo on desktops to begin with; I use it on servers (that need reliability) and low-power systems (that benefit from the optimisations a lot but I definitely spend more time compiling than using the packages).
On low power systems, believe it or not, I've been running LTOed LEDE builds on my router for quite some time now. I haven't had any problems, but of course, I do like pushing the limits and YMMV. I use -Os and --fast-math on there with the appropriate mcpu and mtune, but I have toyed with the idea of using -Ofast as well. It was much easier setting up LTO on LEDE than it was for a full desktop Gentoo system--I have only two exceptions needed.
Comment
-
Originally posted by In_Between_Names View Post
It's actually not the same at all. O3 does not *cause* undefined behaviour. O3 assumes your code *has* no undefined behaviour moreso than O2 and performs transformations accordingly. This can be enough to cause invalid code to fail. Look at how many security bugs have happened over the years because of this: buffer overflows, return to libc, you name it. We should not be encouraging people to develop with O2 to excuse this behaviour. We should be holding C and C++ code to a higher standard that contains no UB to begin with.
- Likes 2
Comment
-
Originally posted by In_Between_Names View Post
It's actually not the same at all. O3 does not *cause* undefined behaviour. O3 assumes your code *has* no undefined behaviour moreso than O2 and performs transformations accordingly. This can be enough to cause invalid code to fail. Look at how many security bugs have happened over the years because of this: buffer overflows, return to libc, you name it. We should not be encouraging people to develop with O2 to excuse this behaviour. We should be holding C and C++ code to a higher standard that contains no UB to begin with.
Comment
-
Originally posted by duby229 View Post
It is a nitpick, because no C or C++ is bug free. You can write the simplest code and compile it with different compilers and get different binaries. You have to assume that all C or C++ code exhibits undefined behavior. Most code does.
- Likes 2
Comment
-
Originally posted by GrayShade View Post
If it exhibits UB, some day it *will* break. And I'm always going to argue for making things break earlier rather than later.
Comment
-
Originally posted by duby229 View Post
It is a nitpick, because no C or C++ is bug free. You can write the simplest code and compile it with different compilers and get different binaries. You have to assume that all C or C++ code exhibits undefined behavior. Most code does.
- Likes 1
Comment
-
Originally posted by In_Between_Names View Post
Citation needed re: "no C or C++ is bug free". It is entirely possible to write correct C and C++ code. The standards documents that govern those languages document in *excruciating* detail where the language is defined and undefined. Clang and GCC even have a nice suite of UB sanitizers now that you can test your code with. They are growing more complete with each release. It may be difficult to write correct code, but it is far from impossible.
Comment
-
Originally posted by duby229 View Post
Of course. I'm not saying that undefined behavior shouldn't be fixed. I'm just saying that no matter what, it's still going to exhibit undefined behavior some scenario or another. 100% of the time on 100% of C or C++ code. It's just not possible to completely and totally avoid.
Comment
Comment