Re: Debian/SPARC[64]
- To: Karel Gardas <karel.gardas@centrum.cz>
- Cc: debian-sparc@lists.debian.org
- Subject: Re: Debian/SPARC[64]
- From: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
- Date: Sun, 01 Mar 2015 18:50:04 +0000
- Message-id: <[🔎] 54F35F5C.6010804@ilande.co.uk>
- In-reply-to: <54F0F384.5010308@centrum.cz>
- References: <54B01418.7080408@centrum.cz> <1420844741.2022.12.camel@debian.org> <1421011111.776008317.1leg045z@frv40.fwdcdn.com> <54B386BA.8090602@centrum.cz> <54B3BEE9.8010106@ilande.co.uk> <54C72E8D.3010401@centrum.cz> <54C814C6.1060904@ilande.co.uk> <54F0F384.5010308@centrum.cz>
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.
Reply to: