4 ms·

It's a while since I had to deal with this kind of thing, but my memory was that as soon as you go beyond the flags that the upstream developers use (just to be

by rgmerk 2y ago

It's a while since I had to deal with this kind of thing, but my memory was that as soon as you go beyond the flags that the upstream developers use (just to be clear, I mean the upstream developers, not the distro packagers) you're buying yourself weird bugs and a whole lot of indifference if they occur. I haven't used a non-libc malloc before but I suspect the same applies.

taeric 2y ago
I've been building my own emacs for a long time, and have yet to hit any weird bugs. I thought that as long as you avoid any unsafe optimizations, you should be fine? Granted, I also thought that -march=native was the main boost that I was seeing. This post indicates that is not necessarily the case. I also suspect that any application using floats is more likely to have rough edges?
- pertymcpert 2y ago
  Complex software usually has some undefined behavior lurking that at higher or even just different optimization levels can trigger the compiler to do unexpected things to the code. It happens all the time in my line of work. If there's an extensive test suite you can run to verify that it still works mostly as expected then it's easier.
  - taeric 2y ago
    This is one where I suspect we don't disagree. But "all the time" can have a very different feel between people. It also used to happen that just changing processors was likely to find some problems in the code. I have no doubt that still happens, but I'd also expect it has reduced. Some of this has to be a convergence on far fewer compilers than we used to encounter. I know there are still many c compilers. Seems there are only two common ones, though. Embedded, of course, is a whole other bag of worms.
- Y_Y 2y ago
  Did you try -ffast-math? IIRC that used to break emacs in some subtle way, while providing no extra speed.
  - taeric 2y ago
    I thought touching the math optimizations directly was in the "unsafe" bucket. Really the only optimization I was aiming for was -march=native. That and the features like native compilation that have made it to the release. I do think I saw improvements. But I never got numbers, so I'm assuming most of my feel was wishful thinking. Reality is a modern computer is hella fast for something like emacs. I did see compilation mode improve when I trimmed down the regexes it watches for to only the ones I knew were relevant for me. That said, I think I've stopped doing that; so maybe that is a lot better?
  - fireant 2y ago
    I've turned on fastmath in python numba compiler while thinking "of course i want faster math, duh". Took me a while to find out it was a cause of many "fun" subtle bugs. Never touching that stuff again.
Brian_K_White 2y ago
Two opposing things are both true at the same time. If you as an individual avoid being at all different, then you are in the most company and will likely have the most success in the short term. But it's also true that if we all do that then that leads to monoculture and monoculture is fragile and bad. It's only because of people building code in different contexts (different platforms, compilers, options, libraries, etc...) that code ever becomes at all robust. A bug that you mostly don't trigger because your platform or build flags just happens to walk just a hair left of the hole in the ground, was still a bug and the code is still better for discovering and fixing it. We as individuals all benefit from code being generally robust instead of generally fragile.
notpushkin 2y ago
On the other hand, if your optimization helps consistently across platforms, you could convince upstream developers to implement it directly. (Not necessarily across all platforms – a sizable performance gain on just a single arch might still be enough to tweak configuration for that particular build).

by rgmerk 2y ago

taeric 2y ago

I've been building my own emacs for a long time, and have yet to hit any weird bugs. I thought that as long as you avoid any unsafe optimizations, you should be fine? Granted, I also thought that -march=native was the main boost that I was seeing. This post indicates that is not necessarily the case. I also suspect that any application using floats is more likely to have rough edges?

pertymcpert 2y ago
Complex software usually has some undefined behavior lurking that at higher or even just different optimization levels can trigger the compiler to do unexpected things to the code. It happens all the time in my line of work. If there's an extensive test suite you can run to verify that it still works mostly as expected then it's easier.
- taeric 2y ago
  This is one where I suspect we don't disagree. But "all the time" can have a very different feel between people. It also used to happen that just changing processors was likely to find some problems in the code. I have no doubt that still happens, but I'd also expect it has reduced. Some of this has to be a convergence on far fewer compilers than we used to encounter. I know there are still many c compilers. Seems there are only two common ones, though. Embedded, of course, is a whole other bag of worms.
Y_Y 2y ago
Did you try -ffast-math? IIRC that used to break emacs in some subtle way, while providing no extra speed.
- taeric 2y ago
  I thought touching the math optimizations directly was in the "unsafe" bucket. Really the only optimization I was aiming for was -march=native. That and the features like native compilation that have made it to the release. I do think I saw improvements. But I never got numbers, so I'm assuming most of my feel was wishful thinking. Reality is a modern computer is hella fast for something like emacs. I did see compilation mode improve when I trimmed down the regexes it watches for to only the ones I knew were relevant for me. That said, I think I've stopped doing that; so maybe that is a lot better?
- fireant 2y ago
  I've turned on fastmath in python numba compiler while thinking "of course i want faster math, duh". Took me a while to find out it was a cause of many "fun" subtle bugs. Never touching that stuff again.

Brian_K_White 2y ago

Two opposing things are both true at the same time. If you as an individual avoid being at all different, then you are in the most company and will likely have the most success in the short term. But it's also true that if we all do that then that leads to monoculture and monoculture is fragile and bad. It's only because of people building code in different contexts (different platforms, compilers, options, libraries, etc...) that code ever becomes at all robust. A bug that you mostly don't trigger because your platform or build flags just happens to walk just a hair left of the hole in the ground, was still a bug and the code is still better for discovering and fixing it. We as individuals all benefit from code being generally robust instead of generally fragile.

notpushkin 2y ago

On the other hand, if your optimization helps consistently across platforms, you could convince upstream developers to implement it directly. (Not necessarily across all platforms – a sizable performance gain on just a single arch might still be enough to tweak configuration for that particular build).