From: John D. <uf...@gm...> - 2006-12-07 03:07:23
|
Hello, But for the same compiler on the same machine, the results are much closer across different optimization levels with 64 bit rounding. When I run the same regressions on windows, freebsd, and linux, the results are off in a much less significant decimal place. I want my regression to show significant differences due to algorithmic changes, and not just the fact that I chose -O2 versus -O3. When I do AMD-64 in 64bit mode, it is going to prefer the 64-bit SSE instructions over the 80-bit 387 instructions. Now I am going to get closer results to a machine with a sparc chip then when I compiled the program on the same machine in 32-bit mode. If my result is rounded to 64-bit in the floating point register, less damage is done when that number is written back to memory and read back in. I am happier with that than having an 80-bit number written from register to memory, read back in and zero extended. An excellent paper on this issue is: http://www.wrcad.com/linux_numerics.txt When an EDA customer gets a new update to their tools, they're going to validate and they want an explanation why the results no longer match their golden files. EDA companies are keenly aware of this, and often provide extended precision, but only as a non-default option. Regards, Juan On 12/6/06, al davis <ad...@fr...> wrote: > > On Wednesday 06 December 2006 20:06, John Doe wrote: > > Concerning floating point, is the rounding mode set to 64-bit > > or 80-bit when the regressions are running on x86 machines? > > Having 80-bit enabled causes all kinds of issues for > > regressions because debug and optimized versions of code can > > have significantly different results. On x86_64 bit > > machines, the 387 instructions are bypassed. > > That option is not always obeyed by the compilers. > > It is really nothing more than minor nuisance in validating > regressions. > > There are things like ... > > A number that should be zero, maybe made by subtracting one > version of 3.3489 from another version of 3.3489 . They were > made by some calculation. The result is 6.2342e-16 on one > version and 6.2738e-16 on another. What if one of the numbers > is -7.67842e-18 ? > > A calculation uses the "sin()" function, which is implemented a > little different on a different CPU, or a different compiler. > It might not show just looking at the number, but then subtract > them..... > > If you are picky, it is possible to see the difference between > an Intel and an AMD processor. It is easy to see the > difference between an AMD-64 in "long" mode vs. the same AMD-64 > in 32 bit mode. > > Compilers sometimes optimize by combining common subexpressions > or rearranging the order of an expression. Usually this is > desirable because it leads to better performance and has no > undesirable effects. > > Part of the point of regressions is to show these issues. It is > important that they do. Suppose I make a change to an > algorithm. I want to see that effect, and will design tests to > show it. Consider ... How accurate is the time step control? > What error is added by something like "bypass"? How do I prove > that this model parameter actually does something? > > Tests are often used to compare one simulator against another. > In this case, it is guaranteed that there will be differences. > To make a real test, we make test cases that might exaggerate > the differences. > > One way is to have 2 sets of tests. One is for the developers, > and shows all of this. The other is more lax, and just tests > basic functionality. For this one, just pick the numbers so > they are not sensitive to this. > > But even this is misleading. Anyone serious knows that this > happens. For education, it is important that students learn > that this happens, and that it is normal. > > Welcome to floating point computer math. > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share > your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Ngspice-devel mailing list > Ngs...@li... > https://lists.sourceforge.net/lists/listinfo/ngspice-devel > |