Re: [PORTS] Re: Re: Call for port testing on fmgr changes --Results!
От | Adriaan Joubert |
---|---|
Тема | Re: [PORTS] Re: Re: Call for port testing on fmgr changes --Results! |
Дата | |
Msg-id | 39575AC4.8691C6E@albourne.com обсуждение исходный текст |
Ответ на | Re: Re: Call for port testing on fmgr changes -- Results! (Peter Eisentraut <e99re41@DoCS.UU.SE>) |
Список | pgsql-hackers |
Thomas Lockhart wrote: > > I noticed the other day that the geometry output differs with the > > compiler optimization level. That can't be good. > > It depends where the differences are. If they are just in the last few > decimal places, then it should be OK (though annoying for regression > test support). > > With higher optimizations, they may be doing more inlining and using > different code sequences for, for example, the transcendental functions. Dunno which flags you used, but with the right flags you get faster versions of the built-in library routines -- I know that for sine/cosine etc this makes a significant difference in runtime for a very small loss in accuracy. And aggressive reordering of instructions can mean that different parts of the calculation are executed in different order (if I recall correctly EV6/7s have 8 fp/int pipes) so that small differences in end-results are to be expected. But then, the last few digits are garbage in most numerical calculations anyway, so no great harm done there. The right way to solve this would be to be able to control the number of digits that are printed, so that it is easier to check that the significant digits are the same. That would probably get rid of quite a few architecture specific files regression test files as well. Adriaan
В списке pgsql-hackers по дате отправления: