[erlang-questions] Vector instructions

[Damien Morton]

Might be worthwhile looking at Python's NumPy module and the minor 
changes to the language they added to make the module nicer to use.

Im thinking particularly of the array slice notation.

On 4/8/2008 11:31 PM, Ulf Wiger (TN/EAB) wrote:
> Thomas Lindgren skrev:
>   
>> --- "Ulf Wiger (TN/EAB)" <ulf.wiger@REDACTED>
>> wrote:
>>     
>>> While we're at it, I'd like to throw in a wish to
>>> be able to handle real-time manipulation of media
>>> streams in Erlang (with good performance, that is).
>>>
>>> Think, for example, transcoding of video streams.
>>> Given Erlang's reputation as a language for
>>> telecoms,
>>> I don't think this is too far-fetched, even if it
>>> were to require some special syntax.
>>>       
>> You mean '[not] too far-fetched [as a feature provided
>> to the user base]' rather than the tech work itself?
>> :-) 
>>     
>
> Yes. (:
>
>
>   
>> Anyway, I think there are plenty of interesting
>> applications, including many outside of the telecoms
>> field.
>>     
>
> I'm sure.
>
>
>  > It's not quite in the core area of current
>   
>> Erlang practice, of course.
>>     
>
> Not current Erlang practice, no, but I see it as a
> fairly natural evolution, especially since the bit
> syntax has sort of laid the ground work for bit
> manipulation applications. Extending it to support more
> complex updates with competitive performance seems like
> a very worthy next step.
>
> In experiments we've made in the past, Erlang offers
> fairly good stream relay performance, as long as one
> doesn't need to do any deep inspection of the data.
> Updating the data as well makes it likely that an
> Erlang-based solution fails to reach even the lowest
> watermark in terms of performance. This is a pity,
> since e.g. complex media firewalls etc. ought to be
> fertile ground for Erlang, even in the absence of
> special hardware. Right now, Erlang is Just Right for
> the signaling parts of such an application, but
> Totally Wrong for the media parts. But there's a fairly
> big grey area, where acceptable performance of an all-
> Erlang implementation would be just perfect.
>
> Cryptol, http://www.cryptol.net, might offer some
> inspiration, BTW.
>
> BR,
> Ulf W
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://www.erlang.org/mailman/listinfo/erlang-questions
>
>
>