On 07/20/2012 01:39 AM, Richard Guenther wrote:
>> > I've not yet speed tested this, only completed bootstrap + test
>> > runs for both x86_64 and ppc64. I've done sanity cross compiles
>> > to alpha and mips (the only SWITCHABLE_TARGET).
> It would be interesting to see startup-time effects of this patch (thus,
> compile-time of an empty CU).
I've now done some speed testing on x86_64. Best I can figure, everything is
within measurement error. I tried both standalone compilations of combine.ii
and bootstraps. I had to loop executions of cc1[*] to even measure the startup
time as requested, in which the only effect seems to be a narrowing of stddev.
I did some gperf profiles of the combine.ii compilation. There, the cumulative
time in raw_optab_handler just barely makes it to 0.01 sec with 76k invocations.
So while we could make that unmeasurable with a minimal perfect hash, we
probably
wouldn't actually be able to notice its effect on compilation as a whole.
So I guess we're down to theoretical improvement in memory usage and startup,
and a real improvement in maintainability due to the consolidation of the places
that must be modified to add or edit an optab.
No other comments over the weekend, really?
r~
[*]:
#include <unistd.h>
#include <sys/fcntl.h>
#include <stdlib.h>
int main(int ac, char **av)
{
int i, count = atoi(av[1] ? av[1] : "100");
close (0);
close (1);
open ("/dev/null", O_RDONLY);
open ("/dev/null", O_WRONLY);
for (i = 0; i < count; ++i)
{
int f = vfork();
if (f == -1)
return 1;
if (f == 0)
{
execl ("./cc1", "./cc1", "-quiet", "-o", "-", NULL);
_exit (1);
}
wait(NULL);
}
return 0;
}
time loop 1000:
NEW real user sys OLD real user sys
11.344 7.765 2.962 11.456 7.770 3.033
11.296 7.786 2.862 11.286 7.787 2.843
11.312 7.776 2.897 11.323 7.740 2.942
11.367 7.820 2.917 11.355 7.800 2.916
11.275 7.777 2.852 11.354 7.708 2.974
avg 11.319 7.785 2.898 11.355 7.761 2.942
stddev 0.033 0.019 0.040 0.057 0.033 0.063
