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. > -- 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-devel@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.
