JasonB (no@spam.com) on 8/23/09 wrote:
---------------------------

>However a different default assumption alone doesn't buy you much if you consider
>writing correct and safe threaded code to be too difficult unless your perceptions
>are coloured by widespread and reckless use of global variables. (A no-no in our
>shop; we only have a few read-only status variables that are initialised during program startup.)

It isn't global variables in the language sense, so much
as the fact that the data structures are highly
interlinked, so if you pass a pointer into a thread
then the thread might call routines that call other
routines that follow pointers to other objects that
point to other objects that point anywhere ...

>What I did say was that it would need to be about a thousand times faster
>to compete with not having to copy it at all.

The data has to get into/through the L1 cache of the
core that runs the task, whether you program any explicit
data copying or not. And the *implicit* data movement
takes time - time that is hard to measure, but it
isn't a free lunch.

>That's also a huge burden. You've stated many times how much effort is required
>to revisit the assumptions of a large codebase stretching back 15 years while at
>the same time advocating a sweeping change like this.

It's a problem that tools can help with, a lot: the
serialize code can follow pointers, and it can tell
you where it's going and how much stuff it's moving.
And if you fail to copy some stuff you really needed
(e.g. access through global/static variable), then
the separate process will get junk and crash. Dealing
with those issues seems more tractable than dealing
with unrepeatable thread interactions. YMMV.

>Using threading I can look at a tiny part of the code, analyse it, and thread it
>safely with minimal changes. I can do this bit-by-bit over time, finding the next
>best operation to parallelise and implementing it.

That aspect is the same.

>To do it your way I would have to be in a position to predict all the ways I might
>want to slice and dice the data in future if I want to avoid having to go through
>the whole process every time I wanted to parallelise a certain operation, which
>would be tricky since different operations really want to partition the data in different ways.

Well, good algorithms need suitable data structures.
If different algorithms want to traverse the data in
different ways, that's a design issue which may need
to be addressed for serial code just as much as for
parallel code. If my approach forces its users to
think hard about the data structure for each particular
algorithm, that may have some benefits as well as costs.

>Consider the case I mentioned: the processor is accessing shared data at a rate
>of no more than a few hundred MB/sec, and each access is surrounded by quite a few

Yeah, that's all fine: if you have a detailed understanding
of all the data access patterns and algorithms, then
you're golden. But that isn't the kind of culture I'm
working in (and frankly, I think the vast majority of
programmers these days don't have a clue: a lot of ours
have no clue about relative bandwidth and latency of
disk and DRAM; some don't seem to know what a cache is,
or why it matters).

>BTW, I did forget one feature of C++ that does help with threading, and
>that's const,

I find it mostly useless myself: you pass in a pointer
to a const object, then you read some other pointer
inside the object and follow it to something else,
and modifying that second (or N'th) object is just as
harmful. I suppose you could try to write all your
classes with deep const'ness, i.e. a const method treats
all pointers to other objects as const, But that's
hard to do and perhaps not always what you want "const"
to mean.