Re: [9fans] GCC/G++: some stress testing

[Philippe Anel <xigh@free.fr>]

Please note I'm not an expert in this domain. I am only interested in
this area, and have only read a few papers.
It is interesting to talk with you about this 'real world' problems.
> Latency is quite important in the application domain I have to target:
> the target is to produce a new image every 60th of a second, including
> all the simulation effort to get there.  In addition, we have user
> input which needs to be processed, and usually network delays to worry
> about as well.  Every bit of latency between user input and display
> breaks the illusion of control.  And though TVs are getting better,
> it's not atypical to see 4-6 frames of latency introduced by the
> display subsystem, once you've finished generating a frame buffer.
So, does this mean the latency is only required by the I/O system of
your program ? If so, maybe I'm wrong, what you need is to be able to
interrupt working cores and I'm afraid libthread doesn't help here.
If not and your algorithm requires (a lot of) fast IPC, maybe this is
the reason why it doesn't scale well ?
>
> I don't know what you mean by "CSP system itself takes care about
> memory hierarchy".  Do you mean that the CSP implementation does
> something about it, or do you mean that the code using the CSP
> approach takes care of it?
Both :)
I agree with you about the fact programming for the memory hierarchy is
way more important than optimizing CPU clocks.
But I also think synchronization primitives used in CSP systems are the
main reason why CSP programs do not scale well (excepted bad designed
algorithm of course).
I meant that a different CSP implementation, based on different
synchronisation primitive (IPI), can help here.
>
> IPI isn't free either - apart from the OS switch, it generates bus
> traffic that competes with the cache coherence protocols and memory
> traffic; in a well designed compute kernel that saturates both compute
> and bandwidth the latency hiccups so introduced can propagate really
> badly.
>
This is very interesting. For sure IPI is not free. But I thought the
bus traffic generated by IPI was less important than cache coherence
protocols such as MESI, mainly because it is a one way message.
I think now IPI are sent through the system bus (local APIC used to talk
through a separate bus), so I agree with you about the fact it can
saturate the bandwidth. But I wonder if locking primitive are not worse.
It would be interesting to test this.

Phil;