[erlang-questions] Erlang shows its slow face!

[Edmond Begumisa]

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/