On 27/02/15 22:45, Karel Gardas wrote: > Hi Mark, > > another report, so when not using virtio for drive I'm able to compile > few haskell packages which is about a week or so of run. I've seen just > one issue when the compilation stopped for about 22 hours and then > continued well. > > Anyway, as you are dealing with SPARC/Qemu, I'd like to note that I'm a > little bit surprised how slow this is in comparison with ARMv8 > emulation. Please don't get me wrong! It's a tremendous value to have > SPARC/64 emulated at all. It's just a little bit surprise for me since I > always first nbench2 emulator and then work with it when the results are > kind of acceptable. Basically I get +- similar nbench2 results from > running SPARC64 and AArch64 emulation with Linux and nbench2 on top of > that, cut: > > SPARC64: > MEMORY INDEX : 3.176 > INTEGER INDEX : 3.640 > FLOATING-POINT INDEX: 0.528 > Baseline (LINUX) : AMD K6/233*, 512 KB L2-cache, gcc 2.7.2.3, > libc-5.4.38 > > ARMv8: > MEMORY INDEX : 2.378 > INTEGER INDEX : 3.249 > FLOATING-POINT INDEX: 0.708 > Baseline (LINUX) : AMD K6/233*, 512 KB L2-cache, gcc 2.7.2.3, > libc-5.4.38 > > > and yet, it looks like SPARC is more than 7 times slower on compilation > of the nbench. I guess it's also slower generally. For your information > it takes around 1 minute to compile nbench2 on ARMv8 and more then 7 > minutes to compile on SPARC64. > > Do you have any idea why this may be so different? Both running the same > qemu version and on the same host OS and the same host machine (Solaris > 11/xeon e5-2620). > > Thanks! > Karel
Hi Karel, Thanks for the update. I remember the previous QEMU SPARC maintainer pointing out that due to the SPARC CPU windows, the TCG (code generator) can spend a lot of time switching register windows. This is because other architectures can map most of their emulated registers to the host registers for speed, whereas a single register window change under SPARC requires multiple memory accesses in order to get the new emulated window values into the host CPU. The other possibility could be different I/O subsystems used between ARMv8 and SPARC. Do you know which disk controller the ARMv8 is using? It may also be worth running a heavy compile with profiling enabled and then posting the gprof output somewhere so I can take a look. ATB, Mark. -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54f35f5c.6010...@ilande.co.uk