[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-discuss] Very poor compilation performance in armhf chroot vs
Re: [Qemu-discuss] Very poor compilation performance in armhf chroot vs native
Thu, 12 Sep 2019 08:39:52 -0400
I think I understand the nuances of your last note on performance
comparison, indeed my approach there was not correct. The only real ARM
hardware I have is an rpi3b+ which isnt powerful enough for the task. I
think I will use the built-in cross-compile of chromium infrastructure and
figure out the ubuntu packaging then test the resulting ARM package/binary
in qemu and on rpi. That seems an easier path based on my skills!
Thank you for your guidance.
On Thu, Sep 12, 2019 at 5:25 AM Peter Maydell <address@hidden>
> On Thu, 12 Sep 2019 at 10:01, Aboul Fad <address@hidden> wrote:
> > Thank you for your reply. I am though stumped by that large of
> degradation using that simple test and when I attempted to compile my
> actual project (chromium) in the chroot, it was insanely slow.
> Emulation isn't fast, generally speaking.
> > Maybe this is off topic or meant for another mailing list: It seems my
> approach for cross compiling using qemu-arm/chroot is wrong. I know I can
> install a cross compile toolchain for arm target on the native OS and cross
> compile there. Sadly, I have a chromium packaging code that checks the host
> arch and based on that will or not cross-compile.
> > Is there a way to take advantage of a hybrid approach: compile on the
> native hardware/OS using cross compile toolchain and link in chroot using
> It is possible to just drop an x86 binary of a cross-compiler
> (x86-to-arm) into your chroot as its 'gcc' binary,
> and then you'll get native performance of the compiler
> parts. (You can extend that to eg using a native /bin/sh
> and similar binaries that get run a lot in compilation.)
> The trick is that you do need to make sure your cross
> compiler is configured to be equivalent to the compiler you're
> replacing it with (eg that it looks for headers and libraries
> in the same places, and so on).
> If you have performant and reliable native arm hardware to do the
> compilation on, this will almost always be the best option,
> compared to trying to maintain a cross-compile setup. But
> bear in mind that you want to compare performance of
> native compilation *on your arm hardware* to QEMU performance,
> not performance of native x86 compilation!
> -- PMM