[erlang-questions] Erlang Cost Model

[Joe Armstrong]

On Thu, Sep 17, 2015 at 6:13 PM, zxq9 <zxq9@REDACTED> wrote:
> On 2015年9月17日 木曜日 11:56:47 you wrote:
>> On 09/17, Eric des Courtis wrote:
>> >Regardless if concurrency and parallelism plays a role *I still need to
>> >know if an operation in a sequential process I am working on is O(1) or
>> >O(n)* or am I missing something?

Note that O(1) does not mean fast - it just means "constant" time
without knowing *what* the constant is this information is useless.

O(N) means the time depends linearly upon N - but again
I doubt if anybody really knows if a function is O(N) - when you run
out of cache or swap space it will certainly not be linear.

Knowing that a function is O(N) is meaningless for performance estimation
if you don't know the range of N AND the constant values involved AND
the scale factors.

If you notice *time and time again* when people say "will Erlang be
fast enough to do this" and "this" is described in vague terms of
"lot's of users"
"lot's of data" - I reply - "give me the numbers" and "don't guess measure"

You need to numerically quantity the problem AND the target computer.

Even with all the numbers available predictions should be taken with a
lorry-load of salt.

Cheers
/Joe




>
> So that comment I made about "case 1" where there are a "lot of options already"...
>
>> These values are way more worthwhile as a property of libraries than
>> language, since they're far more impacted by the choice of algorithm
>> taken there.
>>
>> Let's look at a few modules:
>>
>> 1. Queue
>> 2. Maps
>> 3. Dict
>> 4. Array
>> 5. Gb_trees
>> 6. Sets
>> 7. Gb_sets
>> 8. ETS
>> 9. Orddict
>> 10. ordsets
>> 11. sofs
>> 12. Digraph
>> 13. lists:key* functions
>> 14. Proplists
>
> ...
>
>> 1. Message receiving (non-selective)
>> 2. Message receiving (selective)
>> 3. Sorting (lists:sort)
>
> These are costs specific to a particular operation happening on its own time, but tell you nothing meaningful about your system as a whole because all of this stuff is going on at once in different processes at different times. Sometimes you are in the situation where doubling your processing speed just means adding more cores. Sometimes not. You will either *know* at the outset of a project or *have no idea whether this is true* until you actually have something up and running that you can measure. Usually it is the latter.
>
> Very often you will find yourself able to approach a concurrent ideal after you've already got something implemented that does basically what you want, but not before. This is true whether or not you've got months of paid time to toy with an idea (HA HA! Like *that* ever happens!). It is nearly always faster to experiment with a prototype in Erlang than to just muse about it until the concept is perfect. Once you have a prototype, tweaking it is easy, and when that exists you can already measure stuff for real. This is why I am calling the *unqualified* utility of cost models into question.
>
> -Craig
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions