Does DMD perform processor specific optimizations? Does it make use of MMX, SSE and other such extensions? I am creating high performance applications and these optimizations would really come in handy.

Orgoton wrote:
> Does DMD perform processor specific optimizations? Does it make use of MMX, SSE and other such extensions? I am creating high performance applications and these optimizations would really come in handy.

Not at the moment (as far as I know), although there have been some long discussions about it.  Of course you can always do it in ASM. Performance wise, you should be able to get near or better then C++.

PS - I'm looking forward to seeing these in D as well.

-Joel

janderson Wrote:

> Orgoton wrote:
> > Does DMD perform processor specific optimizations? Does it make use of MMX, SSE and other such extensions? I am creating high performance applications and these optimizations would really come in handy.
> 
> Not at the moment (as far as I know), although there have been some long discussions about it.  Of course you can always do it in ASM. Performance wise, you should be able to get near or better then C++.
> 
> PS - I'm looking forward to seeing these in D as well.
> 
> -Joel


I was thinking that some kind of standardized vector intrinsic interface would be really cool.  Think std.intrinsic or Tango's core.intrinsic, extended to vectorized types, with one interface for various underlying implementations.  I don't know enough about the functional overlap of AltiVec with x86 SIMD to know if it is feasible or not though, especially if things like alignment contraints are different for each set.

Howard Berkey wrote:
> janderson Wrote:
> 
>> Orgoton wrote:
>>> Does DMD perform processor specific optimizations? Does it make use of MMX, SSE and other such extensions? I am creating high performance applications and these optimizations would really come in handy.
>> Not at the moment (as far as I know), although there have been some long discussions about it.  Of course you can always do it in ASM. Performance wise, you should be able to get near or better then C++.
>>
>> PS - I'm looking forward to seeing these in D as well.
>>
>> -Joel
> 
> 
> I was thinking that some kind of standardized vector intrinsic interface would be really cool.  Think std.intrinsic or Tango's core.intrinsic, extended to vectorized types, with one interface for various underlying implementations.  I don't know enough about the functional overlap of AltiVec with x86 SIMD to know if it is feasible or not though, especially if things like alignment contraints are different for each set.
> 

Some time ago, I wrote a simple library that extended arrays of basic types with parallel operations (like add, mult, madd, etc.) that were coded in MMX.  Never bothered to publish it since I wasn't sure if it was actually useful or not...

That said, it's certainly possible to add some of this stuff in library code.  It's definitely worth doing it if only because you need to teach yourself some assembler to do it.

	-- Daniel

-- 
Unlike Knuth, I have neither proven or tried the above; it may not even make sense.

v2sw5+8Yhw5ln4+5pr6OFPma8u6+7Lw4Tm6+7l6+7D i28a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP  http://hackerkey.com/

Daniel Keep Wrote:

> 
> 
> Howard Berkey wrote:
> > janderson Wrote:
> > 
> >> Orgoton wrote:
> >>> Does DMD perform processor specific optimizations? Does it make use of MMX, SSE and other such extensions? I am creating high performance applications and these optimizations would really come in handy.
> >> Not at the moment (as far as I know), although there have been some long discussions about it.  Of course you can always do it in ASM. Performance wise, you should be able to get near or better then C++.
> >>
> >> PS - I'm looking forward to seeing these in D as well.
> >>
> >> -Joel
> > 
> > 
> > I was thinking that some kind of standardized vector intrinsic interface would be really cool.  Think std.intrinsic or Tango's core.intrinsic, extended to vectorized types, with one interface for various underlying implementations.  I don't know enough about the functional overlap of AltiVec with x86 SIMD to know if it is feasible or not though, especially if things like alignment contraints are different for each set.
> > 
> 
> Some time ago, I wrote a simple library that extended arrays of basic types with parallel operations (like add, mult, madd, etc.) that were coded in MMX.  Never bothered to publish it since I wasn't sure if it was actually useful or not...
> 
> That said, it's certainly possible to add some of this stuff in library code.  It's definitely worth doing it if only because you need to teach yourself some assembler to do it.
> 
> 	-- Daniel
> 

My fear is that the SIMD operations themselves might not be orthogonal enough across various processors to be able to abstract anything but a small subset in a standardized way in a platform library like phobos or Tango.  I have not really looked in to them enough to know; this is just something that I am kind of tangentially interested in and I thought it would be cool if possible.

The other option of course is to have the compiler generate and use them internally when possible.  And of course the two options are not mutually exclusive either.

I think that D has a really good start on this now; having things like std.intrinsic in the standard librar(ies) is actually very nice.  Having alignment as a specifier baked into the language itself is also great; no more ugly compiler specific stuff like

#ifdef __GNUC__
__attribute__((aligned(16)));
#endif

or whatever.

But I digress from the original question :)

Howard

Daniel Keep wrote:
> Some time ago, I wrote a simple library that extended arrays of basic
> types with parallel operations (like add, mult, madd, etc.) that were
> coded in MMX.  Never bothered to publish it since I wasn't sure if it
> was actually useful or not...

Please do publish it. I'd like to teach myself some assembly programming, and it'd be nice to see someone else's code for inlining array operations with MMX instructions.

If you don't post it at dsource, at least send me an email with the code attached.

Thanks!!

--benji

Daniel Keep Wrote:

<snip>
> v2sw5+8Yhw5ln4+5pr6OFPma8u6+7Lw4Tm6+7l6+7D i28a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP  http://hackerkey.com/

At first I thought that was a new means of munging email addresses.  Now I see it's a new version of geek code.

But is there any tool for decoding the version you've used, or is one supposed to do it manually?

Stewart.

Stewart Gordon kirjoitti:
> Daniel Keep Wrote:
> 
> <snip>
>> v2sw5+8Yhw5ln4+5pr6OFPma8u6+7Lw4Tm6+7l6+7D i28a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP  http://hackerkey.com/
> 
> At first I thought that was a new means of munging email addresses.  Now I see it's a new version of geek code.
> 
> But is there any tool for decoding the version you've used, or is one supposed to do it manually?

A true hacker probably automagically decodes it. :) The program on the website happily decrypts it after replacing v2 with v4.

Stewart Gordon wrote:
> Daniel Keep Wrote:
> 
> <snip>
>> v2sw5+8Yhw5ln4+5pr6OFPma8u6+7Lw4Tm6+7l6+7D i28a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP  http://hackerkey.com/
> 
> At first I thought that was a new means of munging email addresses.  Now I see it's a new version of geek code.
> 
> But is there any tool for decoding the version you've used, or is one supposed to do it manually?
> 
> Stewart.

I did write a Python script that would decode it, but that was ages ago and stuffed if I can find the damn thing...

	-- Daniel

-- 
Unlike Knuth, I have neither proven or tried the above; it may not even make sense.

v2sw5+8Yhw5ln4+5pr6OFPma8u6+7Lw4Tm6+7l6+7D i28a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP  http://hackerkey.com/

Sweet.  That's actually rather terse, and interesting...

sw7CSDhw5ln7pr7OSAPFck2ma5u6LSBw4Xl6GLSiOSciTE/e4t3b6AHen4g5VGPa2Xs6MRr8p-2/-5 hackerkey.com