[sage-devel] Re: how do I build sage-5.0 on virtualbox?
On May 21, 4:02 pm, Jeroen Demeyer jdeme...@cage.ugent.be wrote: On 2012-05-21 23:21, Adam Webb wrote: William (or anyone else having this problem), can you test the SPKG Jeroen has put up on #12970 ? Just unpack a sage source tarball, and replace mpir-2.4.0.p3.spkg withhttp://boxen.math.washington.edu/home/jdemeyer/spkg/mpir-2.4.0.p5.spkg. I'd test it myself but I don't have access to my VM for the next month or so. -Keshav Join us in #sagemath on irc.freenode.net ! I tried the spkg and everything built without problems. A 'make - ptestlong' also passed. This is using Ubuntu 12.04 (64 bit) on vmplayer in Windows 7. Please 1) Mention your CPU model 2) Send the MPIR build log My cpu is an Intel Core i7-2600. BTW I am using VMware Player 4.0.3. For what it is worth, cpuinfo shows the following flags: flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts nopl xtopology tsc_reliable nonstop_tsc aperfmperf pni pclmulqdq ssse3 cx16 sse4_1 sse4_2 popcnt hypervisor lahf_lm ida arat epb xsaveopt pln pts dts Log file is at http://sage.math.washington.edu/home/awebb/mpir-2.4.0.p5.log. Cheers, Adam -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: how do I build sage-5.0 on virtualbox?
William (or anyone else having this problem), can you test the SPKG Jeroen has put up on #12970 ? Just unpack a sage source tarball, and replace mpir-2.4.0.p3.spkg withhttp://boxen.math.washington.edu/home/jdemeyer/spkg/mpir-2.4.0.p5.spkg. I'd test it myself but I don't have access to my VM for the next month or so. -Keshav Join us in #sagemath on irc.freenode.net ! I tried the spkg and everything built without problems. A 'make - ptestlong' also passed. This is using Ubuntu 12.04 (64 bit) on vmplayer in Windows 7. Cheers, Adam -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: how do I build sage-5.0 on virtualbox?
On 2012-05-21 23:21, Adam Webb wrote: William (or anyone else having this problem), can you test the SPKG Jeroen has put up on #12970 ? Just unpack a sage source tarball, and replace mpir-2.4.0.p3.spkg withhttp://boxen.math.washington.edu/home/jdemeyer/spkg/mpir-2.4.0.p5.spkg. I'd test it myself but I don't have access to my VM for the next month or so. -Keshav Join us in #sagemath on irc.freenode.net ! I tried the spkg and everything built without problems. A 'make - ptestlong' also passed. This is using Ubuntu 12.04 (64 bit) on vmplayer in Windows 7. Please 1) Mention your CPU model 2) Send the MPIR build log -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: how do I build sage-5.0 on virtualbox?
William Stein wst...@gmail.com writes: Hi, I know something like this has been reported, but I can't figure out where. I am using Ubuntu 12.04 in Virtualbox on my Mac, and I can't build Sage because of MPIR. Which ticket? What's the workaround? This will probably impact me a lot, since I use virtual machines quite a bit... libtool: compile: ../strip_fPIC.sh ../yasm/yasm -I .. -f elf64 add_n.as -fPIC -DPIC -o .libs/add_n.o ../yasm/yasm -I .. -f elf64 add_n.as -D PIC -o .libs/add_n.o ../libtool: line 1133: 20873 Illegal instruction (core dumped) ../strip_fPIC.sh ../yasm/yasm -I .. -f elf64 add_n.as -fPIC -DPIC -o .libs/add_n.o make[4]: *** [add_n.lo] Error 1 make[4]: Leaving directory `/home/wstein/sage/build/sage-5.0/spkg/build/mpir-2.4.0.p3/src/mpn' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/home/wstein/sage/build/sage-5.0/spkg/build/mpir-2.4.0.p3/src' make[2]: *** [all] Error 2 make[2]: Leaving directory `/home/wstein/sage/build/sage-5.0/spkg/build/mpir-2.4.0.p3/src' Error building MPIR. real 1m36.861s user 0m35.050s sys 0m15.297s Error installing package mpir-2.4.0.p3 William (or anyone else having this problem), can you test the SPKG Jeroen has put up on #12970 ? Just unpack a sage source tarball, and replace mpir-2.4.0.p3.spkg with http://boxen.math.washington.edu/home/jdemeyer/spkg/mpir-2.4.0.p5.spkg . I'd test it myself but I don't have access to my VM for the next month or so. -Keshav Join us in #sagemath on irc.freenode.net ! -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: how do I build sage-5.0 on virtualbox?
The restriction is not due to the physical CPU at all. The physical CPU's architecture is equal to the architecture that MPIR detects. That is not the problem. The problem is that Virtualbox does not support certain instructions inside the VM. And that means that all VMs made by people using Virtualbox will probably have this problem. The conditions for this problem to occur are: 1) the physical CPU supports some instruction x; and 2) Virtualbox does not support running instruction x inside VMs; and 3) MPIR gets built with instruction x somewhere in its binary (or fails during the build due to instruction x being run somewhere in the build process), because it knew that the *physical* CPU supported that instruction, while it did not know that the *virtual* CPU does *not* support that instruction. At least, that's how I understand the situation. -Keshav Join us in #sagemath on irc.freenode.net !- Hide quoted text - - Show quoted text - Just to add my 2 cents. I am using vmplayer which I believe is simliar overall if not in implementation detail. However it supports a somewhat different set of CPU instructions. Fortunately, the solution posted here for virtual box, using march=native, works equally well for vmplayer. Adam -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: how do I build sage-5.0 on virtualbox?
Check the discussion here: https://groups.google.com/d/msg/sage-release/cloOmbv38zk/qFKrbB5fQXUJ Not sure a solution was proposed... On Friday, May 18, 2012 7:42:47 AM UTC+2, P Purkayastha wrote: I think Keshav ran into the same problem and it was because vbox wasn't reporting the correct cpu parameters or something like that. On Friday, May 18, 2012 1:00:54 PM UTC+8, William wrote: Hi, I know something like this has been reported, but I can't figure out where. I am using Ubuntu 12.04 in Virtualbox on my Mac, and I can't build Sage because of MPIR. Which ticket? What's the workaround? This will probably impact me a lot, since I use virtual machines quite a bit... libtool: compile: ../strip_fPIC.sh ../yasm/yasm -I .. -f elf64 add_n.as -fPIC -DPIC -o .libs/add_n.o ../yasm/yasm -I .. -f elf64 add_n.as -D PIC -o .libs/add_n.o ../libtool: line 1133: 20873 Illegal instruction (core dumped) ../strip_fPIC.sh ../yasm/yasm -I .. -f elf64 add_n.as -fPIC -DPIC -o .libs/add_n.o make[4]: *** [add_n.lo] Error 1 make[4]: Leaving directory `/home/wstein/sage/build/sage-5.0/spkg/build/mpir-2.4.0.p3/src/mpn' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/home/wstein/sage/build/sage-5.0/spkg/build/mpir-2.4.0.p3/src' make[2]: *** [all] Error 2 make[2]: Leaving directory `/home/wstein/sage/build/sage-5.0/spkg/build/mpir-2.4.0.p3/src' Error building MPIR. real1m36.861s user0m35.050s sys0m15.297s Error installing package mpir-2.4.0.p3 -- William Stein Professor of Mathematics University of Washington http://wstein.org -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: how do I build sage-5.0 on virtualbox?
On May 17, 10:00 pm, William Stein wst...@gmail.com wrote: Hi, I know something like this has been reported, but I can't figure out where. I am using Ubuntu 12.04 in Virtualbox on my Mac, and I can't build Sage because of MPIR. Which ticket? What's the workaround? http://groups.google.com/group/sage-release/msg/024747c0ee60156e apparently: build MPIR with -march=native This might be worth a ticket. -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: how do I build sage-5.0 on virtualbox?
What I've been doing is the following: $ make # the build fails on mpir $ CFLAGS=-O2 -march=native ./sage -i mpir # mpir builds $ make # sage finishes building This is now #12970: http://trac.sagemath.org/sage_trac/ticket/12970 -Keshav Join us in #sagemath on irc.freenode.net ! On Friday, May 18, 2012 1:00:54 PM UTC+8, William wrote: Hi, I know something like this has been reported, but I can't figure out where. I am using Ubuntu 12.04 in Virtualbox on my Mac, and I can't build Sage because of MPIR. Which ticket? What's the workaround? This will probably impact me a lot, since I use virtual machines quite a bit... libtool: compile: ../strip_fPIC.sh ../yasm/yasm -I .. -f elf64 add_n.as -fPIC -DPIC -o .libs/add_n.o ../yasm/yasm -I .. -f elf64 add_n.as -D PIC -o .libs/add_n.o ../libtool: line 1133: 20873 Illegal instruction (core dumped) ../strip_fPIC.sh ../yasm/yasm -I .. -f elf64 add_n.as -fPIC -DPIC -o .libs/add_n.o make[4]: *** [add_n.lo] Error 1 make[4]: Leaving directory `/home/wstein/sage/build/sage-5.0/spkg/build/mpir-2.4.0.p3/src/mpn' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/home/wstein/sage/build/sage-5.0/spkg/build/mpir-2.4.0.p3/src' make[2]: *** [all] Error 2 make[2]: Leaving directory `/home/wstein/sage/build/sage-5.0/spkg/build/mpir-2.4.0.p3/src' Error building MPIR. real1m36.861s user0m35.050s sys0m15.297s Error installing package mpir-2.4.0.p3 -- William Stein Professor of Mathematics University of Washington http://wstein.org -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: how do I build sage-5.0 on virtualbox?
Jeroen Demeyer jdeme...@cage.ugent.be writes: Something else to try: build with SAGE_FAT_BINARY=yes. Perhaps the run-time CPU detection works better. Yup, that works. But it's still a workaround and not really a solution. It would be nice if I could type make and have everything just work. -Keshav Join us in #sagemath on irc.freenode.net ! -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: how do I build sage-5.0 on virtualbox?
On Fri, May 18, 2012 at 6:19 AM, Keshav Kini keshav.k...@gmail.com wrote: Jeroen Demeyer jdeme...@cage.ugent.be writes: Something else to try: build with SAGE_FAT_BINARY=yes. Perhaps the run-time CPU detection works better. Yup, that works. But it's still a workaround and not really a solution. It would be nice if I could type make and have everything just work. Building with SAGE_FAT_BINARY will result in other parts of Sage (e.g., ATLAS) being built much less efficiently. It's far better to use CFLAGS=-O2 -march=native ./sage -i mpir which does seem to work. Many thanks for working on somehow fixing this.I think a lot of people use virtualbox, so having MPIR building broken there is not good... What do the MPIR dev's think is an acceptable solution here? -- William -Keshav Join us in #sagemath on irc.freenode.net ! -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -- William Stein Professor of Mathematics University of Washington http://wstein.org -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [mpir-devel] Re: [sage-devel] Re: how do I build sage-5.0 on virtualbox?
I'm not sure how virtual boxes work. Do they emulate the CPU as well as the OS? Unfortunately, there isn't really a lot we can do if virtual box is going out of its way to report incorrect cpu parameters through the *assembly instruction* cpuid, if that is what is happening (I am not sure if it is or not). Unfortunately, the solution does appear to be to build MPIR with -march=native, which apparently works. If anyone has any deep insight into this, please let us know. Maybe it is possible for us to do something about it upstream. I'm keen to fix it, I just don't understand the problem well enough. Bill. On 18 May 2012 16:16, William Stein wst...@gmail.com wrote: On Fri, May 18, 2012 at 6:19 AM, Keshav Kini keshav.k...@gmail.com wrote: Jeroen Demeyer jdeme...@cage.ugent.be writes: Something else to try: build with SAGE_FAT_BINARY=yes. Perhaps the run-time CPU detection works better. Yup, that works. But it's still a workaround and not really a solution. It would be nice if I could type make and have everything just work. Building with SAGE_FAT_BINARY will result in other parts of Sage (e.g., ATLAS) being built much less efficiently. It's far better to use CFLAGS=-O2 -march=native ./sage -i mpir which does seem to work. Many thanks for working on somehow fixing this. I think a lot of people use virtualbox, so having MPIR building broken there is not good... What do the MPIR dev's think is an acceptable solution here? -- William -Keshav Join us in #sagemath on irc.freenode.net ! -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -- William Stein Professor of Mathematics University of Washington http://wstein.org -- You received this message because you are subscribed to the Google Groups mpir-devel group. To post to this group, send email to mpir-de...@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en. -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [mpir-devel] Re: [sage-devel] Re: how do I build sage-5.0 on virtualbox?
On 2012-05-18 17:29, Bill Hart wrote: I'm not sure how virtual boxes work. Do they emulate the CPU as well as the OS? Unfortunately, there isn't really a lot we can do if virtual box is going out of its way to report incorrect cpu parameters through the *assembly instruction* cpuid, if that is what is happening (I am not sure if it is or not). Unfortunately, the solution does appear to be to build MPIR with -march=native, which apparently works. If anyone has any deep insight into this, please let us know. Maybe it is possible for us to do something about it upstream. I'm keen to fix it, I just don't understand the problem well enough. I think the following /proc/cpuinfo explains what happens: processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 42 model name : Intel(R) Core(TM) i5-2500K CPU @ 3.30GHz stepping: 7 cpu MHz : 3302.482 cache size : 6144 KB physical id : 0 siblings: 4 core id : 0 cpu cores : 4 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 5 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx lm constant_tsc rep_good nopl pni ssse3 lahf_lm bogomips: 6604.96 clflush size: 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: According to vendor/family/model, this is a Sandy Bridge. However, the CPU features (see flags) are seriously reduced compared to a real Sandy Bridge. Compiling with -march=SOMETHING means that 3 things have to be satisfied: (1) GCC must understand the command line flag (2) The assembler must understand the instructions (3) The processor must support the instructions Based on my observations, it seems that MPIR already checks (1) and (2). With -march=native, (1) and (3) are guaranteed, but not (2). When checking CFLAGS in MPIR, would it be possible to actually *run* an executable compiled with -march=SOMETHING, thereby checking (3)? Alternatively, check the feature flags from CPUID and lower the architecture based on that. Jeroen. -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [mpir-devel] Re: [sage-devel] Re: how do I build sage-5.0 on virtualbox?
On 18 May 2012 17:26, Jeroen Demeyer jdeme...@cage.ugent.be wrote: On 2012-05-18 17:29, Bill Hart wrote: I'm not sure how virtual boxes work. Do they emulate the CPU as well as the OS? Unfortunately, there isn't really a lot we can do if virtual box is going out of its way to report incorrect cpu parameters through the *assembly instruction* cpuid, if that is what is happening (I am not sure if it is or not). Unfortunately, the solution does appear to be to build MPIR with -march=native, which apparently works. If anyone has any deep insight into this, please let us know. Maybe it is possible for us to do something about it upstream. I'm keen to fix it, I just don't understand the problem well enough. I think the following /proc/cpuinfo explains what happens: processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 42 model name : Intel(R) Core(TM) i5-2500K CPU @ 3.30GHz stepping : 7 cpu MHz : 3302.482 cache size : 6144 KB physical id : 0 siblings : 4 core id : 0 cpu cores : 4 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 5 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx lm constant_tsc rep_good nopl pni ssse3 lahf_lm bogomips : 6604.96 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: According to vendor/family/model, this is a Sandy Bridge. However, the CPU features (see flags) are seriously reduced compared to a real Sandy Bridge. Compiling with -march=SOMETHING means that 3 things have to be satisfied: (1) GCC must understand the command line flag (2) The assembler must understand the instructions (3) The processor must support the instructions Based on my observations, it seems that MPIR already checks (1) and (2). With -march=native, (1) and (3) are guaranteed, but not (2). When checking CFLAGS in MPIR, would it be possible to actually *run* an executable compiled with -march=SOMETHING, thereby checking (3)? Configure does run actual compile tests for the various -march options, I believe. But the problem (3) won't show up unless code specifically designed to compile to instructions that are only supported on that processor is compiled. I don't think this is feasible (and it is an autotools/configure issue anyway, not MPIR). Alternatively, check the feature flags from CPUID and lower the architecture based on that. This would be feasible I think, but basically defeats the entire strategy of selecting CPUs in MPIR. So does virtual box emulate a CPU with reduced features or something? Do they consider this a bug, do you think? Bill. -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [mpir-devel] Re: [sage-devel] Re: how do I build sage-5.0 on virtualbox?
On Friday, 18 May 2012 18:35:04 UTC+2, Bill Hart wrote: On 18 May 2012 17:26, Jeroen Demeyer wrote: On 2012-05-18 17:29, Bill Hart wrote: I'm not sure how virtual boxes work. Do they emulate the CPU as well as the OS? Unfortunately, there isn't really a lot we can do if virtual box is going out of its way to report incorrect cpu parameters through the *assembly instruction* cpuid, if that is what is happening (I am not sure if it is or not). Unfortunately, the solution does appear to be to build MPIR with -march=native, which apparently works. If anyone has any deep insight into this, please let us know. Maybe it is possible for us to do something about it upstream. I'm keen to fix it, I just don't understand the problem well enough. I think the following /proc/cpuinfo explains what happens: processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 42 model name : Intel(R) Core(TM) i5-2500K CPU @ 3.30GHz stepping: 7 cpu MHz : 3302.482 cache size : 6144 KB physical id : 0 siblings: 4 core id : 0 cpu cores : 4 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 5 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx lm constant_tsc rep_good nopl pni ssse3 lahf_lm bogomips: 6604.96 clflush size: 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: According to vendor/family/model, this is a Sandy Bridge. However, the CPU features (see flags) are seriously reduced compared to a real Sandy Bridge. Compiling with -march=SOMETHING means that 3 things have to be satisfied: (1) GCC must understand the command line flag (2) The assembler must understand the instructions (3) The processor must support the instructions Based on my observations, it seems that MPIR already checks (1) and (2). With -march=native, (1) and (3) are guaranteed, but not (2). When checking CFLAGS in MPIR, would it be possible to actually *run* an executable compiled with -march=SOMETHING, thereby checking (3)? Configure does run actual compile tests for the various -march options, I believe. But the problem (3) won't show up unless code specifically designed to compile to instructions that are only supported on that processor is compiled. I don't think this is feasible (and it is an autotools/configure issue anyway, not MPIR). Alternatively, check the feature flags from CPUID and lower the architecture based on that. This would be feasible I think, but basically defeats the entire strategy of selecting CPUs in MPIR. So does virtual box emulate a CPU with reduced features or something? yes. This was discussed here and/or on sage-support... Do they consider this a bug, do you think? They are pwned by Oracle now, it's unlikely they'd fix anything quickly, if at all... Dima Bill. -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [mpir-devel] Re: [sage-devel] Re: how do I build sage-5.0 on virtualbox?
On 18 May 2012 17:46, Dima Pasechnik dimp...@gmail.com wrote: On Friday, 18 May 2012 18:35:04 UTC+2, Bill Hart wrote: On 18 May 2012 17:26, Jeroen Demeyer wrote: On 2012-05-18 17:29, Bill Hart wrote: I'm not sure how virtual boxes work. Do they emulate the CPU as well as the OS? Unfortunately, there isn't really a lot we can do if virtual box is going out of its way to report incorrect cpu parameters through the *assembly instruction* cpuid, if that is what is happening (I am not sure if it is or not). Unfortunately, the solution does appear to be to build MPIR with -march=native, which apparently works. If anyone has any deep insight into this, please let us know. Maybe it is possible for us to do something about it upstream. I'm keen to fix it, I just don't understand the problem well enough. I think the following /proc/cpuinfo explains what happens: processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 42 model name : Intel(R) Core(TM) i5-2500K CPU @ 3.30GHz stepping : 7 cpu MHz : 3302.482 cache size : 6144 KB physical id : 0 siblings : 4 core id : 0 cpu cores : 4 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 5 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx lm constant_tsc rep_good nopl pni ssse3 lahf_lm bogomips : 6604.96 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: According to vendor/family/model, this is a Sandy Bridge. However, the CPU features (see flags) are seriously reduced compared to a real Sandy Bridge. Compiling with -march=SOMETHING means that 3 things have to be satisfied: (1) GCC must understand the command line flag (2) The assembler must understand the instructions (3) The processor must support the instructions Based on my observations, it seems that MPIR already checks (1) and (2). With -march=native, (1) and (3) are guaranteed, but not (2). When checking CFLAGS in MPIR, would it be possible to actually *run* an executable compiled with -march=SOMETHING, thereby checking (3)? Configure does run actual compile tests for the various -march options, I believe. But the problem (3) won't show up unless code specifically designed to compile to instructions that are only supported on that processor is compiled. I don't think this is feasible (and it is an autotools/configure issue anyway, not MPIR). Alternatively, check the feature flags from CPUID and lower the architecture based on that. This would be feasible I think, but basically defeats the entire strategy of selecting CPUs in MPIR. So does virtual box emulate a CPU with reduced features or something? yes. This was discussed here and/or on sage-support... I don't read sage-support unfortunately. I do browse sage-devel regularly, but sometimes miss relevant posts. (Having said that, I do recall this issue being discussed, and had thought that it was determined to be a bug in virtualbox.) Anyhow, please bear with me, as I am insanely ignorant about virtualbox. Can someone tell me what a usage case is for a virtual box which claims to have a given CPU, but which actually has a different (lesser) CPU? Would this be a standard application of the technology? In other words, would people regularly build or use a virtualbox which has a CPU whose features are different from the physical CPU of the box? And would it be usual to expect some of the features of the specified CPU to be missing. Is the restriction because of the native capabilities of the physical CPU (i.e. does virtualbox always do this when the physical CPU doesn't have the required features), or because the features of the CPU virtualbox is claiming to provide are not emulated and may be at some point when people write the relevant code, or because someone simply introduced a bug into virtualbox which has it specify the incorrect CPU (i.e. this is an isolated instance)? I'm just trying to determine what sort of problem it is, so that I can figure out if this is something we ought to work around or not. Do they consider this a bug, do you think? They are pwned by Oracle now, it's unlikely they'd fix anything quickly, if at all... I'm sorry to hear that. Bill. Dima Bill. -- You received this message because you are subscribed to the Google Groups mpir-devel group. To view this discussion on the web visit https://groups.google.com/d/msg/mpir-devel/-/jtKiGMfjbzgJ. To post to this group, send email to mpir-de...@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at
Re: [mpir-devel] Re: [sage-devel] Re: how do I build sage-5.0 on virtualbox?
On Sat, May 19, 2012 at 1:21 AM, Bill Hart goodwillh...@googlemail.com wrote: On 18 May 2012 17:46, Dima Pasechnik dimp...@gmail.com wrote: On Friday, 18 May 2012 18:35:04 UTC+2, Bill Hart wrote: On 18 May 2012 17:26, Jeroen Demeyer wrote: On 2012-05-18 17:29, Bill Hart wrote: I'm not sure how virtual boxes work. Do they emulate the CPU as well as the OS? Unfortunately, there isn't really a lot we can do if virtual box is going out of its way to report incorrect cpu parameters through the *assembly instruction* cpuid, if that is what is happening (I am not sure if it is or not). Unfortunately, the solution does appear to be to build MPIR with -march=native, which apparently works. If anyone has any deep insight into this, please let us know. Maybe it is possible for us to do something about it upstream. I'm keen to fix it, I just don't understand the problem well enough. I think the following /proc/cpuinfo explains what happens: processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 42 model name : Intel(R) Core(TM) i5-2500K CPU @ 3.30GHz stepping : 7 cpu MHz : 3302.482 cache size : 6144 KB physical id : 0 siblings : 4 core id : 0 cpu cores : 4 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 5 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx lm constant_tsc rep_good nopl pni ssse3 lahf_lm bogomips : 6604.96 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: According to vendor/family/model, this is a Sandy Bridge. However, the CPU features (see flags) are seriously reduced compared to a real Sandy Bridge. Compiling with -march=SOMETHING means that 3 things have to be satisfied: (1) GCC must understand the command line flag (2) The assembler must understand the instructions (3) The processor must support the instructions Based on my observations, it seems that MPIR already checks (1) and (2). With -march=native, (1) and (3) are guaranteed, but not (2). When checking CFLAGS in MPIR, would it be possible to actually *run* an executable compiled with -march=SOMETHING, thereby checking (3)? Configure does run actual compile tests for the various -march options, I believe. But the problem (3) won't show up unless code specifically designed to compile to instructions that are only supported on that processor is compiled. I don't think this is feasible (and it is an autotools/configure issue anyway, not MPIR). Alternatively, check the feature flags from CPUID and lower the architecture based on that. This would be feasible I think, but basically defeats the entire strategy of selecting CPUs in MPIR. So does virtual box emulate a CPU with reduced features or something? yes. This was discussed here and/or on sage-support... I don't read sage-support unfortunately. I do browse sage-devel regularly, but sometimes miss relevant posts. (Having said that, I do recall this issue being discussed, and had thought that it was determined to be a bug in virtualbox.) Anyhow, please bear with me, as I am insanely ignorant about virtualbox. Can someone tell me what a usage case is for a virtual box which claims to have a given CPU, but which actually has a different (lesser) CPU? Would this be a standard application of the technology? In other words, would people regularly build or use a virtualbox which has a CPU whose features are different from the physical CPU of the box? And would it be usual to expect some of the features of the specified CPU to be missing. Is the restriction because of the native capabilities of the physical CPU (i.e. does virtualbox always do this when the physical CPU doesn't have the required features), or because the features of the CPU virtualbox is claiming to provide are not emulated and may be at some point when people write the relevant code, or because someone simply introduced a bug into virtualbox which has it specify the incorrect CPU (i.e. this is an isolated instance)? The restriction is not due to the physical CPU at all. The physical CPU's architecture is equal to the architecture that MPIR detects. That is not the problem. The problem is that Virtualbox does not support certain instructions inside the VM. And that means that all VMs made by people using Virtualbox will probably have this problem. The conditions for this problem to occur are: 1) the physical CPU supports some instruction x; and 2) Virtualbox does not support running instruction x inside VMs; and 3) MPIR gets built with instruction x somewhere in its binary (or fails during the build due to instruction x being run somewhere in the build process),
[sage-devel] Re: how do I build sage-5.0 on virtualbox?
I think Keshav ran into the same problem and it was because vbox wasn't reporting the correct cpu parameters or something like that. On Friday, May 18, 2012 1:00:54 PM UTC+8, William wrote: Hi, I know something like this has been reported, but I can't figure out where. I am using Ubuntu 12.04 in Virtualbox on my Mac, and I can't build Sage because of MPIR. Which ticket? What's the workaround? This will probably impact me a lot, since I use virtual machines quite a bit... libtool: compile: ../strip_fPIC.sh ../yasm/yasm -I .. -f elf64 add_n.as -fPIC -DPIC -o .libs/add_n.o ../yasm/yasm -I .. -f elf64 add_n.as -D PIC -o .libs/add_n.o ../libtool: line 1133: 20873 Illegal instruction (core dumped) ../strip_fPIC.sh ../yasm/yasm -I .. -f elf64 add_n.as -fPIC -DPIC -o .libs/add_n.o make[4]: *** [add_n.lo] Error 1 make[4]: Leaving directory `/home/wstein/sage/build/sage-5.0/spkg/build/mpir-2.4.0.p3/src/mpn' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/home/wstein/sage/build/sage-5.0/spkg/build/mpir-2.4.0.p3/src' make[2]: *** [all] Error 2 make[2]: Leaving directory `/home/wstein/sage/build/sage-5.0/spkg/build/mpir-2.4.0.p3/src' Error building MPIR. real1m36.861s user0m35.050s sys0m15.297s Error installing package mpir-2.4.0.p3 -- William Stein Professor of Mathematics University of Washington http://wstein.org -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
