[fedora-arm] F14 qemu arm default board

omalleys at msu.edu omalleys at msu.edu
Thu Dec 30 23:12:42 UTC 2010

Quoting Andy Green <andy at warmcat.com>:

> On 12/30/10 22:28, Somebody in the thread at some point said:
>>> At that time the alternative it was being compared to was a real
>>> 532MHz ARM11 with 128MB of DDR, it was able to compile "much" faster
>>> than the qemu box. This year there are Cortex A9 ARM boxes available
>>> are much faster than that and next year there'll be Cortex A15 ~2GHz
>>> quad core natively. Qemu and intel boxes aren't getting faster at that
>>> kind of rate any more.
>> No there is a huge performance difference from what I have seen. However
>> I did get some boost by using a newer kernel, and by switching the boards.
>> I was just trying to determine whether or not I should bother try to
>> test ARM11xx for qemu compilation speed or whether I should try
>> something else.
> I don't think it'll make much difference since what's making qemu  
> slow will remain the same if it's emulating ARM9 or ARM11 or whatever.
> But the bigger point is it'd be OK suffering somewhat with a slow  
> qemu for a while if you know in the long run that the way you're  
> doing it will win out and you gained experience with it.  But it  
> seems to me qemu is already way inferior to native ARM devices and  
> the performance gap between qemu and native hardware is set to get  
> dramatically worse in the next year or so.
> The only benefit you can squeeze out of qemu that's hard with a real  
> board is radical amounts of RAM, and I guess that too will be  
> possible with real boards shortly at a reasonable price.

The ability to easily revert and test things. :)

I actually like VM's for testing and development. You just spin off a  
clone of your base dev environment for each project and a clone of a  
base image for your production environment. Then make your image, test  
it, then move it to production hardware.  But I was doing a lot of  
solaris development and between gcc and Sun cc and various versions of  
make, autoconf, etc. It is just easier to waste the disk space and  
shut it off and archive it when you are done.

Granted in this case it is rather pokey. :)

More information about the arm mailing list