Re: [mp3encoder] Re: Some Amd64 timings
From: Gabriel Bouvigne <[EMAIL PROTECTED]> Subject: Re: [mp3encoder] Re: Some Amd64 timings Date: Sat, 28 Feb 2004 16:16:11 +0100 > >>>>As gcc should be able to utilize MMX, SSE, SSE2 and 3dnow > >>>>with inline assembly now, it would be nice if someone would > >>>>try to use it instead of using a 3rd party assembler. > >>> > >>>In short, they should be easier to use well than raw assembly, > >>>whether inlined or external. > > Isn't intrinsics specific to the compiler, with gcc intrinsics not > usable with VC or ICL, and VC intrinsics not usable with gcc? Yes. they are same between ICC/VC6+Processor Pack/GCC, at least for SSE/MMX intrinsic, because Intel standarized and offered the header The problem is about 3DNow!. It is only available for VC (from MS) (and maybe on icc on windows). No gcc support and no none-windows support for it (unless you break the license ...) -- Takehiro TOMINAGA // may the source be with you! ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [mp3encoder] Re: Some Amd64 timings
From: "James H. Cloos Jr." <[EMAIL PROTECTED]> Subject: [mp3encoder] Re: Some Amd64 timings Date: Thu, 26 Feb 2004 18:43:42 -0500 > >>>>> "Alexander" == Alexander Leidinger <[EMAIL PROTECTED]> writes: > > Alexander> As gcc should be able to utilize MMX, SSE, SSE2 and 3dnow > Alexander> with inline assembly now, it would be nice if someone would > Alexander> try to use it instead of using a 3rd party assembler. > > Actually, you realy want to the the intrinsics rather than assembly. > The intrinsics look just like function calls at the C level (making > them easier to understand), the compiler deals with the minutiae of > register assignments, function call abi issues, et al so you only > have the algorithm to deal with, and the compiler's optimizer is not > blocked. Do you think current compiler is better than human to optimize the SSE code written with intrisics ? I don't think so > In short, they should be easier to use well than raw assembly, > whether inlined or external. Agree. If I need to write a "reasonably" fast program in a hurry from scratch, I usually use instisic. But for LAME, I need "extremely" fast program and there's no deadline and there's GOGO, full-assembler mp3 encoder based on LAME. And in these days, the intrisic can be used only a newer compilers and they are buggy... This is why I used NASM instead of intrisics. Now the situation is changed about availability of intrisics, but the rest of them are not changed much, IMHO. Anyway, if someone writes the asm code with intrisics, it will be welcomed if it runs fine, of course. -- Takehiro TOMINAGA // may the source be with you! ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [mp3encoder] Re: Some Amd64 timings
As gcc should be able to utilize MMX, SSE, SSE2 and 3dnow with inline assembly now, it would be nice if someone would try to use it instead of using a 3rd party assembler. In short, they should be easier to use well than raw assembly, whether inlined or external. Isn't intrinsics specific to the compiler, with gcc intrinsics not usable with VC or ICL, and VC intrinsics not usable with gcc? Regards, -- Gabriel Bouvigne www.mp3-tech.org personal page: http://gabriel.mp3-tech.org ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
[mp3encoder] Re: Some Amd64 timings
Hello Alexander On 28.02.04, you wrote: > I have patches locally, but I hadn't time yet to review this > submission... feel free to have a look at it, it's in > http://www.leidinger.net/lame/ thx, I'll take a look at it. Regards -- Pegasos PPC ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [mp3encoder] Re: Some Amd64 timings
On Fri, 27 Feb 2004 19:03:08 +0200 Thomas <[EMAIL PROTECTED]> wrote: > >> As gcc should be able to utilize MMX, SSE, SSE2 and 3dnow > >> with inline assembly now, it would be nice if someone would > >> try to use it instead of using a 3rd party assembler. > > In short, they should be easier to use well than raw assembly, > > whether inlined or external. I agree. > What about the much more powerful Altivec/VMX ? I have patches locally, but I hadn't time yet to review this submission... feel free to have a look at it, it's in http://www.leidinger.net/lame/ Bye, Alexander. -- I will be available to get hired in April 2004. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
[mp3encoder] Re: Some Amd64 timings
Hello James On 26.02.04, you wrote: >> "Alexander" == Alexander Leidinger <[EMAIL PROTECTED]> writes: > >> As gcc should be able to utilize MMX, SSE, SSE2 and 3dnow >> with inline assembly now, it would be nice if someone would >> try to use it instead of using a 3rd party assembler. > In short, they should be easier to use well than raw assembly, > whether inlined or external. What about the much more powerful Altivec/VMX ? Regards -- Pegasos PPC ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
[mp3encoder] Re: Some Amd64 timings
> "Alexander" == Alexander Leidinger <[EMAIL PROTECTED]> writes: Alexander> As gcc should be able to utilize MMX, SSE, SSE2 and 3dnow Alexander> with inline assembly now, it would be nice if someone would Alexander> try to use it instead of using a 3rd party assembler. Actually, you realy want to the the intrinsics rather than assembly. The intrinsics look just like function calls at the C level (making them easier to understand), the compiler deals with the minutiae of register assignments, function call abi issues, et al so you only have the algorithm to deal with, and the compiler's optimizer is not blocked. In short, they should be easier to use well than raw assembly, whether inlined or external. -JimC ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
