<div dir="ltr">Regardless if concurrency and parallelism plays a role <b>I still need to know if an operation in a sequential process I am working on is O(1) or O(n)</b> or am I missing something?</div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Sep 17, 2015 at 12:17 AM, zxq9 <span dir="ltr"><<a href="mailto:zxq9@zxq9.com" target="_blank">zxq9@zxq9.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Wednesday 16 September 2015 19:25:41 Eric des Courtis wrote:<br>
> As a first step lets focus on the complexity of the operations (ignoring<br>
> any associated constants or specific time measurements). Just so newcomers<br>
> to Erlang can validate their assumptions.<br>
><br>
> I will start:<br>
><br>
> Adding to the beginning of a list is O(1)<br>
> Adding to the end of a list is O(n)<br>
><br>
> Sending a large binary to another node is O(n)<br>
> Sending a large binary to other processes on the same node is O(1)<br>
><br>
> etc...<br>
<br>
</span>That is going to wind up reading very similarly to the cost model for any language that uses similar data structures and executes in a managed environment.<br>
<br>
And its not very useful.<br>
<br>
Here is why: "Just so newcomers to Erlang can validate their assumptions."<br>
<br>
Their assumptions are going to be totally invalid (which is different from being wrong) because using concurrent processes as a basic component of a model of computation is *a different model of computation* than these cost models assume. So whatever these "newcomer assumptions" are will not make sense in real programs, unless newcomers only write sequential Erlang programs.<br>
<br>
This is like trying to tune a violin by drum tempo or tune a drum to output from a spectroscope. Sure, each involves a "frequency", but the underlying concept is so different in each case they simply don't compare.<br>
<br>
The only place cost models make sense is:<br>
1- Dealing with a technically ignorant bureaucracy that doesn't understand why this makes no sense, but have the power to can your project if you can't justify it to some Soviet standard<br>
2- Trying to squeeze the last bit of performance out of a bottleneck you can't imagine a way around<br>
<br>
Case 1 is in error, as Erlang will fail in most competitions that measure sequential speed. Meh.<br>
<br>
Case 2 is generally in error as well, as the goal should usually be to avoid having bottlenecks to begin with, not making bottlenecks more performant. (There are standard answers for that one time when you really, genuinely need to make a pig fly.)<br>
<br>
The mapping of operations to cost in terms of scheduler reductions is the closest thing to a meaningful number I think there is. (If this is wrong someone please correct me or expand on this -- I am sort of curious, though only morbidly so. But don't go on and on about how l33t dirty schedulers and NIFs are.)<br>
<br>
In actual programs I've written (and am writing) that handle actual problems for actual users I've had to think about this exactly one time, ever, and that turned out to be a big fat waste of time once I stepped back and took a second look from above.<br>
<br>
What is the purpose of such a cost model? What is its use? Why is this needed?<br>
<br>
The concept is so different that I think this is probably a sort of X-Y problem. If, instead of asking for a cost model, the intended utility of the cost model were explained perhaps more useful things would start popping up on the ML.<br>
<br>
-Craig<br>
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</div></div></blockquote></div><br></div>