Acovea 5.0.1, and How some people are using Acovea the Wrong

[ScottRobertLadd]

I've posted a minor update to Acovea, fixing a bug in the output. It doesn;t change the results any of the 5.0.0 I posted a couple of days ago, but ebuild makers and such might need to change some things because of this.

Also new: *More* configurations, for GCC 4.0 and gfrotran, and a new analysis of GCC 4.0 on Opteron, where I found a **BIG** code generation bug for floating-point programs.

You'll find it all here:

http://www.coyotegulch.com/products/acovea/aco5k8gcc40.html

Finally, a note based on some chat conversations and a perusal of past Acovea discussions here on the Gentoo forums:

Acovea was designed with "spikes" in mind -- short programs that implement a limited algorithm that runs quickly (2-10 seconds per run). Using the default settings, Acovea will perform 4,000 compiles and runs of the benchmark; even with a very small and fast benchmark, this can take several hours. If your program takes a full minute to compile, and another minute to run, Acovea will require 8,000 minutes, or more than 5.5 days to evolve optimal option sets!

Results from running Acovea against a few algorithms should NOT be applied across a broad spectrum of applications. For my Gentoo-based systems, I don't set the value of make.conf's CFLAGS based on Acovea results; I build specific, time-critical applications using algorithm-specific options.

Much as I appreciate the interest in Acovea here, I also want to be certain that people understand how the tool was designed to work. This is an optimization tool, like a profiler.

Thanks much.

[nmcsween]

Not that I like the idea of tweaking everything past a point but in hypothetical terms could acovea be used as a replacement for crude make.conf CFLAGS and CXXFLAGS? This could eliminate about 80% of the problems ( bugs ) Gentoo suffers.
_________________
Great Resources

• Fluid Portage

[nmcsween]

This could be easily implemented via per package cflags selection and acovea wrapper around emerge (i.e aemerge). This could be complimented by such things as gcc profiling if portage learned how to deal with temp files correctly. This would take things to an extreme though... anyone up for a 3 day compile of gzip? But such things as ftp servers, and http servers could benifit *greatly* from this.
_________________
Great Resources

• Fluid Portage

[bollucks]

If you do this, prepare for pretty much nothing to work reliably.

[nmcsween]

What will casue it? Why? Where will I encounter problems? Between acovea and portage? Explain why you think it won't work. Clarify
_________________
Great Resources

• Fluid Portage

[rhill]

But how would you know what flags gave you the most optimized performance? To use your example, how do you go about measuring the performance of gzip? You could measure the time it takes to, say, zip or unzip a large file or a large number of smaller files and compare those measurements, but how would Acovea know to do that? You would have to come up with a unique and accurate benchmark for every single package you built, and you'd have to run it yourself after each and every build attempt (or individually script each benchmark and somehow tell Acovea to run it i suppose).

It's not a bad idea, but it would be extremely difficult to implement in reality.
_________________
by design, by neglect
for a fact or just for effect

[nmcsween]

Acovea as a baseline and gcc profiling for well run packages would be a nice in-between alternative instead of a script for every package. Portage needs to work on temp file handling so profiling can be using without ebuild hacks.
_________________
Great Resources

• Fluid Portage

[ScottRobertLadd]

[rhill]