things happened. Anyways I built out the qemu 1.4.1 and it is horribly SLOW. I don’t know why I haven’t even begun to think about gprof or what is up with GCC 4.7.2 trying to build GLIB2 as I’m having zero luck of building out a clean version.
It takes about as long as an XT to boot MS-DOS 5, so I really don’t see this as being terribly useful to anyone.
The issue happens since 1.0 here, and rebuilding glib2 doesn’t help.
well that is.. disappointing.. I don’t recall 1.3 being this horribly slow… 🙁
Just tried booting Fedora 18/x86_64 in qemu-system-x86_64 on a Centos 6.4 host, and it boots within seconds. I’m using -nographic though. Could it be that the graphics emulation makes it slow?
I need to get an ethernet cable to do more testing, just about everything is in flux @ home.. but in a good way..
Just got back from China with a hell of a cold (not the h7n9 or whatever) and just feel out of it… With the 1.0++ versions of Qemu the SDL graphics scaling did slow things considerably, but not to the point of it taking MS-DOS a minute to boot.
I wonder if GCC 4.7 is more so to blame on MinGW, as it has issues with headers and libs trying to build a full glib2…
Fwiw I’m using
gcc version 4.4.7 20120313 (Red Hat 4.4.7-3) (GCC)
My MinGW is 4.7.2 and it has all kinds of issues… I’ll have to see how to downgrade to 4.4.7 ….
QEMU is ridiculously slow here on Debian. It’s reached XT-based performance. In the end I just started using VMWare for everything.
On a side note, had to abuse dd to get a BeOS ISO working. BeOS was noted for confusing any emulator. As it turns out, the ISO doesn’t preserve any session information unlike like a cue sheet would, so I had rip out the BeFS partition and mount it on a second CD drive. I imagine it’d work in QEMU, but the performance was complete shite, making it unusable. But it works in VMWare!
Please, submit a bug. It shouldn’t be like that. Yes, it lost something like 5% performance last year to make compilation with clang possible, but not more than that.
At least I asked in maillist
http://www.mail-archive.com/[email protected]/msg142944.html
Can you please try building it without coroutine option? Otherwise, can you try bisecting as Kevin suggested? It might be enough to find just one commit causing the regression, to get an idea what generally went wrong.
coroutine is mandatory in QEMU now, you can’t disable it.
and it is discussed in IRC channel too, but no progress afterwards.
http://roy.dnsd.me/qemu-2013-02-19.log.html (search RT|AO lines and look the conversions after that line)
That’s strange. The sparc64 emulation became definitely faster than it was a year ago.