|From:||Brandon J. Van Every|
|Subject:||[Chicken-users] optimization flags|
|Date:||Wed, 06 Sep 2006 22:58:02 -0700|
|User-agent:||Thunderbird 184.108.40.206 (Windows/20060719)|
John Cowan wrote:
Brandon J. Van Every scripsit:It is true that I have not implemented GCC specific flags in CMake. This is pretty easy to do.Good idea. They should probably be provided in every build except MSVC, because they optimize the generated C code quite a bit when you have lots of little functions, as Chicken output does.
I'm only providing the flags for GCC builds. I'm not willing to assume that non-GCC compilers take GCC flags. If people have non-GCC, non-MSVC compilers, they can inform us, and we can add more flags. I might also set up an area at the top of CMakeLists.txt that's meant for people to add flags we don't know about.
Given all the compiler, architecture, and philosophical permutations, optimization flags can get quite complicated. For instance, Felix has this "-Os" philosophy, that optimizing for size yields the best performance. I'd like to see hard evidence of that. I certainly don't take it on faith, or on principles. Generally when people design code to be smaller, they blow off CPU optimizations that are faster. Typically, cache aligned instructions are better pipelined and take less CPU cycles to execute, even if they consume more memory. So the game is, does the smaller cache size of the -Os code beat the better pipelining of the -Ox code? I don't know. Especially, I don't know in the case of Chicken garbage collection.
So, I'm not going to debate the choice of optimization flags right now. I've copied what's used by Autoconf. But I do think this is fodder for a more rigorous benchmarking project someday. Along with questions like, "what's the ideal stack size?" A compiler-OS-architecture database is needed for these sorts of things.
I found that -fomit-frame-pointer causes chicken-boot to crash when compiled with MinGW 3.4.5. So, I've turned it off for all MinGW compilers. No idea if it affects anything other than 3.4.5. You can see that there are testing issues. Cygwin built fine without complaint. Didn't actually test the end product though, as I relish the chance to blow up John Cowan's machine. :-) More seriously, it's way too boring to try to do all these testing cases, and I am pressed for time. Until someone steps forward to conjure us a nightly build, I'll be doing some of the testing work myself and foisting whatever is too boring onto the community at large. "Release Candidates" make a lot of sense under such a regime.
Brandon Van Every
|[Prev in Thread]||Current Thread||[Next in Thread]|