Re: Debian/SPARC[64]

[Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>]

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.