Is all this Invarient **** er... stuff, premature optimisation?

Me Here p9e883002 at sneakemail.com
Tue Apr 29 00:44:41 PDT 2008


Walter Bright wrote:

>There are two ways of doing it. One is COW, where those who make the 
>change make the copy. The other way doesn't have a name, but it's making a 
>copy "just in case" someone else might mutate it. I think you're proposing 
>the latter. Invariant strings is a way of enforcing COW, rather than 
>relying on documentation.
>
>There's no doubt you can make JIC work successfully. I've used it myself 
>for decades. But I always find myself expending effort trying to optimize 
>away those copies, and so find it more productive to go the other way and 
>use COW.
>
>While I am comfortable using COW with mutable strings, the many many 
>discussions of it in this forum made it clear that most would like to have 
>some compiler help with it. Invariant strings fit the bill nicely.

Okay Walter,

This will be my last word on the subject. When I posted the headpost of 
this thread, I had no idea what I was getting into.
I've since taken the time to catch up on some of the history, along with 
that of the Phobos/Tango debate. See below.

As I see it, both mechanisms are "just in case". The difference is that 
with invariants and COW, everyone who /doesn't/ need immutability has
to copy so that the one person who does need it, if they indeed exist at 
all which we have no way of knowing, doesn't have to copy.

The other way, the one person who knows they need immutability has to 
copy, and everyone else simply ignores the issue.

If you're given a reference and you need it not to change, take a copy and 
hide it away. Then it cannot.
If you're given a reference and you don't care if it changes, (or you want 
to be apprised of any changes), use it, Keep it or throw it away.

Expecting everyone else to take extra precuations, always, "just in case", 
so that you don't have to take precautions even when you know
you need to, seems the height of selfishness.

STM (from elsewhere)

>>This whole thing of invariance and concurrency seems to be aimed at
>>enabling the use of COW.

>Wouldn't that be more of a copy-swap thing? And isn't STM copy-swap at
>its core?

I'm not sure that I follow the question in context, or the meaning of 
"copy-swap".

STM is an alternative to locking for concurrency control. Essentially, 
each reader of known (marked) shared state gets a copy of the state. And 
an internal copy is made.
If that reader later attempts to write back to the shared state, it's 
current value is compared against the internal copy taken when read,
If they are disparate, the code that is attempting to write gets rolled 
back to the read point and is given the updated value (and another 
internal copy is taken)
Lather, rinse, repeat until the copy and current values are the same, then 
commit the change and continue.

Fairly expensive, and only works for code that can be rolled back (ie. 
referentially transparent code).
Useless for anything that interacts with the outside world. Eg. writes to 
the screen, or a file, or the file system,
or reads from a non-rewindable source like a port or socket or the terminal.
Efficient if you live in a referentially transparent world--all data 
exists at compile time; no interaction with the outside world.
Next to useless otherwise. You still need locking or some other mechanism 
to deal with external state.

If that describes copy-swap then yes. Else no :)

Phobos vs. Tango

I definitely don't want the dead weight of pointless OO wrappers or deeply 
nested hierarchies. Nor the "everything must be OO" philosophy.

Once I regain access to std.string for my char[]s, (and a simple, 
expectation conformant rand() function :), I'll be happy.

Till then, I'll get outta yer hair and go back to trying to process my 
140GB of data using D1.
(
Which is a shame because I really like some of the language changes for 
D2. The extension to foreach for processing files looks cool.
I'd also vote for the convergence of for/foreach if that was possible 
without moving away from a context-free grammar,
I haven't had occasion to explore the lazyness facilties yet, but they 
sound cool.
Ditto the templating.
)

Despite our difference on the issue above, please add my goodwill and 
paudits to your trophy box for your vision and provision of D.

Cheers, b.

-- 




More information about the Digitalmars-d mailing list