 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 09/09/2011 05:14 PM, Darren New wrote:
> On 9/8/2011 11:36, Orchid XP v8 wrote:
>> According to the documentation I read, this is automatic.
>
> It certainly depends on the CPU and architecture.
Well, yes, I was referring to the only architecture in existence that
people are likely to be writing desktop applications for. :-P
> You also have to make sure you're not caching something in a register
> that you've written out the pointer to.
This is certainly true. That's why C has "volatile", for example.
>>> It kind of boggles my mind too. Just the complexity of the monitoring
>>> stuff is stunning, let alone actually getting work done. :-)
>>
>> Apparently it's one of the monitoring and load-balancing systems they
>> translated to Haskell...
>
> What is?
I saw a paper a while back about how Google (I forget which center)
translated part of the monitoring system from Python to Haskell, and
documented what they did and didn't find beneficial about this.
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 9/9/2011 9:57, Orchid XP v8 wrote:
> Well, yes, I was referring to the only architecture in existence that people
> are likely to be writing desktop applications for. :-P
I think even amongst Intel and AMD x64 and x86 architectures, this varies.
I'm pretty sure it's not 100% automatic or there wouldn't be instructions
for causing it to happen.
> I saw a paper a while back about how Google (I forget which center)
> translated part of the monitoring system from Python to Haskell, and
> documented what they did and didn't find beneficial about this.
Ah. Well, there's monitoring out the wazoo here, so I'm quite certain they
didn't rewrite even a majority of it.
--
Darren New, San Diego CA, USA (PST)
How come I never get only one kudo?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 09/09/2011 07:09 PM, Darren New wrote:
> On 9/9/2011 9:57, Orchid XP v8 wrote:
>> Well, yes, I was referring to the only architecture in existence that
>> people are likely to be writing desktop applications for. :-P
>
> I think even amongst Intel and AMD x64 and x86 architectures, this
> varies.
It probably varies on things like the Atom and other embedded stuff.
> I'm pretty sure it's not 100% automatic or there wouldn't be
> instructions for causing it to happen.
There are instructions for loading stuff without caching it, in case you
happen to know that you're only going to access it once. There are
instructions for flushing the cache, if you're about to do a context
switch or you're controlling memory-mapped hardware. But as far as I
know, you don't have to do anything special to get correct
multi-processor behaviour. (Think about it; if you did, every
multi-threaded application ever written would suddenly break when run on
a multi-chip or multi-core setup.)
>> I saw a paper a while back about how Google (I forget which center)
>> translated part of the monitoring system from Python to Haskell, and
>> documented what they did and didn't find beneficial about this.
>
> Ah. Well, there's monitoring out the wazoo here, so I'm quite certain
> they didn't rewrite even a majority of it.
Oh, I'm sure they only translated one system. And it was only Google
Netherlands (or somewhere like that), not the entire company. (Although
it's surprising that different branches would actually do things
differently...)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 9/12/2011 1:13, Invisible wrote:
> (Think about it; if you did, every multi-threaded application ever written
> would suddenly break when run on a multi-chip or multi-core setup.)
Not really. You have no more likelihood of breaking because of lack of
memory barriers than you have of breaking because you've cached something in
a register during a task switch.
The compiler just has to write memory barrier instructions out when you
access a volatile variable. That's why the keyword is there.
--
Darren New, San Diego CA, USA (PST)
How come I never get only one kudo?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 12/09/2011 11:49 PM, Darren New wrote:
> On 9/12/2011 1:13, Invisible wrote:
>> (Think about it; if you did, every multi-threaded application ever
>> written
>> would suddenly break when run on a multi-chip or multi-core setup.)
>
> Not really. You have no more likelihood of breaking because of lack of
> memory barriers than you have of breaking because you've cached
> something in a register during a task switch.
>
> The compiler just has to write memory barrier instructions out when you
> access a volatile variable. That's why the keyword is there.
If you cache something in a register that you shouldn't have, your
application will break on a uniprocessor system. And you'll notice this,
and fix it.
If the hardware didn't enforce cache coherence, applications would work
perfectly on a uniprocessor and then break spectacularly on a
multiprocessor. This doesn't happen, ergo the hardware is enforcing
cache coherence.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 9/13/2011 1:31, Invisible wrote:
> If you cache something in a register that you shouldn't have, your
> application will break on a uniprocessor system. And you'll notice this, and
> fix it.
Right.
> If the hardware didn't enforce cache coherence, applications would work
> perfectly on a uniprocessor and then break spectacularly on a
> multiprocessor.
In what way would it break, given the OS inserts a memory barrier when it
switches tasks?
I.e., in what case would you expect a variable written to memory followed
immediately by a nondeterministic task switch to give you different results
on a multi vs uni processor? In what case would you expect a variable cached
in a register to give you different results during a task switch on a multi
vs uni processor?
--
Darren New, San Diego CA, USA (PST)
How come I never get only one kudo?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> If the hardware didn't enforce cache coherence, applications would work
>> perfectly on a uniprocessor and then break spectacularly on a
>> multiprocessor.
>
> In what way would it break, given the OS inserts a memory barrier when
> it switches tasks?
It's not about task switches, it's about two tasks running on different
cores trying to communicate through memory. If the cores didn't
automatically synchronise their caches, that wouldn't work at all.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 9/14/2011 1:56, Invisible wrote:
> It's not about task switches, it's about two tasks running on different
> cores trying to communicate through memory. If the cores didn't
> automatically synchronise their caches, that wouldn't work at all.
You're missing my point. If it doesn't work with two cores, it doesn't work
with one core either.
If it's automatic, why do x86 CPUs have memory fence instructions?
--
Darren New, San Diego CA, USA (PST)
How come I never get only one kudo?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 14/09/2011 05:48 PM, Darren New wrote:
> On 9/14/2011 1:56, Invisible wrote:
>> It's not about task switches, it's about two tasks running on different
>> cores trying to communicate through memory. If the cores didn't
>> automatically synchronise their caches, that wouldn't work at all.
>
> You're missing my point. If it doesn't work with two cores, it doesn't
> work with one core either.
Yes it does. Because if two tasks run on the same core, they share the
same cache. It's not possible to have two caches out of sync unless
there's actually, you know, *two caches*.
> If it's automatic, why do x86 CPUs have memory fence instructions?
I'm guessing that's for performance, not correctness.
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 9/14/2011 13:54, Orchid XP v8 wrote:
>> If it's automatic, why do x86 CPUs have memory fence instructions?
> I'm guessing that's for performance, not correctness.
http://software.intel.com/en-us/forums/showthread.php?t=65071
It appears at first google that you are correct. On second google,
http://siyobik.info/main/reference/instruction/LFENCE
I think what's happening is that I might write instructions that store
things out of order, so I store something in a memory address, then store a
pointer to that address some place you will look. On the x86 at least, the
memory fence is necessary to make sure that I have stored the data before I
have stored the pointer to it. You will always fetch the most recent pointer
I have stored, but executing "store data ; store pointer" might store the
pointer before the data without a fence. So it's not caches of main memory
but caches of instruction results that's the issue I was thinking of.
--
Darren New, San Diego CA, USA (PST)
How come I never get only one kudo?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
