Can people please stop misinterpreting what I wrote?

Michael Turner leap@REDACTED
Thu Sep 17 08:54:17 CEST 2009



On 9/16/2009, "Richard O'Keefe" <ok@REDACTED> wrote:

>
>On Sep 17, 2009, at 4:43 AM, Jayson Vantuyl wrote:
>> I don't really think that it's useful to classify data sharing as
>> data compression.
>
>It's very much in the spirit of dictionary-based compression.

And just so that everybody's clear: I *didn't* "classify data sharing
as data compression."  I *asked* what, exactly, in the problem that
James' code is intended to solve, couldn't be solved in classic Erlang
style with data compression?  Did I misunderstand the problem?

Oh, and just to be doubly clear: I've used shared data a lot in data
structure design, from the early 1980s onward, and in some shared-memory
multi-processor applications back as far as the late 1980s.  I'm not
religiously opposed to data structure sharing.  I actually think it can
be kind of cool, in circumstances where it's justified.  I just have a
question here, one I'd like see an answer for.  I *don't* like seeing
that question re-written into some questions I never asked, much less
into some statements I never made.

-michael turner



>>  Bottom line, there's an optimization (and a clearly important one)
>> that Erlang isn't doing.
>
>And can't reasonably be *expected* to do.  It is reasonable
>to expect Erlang to *preserve* sharing, as when sending a term
>to another process, because failing to do so can make space use
>blow up in a rather sickening way which it's hard for a
>programmer to detect.
>
>I sometimes think that for every use case there is an equal
>and opposite use case.  In the case of memory, for example,
>we've got *space* issues and *cache* issues.  Looking for
>existing copies of stuff can save you space, but it can
>do terrible things to your cache (bringing in stuff that it
>turns out you don't want).  The tradeoffs depend on how much
>space you may save, how likely the saving is, and how well you
>can avoid looking at irrelevant stuff while looking for an
>existing copy.  The programmer is in a better position to know
>these things than the Erlang compiler or runtime system.
>
>One thing I didn't quite understand was why the original data
>source is emitting stuff with lots of duplication in the first
>place.  Fixing the duplication problem at the source has the
>added benefit of reducing the cost of getting the data into an
>Erlang process to start with.
>
>
>________________________________________________________________
>erlang-questions mailing list. See http://www.erlang.org/faq.html
>erlang-questions (at) erlang.org
>
>


More information about the erlang-questions mailing list