[Qemu-devel] Re: Performances on Mac OS X

[Qemu-devel] Re: Performances on Mac OS X

[Joshua Root]

Laurent Amon <amon@stanfordalumni.org> wrote:

>I was wondering whether the implementation of qemu is tied to gcc or 
>if it might
>be interesting to try to compile using IBM's compiler, which is able 
>to generate
>Altivec code...

I have tried compiling qemu with xlc and it chokes on the asm. I 
believe that it uses a different syntax than gcc for this. I don't 
know what its syntax is, but if anybody does it shouldn't be too hard 
to make a patch which lets it compile.

Using xlc does seem to give substantially better performance than 
gcc, and not just on floating point code.

Cheers,
Josh.
-- 
Joshua Root                  | "Dream up the kind of world you want to live
                              | in. Dream out loud at high volume. That's
z3022016@student.unsw.edu.au | what we do for a living." - Bono

[Qemu-devel] Re: Performances on Mac OS X

[Ben Pfaff]

Joshua Root <z3022016@student.unsw.edu.au> writes:

> I have tried compiling qemu with xlc and it chokes on the asm. I
> believe that it uses a different syntax than gcc for this. I don't
> know what its syntax is, but if anybody does it shouldn't be too hard
> to make a patch which lets it compile.

For what it's worth, I've heard that Intel's compiler supports
GCC's assembler syntax.
-- 
I love deadlines.
I love the whooshing noise they make as they go by.
--Douglas Adams

Re: [Qemu-devel] Intel compiler (was Re: Performances on Mac OS X)

[André Braga]

FWIW, I'm experimenting with compiling QEMU under Windows (because my
Linux install became officially screwed... Stupid Debian.) and the
Intel compiler (I'm a sucker for performance :D), and it chokes at
some GNUisms like __asm__ and whatnot.



On Wed, 04 Aug 2004 09:31:07 -0700, Ben Pfaff <blp@cs.stanford.edu> wrote:
> Joshua Root <z3022016@student.unsw.edu.au> writes:
> 
> > I have tried compiling qemu with xlc and it chokes on the asm. I
> > believe that it uses a different syntax than gcc for this. I don't
> > know what its syntax is, but if anybody does it shouldn't be too hard
> > to make a patch which lets it compile.
> 
> For what it's worth, I've heard that Intel's compiler supports
> GCC's assembler syntax.
>


--
"I invented the term Object-Oriented, and I can tell you I did not
have C++ in mind"
Alan Kay

RE: [Qemu-devel] Re: Performances on Mac OS X

[Roine Gustafsson]

Joshua Root [z3022016@student.unsw.edu.au] wrote:
> Laurent Amon <amon@stanfordalumni.org> wrote:
> 
> >I was wondering whether the implementation of qemu is tied to gcc or
> >if it might
> >be interesting to try to compile using IBM's compiler, which is able 
> >to generate
> >Altivec code...
> 
> I have tried compiling qemu with xlc and it chokes on the asm. I 
> believe that it uses a different syntax than gcc for this. I don't 
> know what its syntax is, but if anybody does it shouldn't be too hard 
> to make a patch which lets it compile.
> 
> Using xlc does seem to give substantially better performance than 
> gcc, and not just on floating point code.
> 

xlc is picky with the source and takes FOREVER to compile with -O6. However,
xlc is object compatible with gcc, so usually you just use xlc on core stuff
that needs the speed, and gcc for everything else.
Compile everything with gcc, rm the object files you want to remake with xlc
(based on profiling), edit the makefiles to use xlc and make again. 

  /Roine

Re: [Qemu-devel] Re: Performances on Mac OS X

[Fabrice Bellard]

Don't spend your time in using another compiler than gcc : most of the 
time is spent in the generated code, and the quality of this code relies 
on very small functions which are too simple for being optimized better.

Fabrice.

Roine Gustafsson wrote:
> Joshua Root [z3022016@student.unsw.edu.au] wrote:
> 
>>Laurent Amon <amon@stanfordalumni.org> wrote:
>>
>>
>>>I was wondering whether the implementation of qemu is tied to gcc or
>>>if it might
>>>be interesting to try to compile using IBM's compiler, which is able 
>>>to generate
>>>Altivec code...
>>
>>I have tried compiling qemu with xlc and it chokes on the asm. I 
>>believe that it uses a different syntax than gcc for this. I don't 
>>know what its syntax is, but if anybody does it shouldn't be too hard 
>>to make a patch which lets it compile.
>>
>>Using xlc does seem to give substantially better performance than 
>>gcc, and not just on floating point code.
>>
> 
> 
> xlc is picky with the source and takes FOREVER to compile with -O6. However,
> xlc is object compatible with gcc, so usually you just use xlc on core stuff
> that needs the speed, and gcc for everything else.
> Compile everything with gcc, rm the object files you want to remake with xlc
> (based on profiling), edit the makefiles to use xlc and make again. 
> 
>   /Roine
> 
> 
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
> 

Re: [Qemu-devel] Re: Performances on Mac OS X

[André Braga]

Still, there are the graphic routines (which are *painfully slow* when
it goes to VESA mode; console is rather zippy!) and I'm positive the
compiler can optimize FP instructions with SSE or something and/or
reorder/reschedule/etc the instructions in order to ameliorate cache
hits and whatnot.

I still believe it's not a complete waste of time.

On Wed, 04 Aug 2004 22:56:30 +0200, Fabrice Bellard <fabrice@bellard.org> wrote:
> Don't spend your time in using another compiler than gcc : most of the
> time is spent in the generated code, and the quality of this code relies
> on very small functions which are too simple for being optimized better.
> 
> Fabrice.
> 


-- 
"A year spent in artificial intelligence is enough to make one believe in God"
Alan J. Perlis

Re: [Qemu-devel] Re: Performances on Mac OS X

[Fabrice Bellard]

André Braga wrote:
> Still, there are the graphic routines (which are *painfully slow* when
> it goes to VESA mode; console is rather zippy!) and I'm positive the
> compiler can optimize FP instructions with SSE or something and/or
> reorder/reschedule/etc the instructions in order to ameliorate cache
> hits and whatnot.

FP is not used in QEMU except for the CPU emulation itself, so expect no 
gain. About VESA with the Cirrus VGA card, the code just needs to be 
optimized !

Fabrice.

Re: [Qemu-devel] Re: Performances on Mac OS X

[André Braga]

What if QEMU uses smarter FP code (for a given architecture) when
emulating the CPU itself? Like always using SSE2, since they have
their own registers, instead of going to the stack of the 387 unit?
Ain't that smarter?

About VESA: one can never have too many compiler optimizations :D
Faster is always good in emulation, and if you can have gains by just
switching compilers, why not use this?

I promise I'll look into the VESA code some time. I'm in love with
QEMU, you know ;D

On Wed, 04 Aug 2004 23:25:01 +0200, Fabrice Bellard <fabrice@bellard.org> wrote:
> FP is not used in QEMU except for the CPU emulation itself, so expect no
> gain. About VESA with the Cirrus VGA card, the code just needs to be
> optimized !
> 
> Fabrice.
> 


-- 
"Logic: merely enables one to be wrong with authority"
Doctor Who

Re: [Qemu-devel] Re: Performances on Mac OS X

[Lindsay Mathieson]

André Braga wrote:

>About VESA: one can never have too many compiler optimizations :D
>  
>
Bugs. Curly, erratic, hard to track down bugs. Enough said.

-- 
When life hands you lemons, ask for a bottle of gin and tonic.

Re: [Qemu-devel] Re: Performances on Mac OS X

[Laurent Amon]

On 4 août 04, at 23:37, André Braga wrote:
> I promise I'll look into the VESA code some time. I'm in love with
> QEMU, you know ;D
>
I haven't had a look at the graphic code, but I would say that the best 
optimization would be to write the emulation for a video card that has 
as much hardware acceleration as possible and write the code to map 
directly to corresponding hi-level routines in the host OS as possible. 
Major stuff, if you ask me.

Lga.

Re: [Qemu-devel] Re: Performances on Mac OS X

[André Braga]

That surely is the best optimization. However, a less ambitious goal
would be redoing the SDL backend because I'm positive it can be done
better. Just look at how many games manage to eat gobs of CPU time
(like an emulator does) and still have responsive graphics under
SDL...

I might be talking off my butt here, but I believe there is a lot of
room for improvement. I'm starting with the easy things (compiler
optimizations) before I put my furry claws on it. :)

On Wed, 4 Aug 2004 23:47:56 +0200, Laurent Amon <amon@stanfordalumni.org> wrote:
> I haven't had a look at the graphic code, but I would say that the best
> optimization would be to write the emulation for a video card that has
> as much hardware acceleration as possible and write the code to map
> directly to corresponding hi-level routines in the host OS as possible.
> Major stuff, if you ask me.
> 

--
"Wherever you go, There you are"
Buckaroo Banzai

Re: [Qemu-devel] Re: Performances on Mac OS X

[Joshua Root]

Fabrice Bellard <fabrice@bellard.org> wrote:
>Don't spend your time in using another compiler than gcc : most of 
>the time is spent in the generated code, and the quality of this 
>code relies on very small functions which are too simple for being 
>optimized better.

What if more than one instruction worth of C were chained together 
before being compiled? Would that make more optimisable code? Could 
this even be done at runtime? Translation time would be greatly 
increased of course, making caching even more important.

Is this technically feasible? Or would my time be better spent 
writing a hand optimised code translator? ;)

Cheers,
Josh

Re: [Qemu-devel] Re: Performances on Mac OS X

[Joe Batt]

On Fri, 2004-08-13 at 05:17, Joshua Root wrote:
> Fabrice Bellard <fabrice@bellard.org> wrote:
> >Don't spend your time in using another compiler than gcc : most of 
> >the time is spent in the generated code, and the quality of this 
> >code relies on very small functions which are too simple for being 
> >optimized better.
> 
> What if more than one instruction worth of C were chained together 
> before being compiled? Would that make more optimisable code? Could 
> this even be done at runtime? Translation time would be greatly 
> increased of course, making caching even more important.

This sounds like HotSpot for qemu.  Within qemu, how much work would it
take to retranslate after profiling execution, like HotSpot server
does?  I've looked a bit, but I get lost  in all the macros.  Where
would someone start looking to understand the translation process?

Where would one look to start on SMP support both for the guest and the
host?

Joe

Re: [Qemu-devel] Re: Performances on Mac OS X

[dguinan]

[-- Attachment #1: Type: text/plain, Size: 424 bytes --]


On Aug 13, 2004, at 2:14 AM, Joe Batt wrote:
> This sounds like HotSpot for qemu.  Within qemu, how much work would it
> take to retranslate after profiling execution, like HotSpot server
> does?  I've looked a bit, but I get lost  in all the macros.  Where
> would someone start looking to understand the translation process?

I think there is room for some interesting tricks here, and not just in 
runtime optimization.

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2359 bytes --]

Re: [Qemu-devel] Re: Performances on Mac OS X

[Joshua Root]

Roine Gustafsson wrote:
>Joshua Root [z3022016@student.unsw.edu.au] wrote:
>
>>I have tried compiling qemu with xlc and it chokes on the asm. I 
>>believe that it uses a different syntax than gcc for this. I don't 
>>know what its syntax is, but if anybody does it shouldn't be too 
>>hard to make a patch which lets it compile.
>
>
>xlc is picky with the source and takes FOREVER to compile with -O6. However,
>xlc is object compatible with gcc, so usually you just use xlc on core stuff
>that needs the speed, and gcc for everything else.

Just for the record, here's a list of things in the qemu source which 
xlc doesn't like:

* __asm__
* this sort of thing: asm volatile ("dcbst 0,%0" : : "r"(ptr) : "memory");
* "..." notation in switch cases
* macros with variable number of arguments
* array definitions with no size specified

Cheers,
Josh