numbers test fails on 32-bit with JULIA_CPU_TARGET=i386 #7185
Comments
|
Don't know if this is helpful, but on my 32-bit platform, |
|
Bump. |
|
Would it be possible for you to do a bisect? Also, what is your 32-bit environment? I have setup ubuntu 12.04 32-bit, which I will try to build on in a couple of days. |
|
Yeah, I can do a bisect, but it's relatively slow so a few hints about e.g. where to start would be useful. Tell me if you don't manage to reproduce the problem on your setup and I'll try bisecting this. The build environment is Fedora 19, 20 and Rawhide in a VM, with gcc 4.8.2 and 4.9.0. |
|
@nalimilan My build on 32-bit dual core Fedora 19 passes all the tests so I'm wondering what would be different about your build environment? |
|
@rickhg12hs Interesting. Maybe the fact that I set |
|
Setting N.B.: After editing |
|
I guess this is a codegen issue then. Cc @Keno @vtjnash @JeffBezanson |
|
As far as I can tell, this is due to a loss of precision on i387, since the result is very slightly off: julia> (Complex(1,2) / Complex(2.5,3.0)) * Complex(2.5,3.0)
0.9999999999999999 + 1.9999999999999998im |
|
Quite possible. |
|
Confirmed that without |
nalimilan
changed the title
|
I've tried using a |
|
AFAICT, i386, i486, and i686 all map to the same processor configuration in llvm |
|
@vtjnash OK. I've tried with |
|
We can just make that an approximate test for now. I am seeing if all the other tests pass before committing. |
|
Next one after fixing the tolerance for this one: |
Not sure that's a good idea: even if the difference is small, it can be slightly confusing, and doesn't it even mean that some equality tests may fail while they work elsewhere? All of that just to support i386 machines nobody will use. :-/ |
|
@sebastien-villemot Do you need to support real i486s in your package? The Debian docs say they are still supported, but I'm not sure this is really required of all packages, even in cases (like Julia) where it makes little sense. I think for Fedora requiring Pentium 4 should be accepted. |
|
@nalimilan I think Debian still support i486, but I am not sure to understand what are the implications for Julia. In particular, the Debian package of julia uses the LLVM provided by Debian, so I do not have to deal with LLVM configuration options. Maybe there are some issues with openlibm since it contains asm, but I did not check. |
|
Pentium 4 is certainly an acceptable minimum. |
|
@ViralBShah can you just submit the patch with the tolerance. |
|
@sebastien-villemot LLVM is completely unrelated to this issue. So is openlibm. The setting only affects Julia, i.e. what instruction set is used when compiling Julia code. It would be interesting to know whether Debian would grant exceptions to 486 support or not. |
|
one option is to simply disable extended precision: diff --git a/deps/openlibm b/deps/openlibm
--- a/deps/openlibm
+++ b/deps/openlibm
@@ -1 +1 @@
-Subproject commit 0b9d67e54a5b07e32a27b68cf0a01c33b515fc9b
+Subproject commit 0b9d67e54a5b07e32a27b68cf0a01c33b515fc9b-dirty
diff --git a/src/codegen.cpp b/src/codegen.cpp
index fecf976..2cee5a3 100644
--- a/src/codegen.cpp
+++ b/src/codegen.cpp
@@ -4457,8 +4457,24 @@ static void init_julia_llvm_env(Module *m)
FPM->doInitialization();
}
+#define FP387_NEAREST 0x0000
+#define FP387_ZERO 0x0C00
+#define FP387_UP 0x0800
+#define FP387_DOWN 0x0400
+
+#define FP387_SINGLE 0x0000
+#define FP387_DOUBLE 0x0200
+#define FP387_EXTENDED 0x0300
+
+static inline void fp387(const unsigned short control)
+{
+ unsigned short cw = (control & 0x0F00) | 0x007f;
+ __asm__ volatile ("fldcw %0" : : "m" (*&cw));
+}
+
extern "C" void jl_init_codegen(void)
{
+ fp387(FP387_DOUBLE | FP387_NEAREST);
#ifdef JL_DEBUG_BUILD
cl::ParseEnvironmentOptions("Julia", "JULIA_LLVM_ARGS");
#endifalthough it is unclear how this would affect the system libm, or openlibm for that matter |
|
I don't think we can expect to run Julia on anything older than a Pentium 4. That gives us a good 14 years of hardware to run on, and anyone seriously interested in technical computing is going to have at least a P4 or greater. I think setting |
|
@staticfloat Probably. In principle, distros want to support any i386, but in practice I guess nobody ever tries a P3 anyway. |
|
FWIW, I came to the conclusion that the 32-bit Debian package has to be compiled for i486. This is a theoretical requirement set by Debian. But it is also a very real constraint, because some Debian autobuilders actually emulate a i486 hardware (using qemu), so the package would not build with |
|
I have been trying to make Julia work on non-SSE2 systems, and it turns out to be not so easy. There are a few tests that fail due to rounding issues, but this is not a big deal. A much bigger problems is for Then I tried to implement the workaround suggested by @vtjnash , which is to use double precision (instead of extended precision). It works well for In the end, I think this demonstrates that I cannot ship a package for non-SSE2 systems, at least as long as you guys don't want to support this configuration. The conclusion is that I am going to drop the 32-bit Debian package. The only people who will be affected by this move are those whose CPU supports SSE2 but not x86-64, which is a rather small range of hardware (the first Pentium 4). Later CPUs with x86-64 support can simply use the 64-bit package. |
|
People who for some reason have installed a 32-bit OS on a x86-64 are also screwed (though few people should be concerned). In the end the Debian policies are counter-productive: to support machines older than P4, you end up dropping support for more recent machines which may be used in real life. :-/ |
|
@nalimilan People who installed Debian 32-bit can still install 64-bit packages thanks to multiarch (provided they switch to a 64-bit kernal). In the precise case of Julia, however, this is not yet possible, at least because the BLAS/LAPACK packages are not multiarch-ready. But this is something that is fixable. |
|
The best solution is probably just to loosen the necessary tests slightly. We aren't learning anything particularly new here, just rehashing an old observation that compilers may rearrange your math operations to do them more efficiently. And thus we are just showing that the system gcc compiler sometimes loses a bit of precision in doing so. It's rather unfortunate that llvm seems to have simply copied gcc behavior in this regard, although perhaps this is just an unfortunate limitation of the i387 hardware. I can reproduce the range issues my i486 cross-compile. analyze-x86 ( |
|
@vtjnash As I have written in a previous comment, it's not just about loosening the testsuite. It's also about modifying Also note that I raised the i486/SSE2 issue on Debian lists, and the consensus seems to be that it's ok to have Julia require SSE2 on 32-bit, as long as it gives an explicit error message when SSE2 is not present. So I'm finally going to ship a 32-bit package, and add a patch that tests at runtime for the presence of SSE2, and gracefully exit if it is not there. |
In README.md, i486 does not work (issue JuliaLang#7185), better take a correct example.
In README.md, i486 does not work (issue JuliaLang#7185), better take a correct example.
In README.md, i486 does not work (issue JuliaLang#7185), better take a correct example.
|
@staticfloat is this superseded by #8731? I think the failures mentioned in this issue have been resolved by loosening tolerances. At least on the PPA there was a case of a user who had a pre-pentium4 i686. Our tests might not be catching every single case of old 32-bit machines giving slightly different floating-point results relative to newer processors, but I think we might have to live with that? |
|
Yes, I agre . |
Pre-SSE2 CPUs are not supported as some tests fail (#7185). Better warn as soon as possible.
Pre-SSE2 CPUs are not supported as some tests fail (#7185). Better warn before the build.
Pre-SSE2 CPUs are not supported as some tests fail (#7185). Better warn before the build. [av skip]
Pre-SSE2 CPUs are not supported as some tests fail (#7185). Better warn before the build.
Pre-SSE2 CPUs are not supported as some tests fail (JuliaLang#7185). Better warn before the build.
I'm seeing a failure on 32-bit (64-bit works fine) when building Julia RPM package based on git master from June 6th. This is a regression. Any ideas about commits which could have broken this so I try a bisection? Or commands that I should run?
Note this is with LLVM 3.3.
The text was updated successfully, but these errors were encountered: