Erlang intrinsics (Was: Re: Extending arithmetic)

[Shawn Pearce]

I think we someone dropped this off the list. :-)

Using a binary for a matrix would be effective, as it would allow
erts to store multiple values in such a way that the SIMD ops could
get to it without requiring conversion.  However, if the Erlang software
wants to get access to the values as well, there is a cost to decoding
the floating point values or integer values from a binary into native
Erlang terms.

I'm remebering that in erts today a tuple is an array of words, where
the first word is the tuple length, and the remaining words are the
data.  Each word is exactly one term, where small ints can fit into
a single term.  I don't know how floating point is handled as a term
though.  If floating point values could be stored in the tuple directly,
without any tag bits, it would be possible for the SIMD to be operated
on a tuple, but still use native pattern matching and element BIFs
to work on the data values.

In a nut shell, erts does't have enough native types to make this
very efficent, imho.  Vectors and matricies need to be stored in a
format close enough to the native hardware that the SIMD operations can
be used directly, but that is still quickly accesiable in Erlang.

I could see tagging tuples 'ala records and using the tag to know
if the tuple is "special":

	{fvector, 1.2, 2.2, 3.2}

is a floating point vector of 3 values, and when created as a tuple is
actually going to be allocated like a tuple, but store the last 3 terms
directly inline as floating point values.

This of course, totally screws with all tuple operations in pattern
matching, BIFs, etc to the point that its not worth even discussing it
as an option.


Overloading tuple or binary syntax, but using an entirely new native
storage system within erts may be possible, but ugly:

	{1.2, 2.2, 3.2}/fvector

and then using that everwhere:

	eq({A,B,C}/fvector, TheVector)
		{A, B, C}/fvector = TheVector.

which could get ugly fast.


Per Bergqvist <per@REDACTED> wrote:
> You are probably right on the overhead.                               
>                                                                       
> Nevertheless, it would be extremely handy to have access to something 
> that could efficiently operate or a large chunks of data.             
> It would work perfect on binaries which is probably what one would    
> like to use for mungling.                                             
> This does not at all need to, and probably shouldn't, be implemented  
> by modifying standard operators.                                      
>                                                                       
> It could also be very nice with support for functions like multiply   
> and add and saturated add.                                            
>                                                                       
> Comments ?                                                            
>                                                                       
> /Per                                                                  
>                                                                       
> > My initial guess is that the time required to reformat an Erlang    
> tuple                                                                 
> > into a format suitable for operation by a SIMD instruction could    
> take                                                                  
> > as long as just doing the operations directly.  In other words, to  
> get                                                                   
> > this optimization it may be necessary to not use tuples, or standard
> > floating point values.                                              
> >                                                                     
> > But I know nothing of erts guts.  :-)                               
> >                                                                     
> > Per Bergqvist <per@REDACTED> wrote:                                 
> > > Yes and if this is not only implmented as syntactic sugar this    
> would                                                                 
> > > give the emulator a chance to use SIMD instructions (MMX, SIMD,   
> SIMD2,                                                                
> > > VIS, MVI etc) to get killer performance.                          
>                                                                       
> > > This sounds like a nice little Björn or Tony hack.                
>                                                                       
> >                                                                     
> > --                                                                  
> > Shawn.                                                              
> >                                                                     
> =========================================================             
> Per Bergqvist                                                         
> Synapse Systems AB                                                    
> Phone: +46 709 686 685                                                
> Email: per@REDACTED                                                   

-- 
Shawn.