[erlang-questions] Erlang shows its slow face!

[Edmond Begumisa]

Richard...

> So my question is: if version 1 isn't performing "reasonably" acceptably  
> for Garcia's purpose, and version 1 isn't blatantly flawed. Isn't this a  
> strong indicator that he's using the wrong tool?
>

You can probably ignore that last question now. I've answered my own  
question after taking a closer look at other solutions!

- Edmond -


On Tue, 16 Nov 2010 02:02:50 +1100, Edmond Begumisa  
<ebegumisa@REDACTED> wrote:

> Hello Richard,
>
> I have a question...
>
>> Erlang is a fine tool for jobs like this one.
>
> Interesting... I would have never thought this. I would have  
> instinctively reached for a language with mutable memory, thinking that  
> this would make the most sense for combinatorial* work (I don't know  
> this for fact, and I could be very wrong, but that's what instinct would  
> tell me.) But then, I'm relatively new to Erlang.
>
> * I've been calling this permutation but I don't know if that's accurate.
>
>> There is little point in optimising a bad algorithm.
>
> Well put. But say you have an 'ok' algorithm. Not the best, but not  
> blatantly flawed either.
>
> I think of optimisation as something you put on a version 2 to-do list.  
> Optimisation to me means staring hard at code and trying to figure out  
> ways to get it to perform better (faster, less memory, less CPU time,  
> etc). This normally means re-writing code that's easy to follow into  
> code that's no-so-easy to follow. Mind you, for Erlang, I don't look at  
> parallelising as optimisation as others seem to. To me, it's just a  
> building block made available and normally it can be applied without  
> changing an algo too much (I'd say it's not used enough).
>
> Of all the variations presented so far, IMO, Garcia's first is the  
> easiest to follow (ignoring that obvious flaw with the repeated list:seq  
> call). A non-mathematical mind like myself can see exactly what he's  
> trying to do. The others (including the ones from Willem and Tony that I  
> tried to parallelise), seem harder to follow. Maybe that's coz they are  
> optimised versions. The authors could have stared long and hard.
>
> So my question is: if version 1 isn't performing "reasonably" acceptably  
> for Garcia's purpose, and version 1 isn't blatantly flawed. Isn't this a  
> strong indicator that he's using the wrong tool?
>
> - Edmond -
>
> On Mon, 15 Nov 2010 12:29:49 +1100, Richard O'Keefe <ok@REDACTED>  
> wrote:
>
>>
>> On 14/11/2010, at 10:17 PM, Hynek Vychodil wrote:
>>  Anyway Erlang is not
>>> right tool for this job. You should use NIF if performance matter.
>>
>> Erlang is a fine tool for jobs like this one.
>> In fact, given its support for large integers,
>> it is about as good for combinatorial algorithms as
>> Smalltalk, though perhaps not as good as Lisp.
>> (But see LFE...)
>>
>> There is little point in optimising a bad algorithm.
>> A fairly naive rewrite turns it from O(N**3) into O(N**2).
>> What really counts here is how easy it is to spot the
>> algorithmic problem and switch to a better algorithm.
>>
>>
>>
>> ________________________________________________________________
>> erlang-questions (at) erlang.org mailing list.
>> See http://www.erlang.org/faq.html
>> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED
>>
>
>


-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/