[erlang-questions] Strange optimization result

[Anders Nygren]

On 10/22/07, Thomas Lindgren <thomasl_erlang@REDACTED> wrote:
>
> --- Anders Nygren <anders.nygren@REDACTED> wrote:
>
> > I did the change to ets:update_counter last night,
> > on my dual
> > core laptop that made an improvement from my
> > previously
> > reported
> > real    0m6.305s
> > user    0m10.149s
> > sys     0m0.380s
> >
> > to
> > real    0m5.094s
> > user    0m8.781s
> > sys     0m0.352s
> >
> > To avoid the update_counter race condition I have
> > only one process
> > that all workers report their matches to.
> >
> > I had some problems with native compilation but
> > finally made it work
> > and
> > real    0m2.192s
> > user    0m3.260s
> > sys     0m0.336s
>
> Nice -- so native compilation yields a 2.3x speedup
> versus the ets-based version (and 2.87x versus the
> original). Have you tried setting that process to
> priority high? (Can be dangerous in general, but in
> the interest of science ... :-)

I just tried it but it actually made things worse.

>
> Parallelization yields 1.78x speedup on the first
> version and 1.49x on the native code version. That's
> pretty good too on two cores.
>
> (I think the ultimate limit in most any language would
> be a time of about 0.33 seconds, the sys time. But at
> this point, we are actually within a factor 10 of
> that.)

Huh??
I thought that sys was the time spent in the kernel.

>
> Okay, I just thought of something marginally more
> clever when using ets. Maybe you did it this way,
> even.
>
> All the matching processes do this when they find a
> match 'M':
>
> case catch ets:update_counter(Tab, M, 1) of
>    {'EXIT', Rsn} -> match_table_owner ! {init_key, M};
>    _ -> ok
> end
>
> and the match_table_owner (which will be the sole
> process inserting new matches into the table) does
> something like
>
> receive
>   {init_key, M} ->
>     case catch ets:update_counter(Tab, M, 1) of
>        {'EXIT', _} -> ets:insert(Tab, {M, 1});
>        _ -> ok
>     end, ...;
>   ...
> end
>
> This detects and handles the race condition by
> funneling all initializations through the
> match_table_owner and making the init there
> idempotent. Furthermore, post-init updates will be
> done by each matching process without sending
> anything. Sounds potentially promising.

I have tested it but on two cores it makes no noticeable
difference, even though it sounds like a good idea.

/Anders