http://groups.google.com/group/comp.programming.threads?hl=en
comp.programming.threads@googlegroups.com
Today's topics:
* AIR Jordan Fusions 13 NIKE Jordan Fusion 14 AIR Jordans 15Nike Jordan - 1
messages, 1 author
http://groups.google.com/group/comp.programming.threads/t/6e687443d2cf526d?hl=en
* Why are Boost thread mutexes so slow compared to Pthreads? - 5 messages, 3
authors
http://groups.google.com/group/comp.programming.threads/t/9c9fd9b9ccafc16a?hl=en
* Core i7 CMPXCHG-performance - 3 messages, 2 authors
http://groups.google.com/group/comp.programming.threads/t/14d357b5d0c9bfb9?hl=en
==============================================================================
TOPIC: AIR Jordan Fusions 13 NIKE Jordan Fusion 14 AIR Jordans 15Nike Jordan
http://groups.google.com/group/comp.programming.threads/t/6e687443d2cf526d?hl=en
==============================================================================
== 1 of 1 ==
Date: Thurs, Jan 1 2009 11:41 pm
From: wholesaleg@126.com
shoes on
AIR Jordan 1 (paypal payment)(www.king-trade.cn )
AIR Jordan 2
AIR Jordan 3
AIR Jordan 4
AIR Jordan 5 (paypal payment)(www.king-trade.cn )
AIR Jordan 6 Rings
AIR Jordan 6
AIR Jordan 7
AIR Jordan 8
AIR Jordan 9 (paypal payment)(www.king-trade.cn )
AIR Jordan 10
AIR Jordan 11
AIR Jordan 12
AIR Jordan 13 (paypal payment)(www.king-trade.cn )
AIR Jordan 14
AIR Jordan 15
AIR Jordan 16
AIR Jordan 17
AIR Jordan 18
AIR Jordan 19
AIR Jordan 20 (paypal payment)(www.king-trade.cn )
AIR Jordan 21
AIR Jordan 22
AIR Jordan 23 (paypal payment)(www.king-trade.cn )
AIR Jordan 3.5
AIR AIR Jordan 4.5
AIR Jordan 7.5
AIR Jordan 9.5
AIR Jordan 12.5 (paypal payment)(www.king-trade.cn )
AIR Jordan 15.5
AIR Jordan 19.5
AIR Jordan 21.5
AIR Jordan Large Size Jordan
AIR Jordan Size 14 Jordan
AIR Jordan Size 15 shoes
AIR Jordan DMP
Nike air force one, air force 1, air force one low cut, air force one
high cut, air force one release date
Air force one, air foce one 25TH, af 1, af 1 25TH, Nike air force one
new releases, limited version
Air Force One (paypal payment)(www.king-trade.cn )
Air Force one 25TH
AF 1
AF 1 25TH (paypal payment)(www.king-trade.cn )
Dunk sb nike sb dunk nike dunk sb dunk sb high dunk sb low dunk sb
woman
Nike sb dunk Nike Dunk High SB nike dunk low premuim sb Nike SB Dunk
High Shimizu
Nike SB Dunk Pro Nike SB Dunk Dunk SB
Nike Dunk shoes
Dunk shoes for woman (paypal payment)(www.king-trade.cn )
Dunk low cut
Dunk high cut
AIR Jordans Fusion 1 Jordan 2 Fusion AIR Jordan 3 Nike Jordan Fusion
4
Jordan 5 shoes Nike Air Jordan 6 VI Force 1 Jordan Fusion AJF 6 AJF6
AJ6F Jordan 6 Rings Jordan 6 fusion (paypal payment)(www.king-
trade.cn )
AIR Jordan Fusions 13 NIKE Jordan Fusion 14 AIR Jordans 15Nike Jordan
16 Fusion Jordan 17 shoes Nike Air Jordans 18 XVIII Force 1 Jordan
Fusion AJF18 AJF18 AJ18F Jordan 18 fusions
(paypal payment)(www.king-trade.cn )
AIR Jordan Fusions 7 NIKE Jordan Fusion 8 AIR Jordans 9 Nikes Jordan
Fusion 10 Jordan 11 shoes Nike Air Jordan 12 XII Force 1 Jordan
Fusion AJF 12 AJF12 AJ12F Jordans 12 fusions
(paypal payment)(www.king-trade.cn )
NIKE AIR JORDAN FORCE FUSION SHOES AJF 5 V JORDANs 5 FUSION NIKE
JORDAN 5 FUSION SHOES AJF5 Nike Air Jordan XXIII 23 Force 1 Jordan
Fusion AJF 23 AJF23 AJ23F
(paypal payment)(www.king-trade.cn )
Nike Jordans Fusion 23 AIR Jordan 22 Jordan Fusions 21 AIR Jordans
Fusion 20 Jordan 19 shoes Air Jordan Force Fusion VIII (8), AJF 8
Nike (paypal payment)(www.king-trade.cn )
Air Jordan 17 XVII Force 1 Jordan Fusions AJF 17 AJF17 AJ17F Jordan
our website : www.king-trade.cn
==============================================================================
TOPIC: Why are Boost thread mutexes so slow compared to Pthreads?
http://groups.google.com/group/comp.programming.threads/t/9c9fd9b9ccafc16a?hl=en
==============================================================================
== 1 of 5 ==
Date: Fri, Jan 2 2009 3:53 am
From: Daniel James
In article news:<lD97l.30342$J84.375@tornado.fastwebnet.it>, Giancarlo
Niccolai wrote:
> > I disagree with your suggestion that automating a process cannot
> > make that process easier and safer than doing it manually.
>
> It CAN make it. It is not... automatic that it will make it.
Then I don't think we're fundamentally in disagreement, but the tone of
some of your posts does seem to imply that you are more strongly
against automation than your statements here suggest.
> And in fact, I have never been against. I was against only in
> advertising automation as always better. One must know its tools, or,
> automation or not, they will shoot back.
Agreed, though I would say that using automatic code is always better
than manually writing a chunk of code that is semantically identical to
the automatic version.
That is: if the automatic code does what you want then it is always
better to use the automatic version than to write a large block of code
that does the same thing.
If what you want is not what the automatic code does then -- of course
-- you will have to write a block of code that exactly expresses your
intent. In practice I have seldom, if ever, needed to do this.
Cheers,
Daniel.
== 2 of 5 ==
Date: Fri, Jan 2 2009 3:53 am
From: Daniel James
In article news:<bJg7l.65096$ly1.6354@newsfe19.iad>, Chris M. Thomasson
wrote:
> It works fine, but its not quite as "flexible"; IMVHO of course.
> How can you use separate scoped locks in the following contrived
> pseudo-code:
You can't do /exactly/ that without scoped unlock, but I'd suggest
(IMHO, of course) that it's possible to produce an equivalent design
using only scoped locks.
The following is NOT such a design (the lock is released between the
call to do_locked_stuff in foo1 and that to do_some_more_locked_stuff
in foo2) but is clearer and in most cases will suffice.
static mutex g_mutex; // non-recursive!
// `foo_2' RULE 1: `Must' be called with `g_mutex' UNlocked!
void foo_2();
void foo_1() {
{
scoped_lock lock(g_mutex);
do_locked_stuff();
}
foo_2();
{
scoped_lock lock(g_mutex);
do_more_locked_stuff();
}
}
// `foo_2' RULE 1: `Must' be called with `g_mutex' UNlocked!
void foo_2() {
{
scoped_lock lock(g_mutex);
do_some_more_locked_stuff();
}
do_unlocked_stuff();
}
Obviously, this won't do if do_locked_stuff breaks some invariant and
relies on do_some_more_locked_stuff to restore it, but (unless these
operations are trivial, in which case I don't see the point of writing
foo2 as a separate function anyway) I'd say that was a questionable
design in any case ...
Then again, you did say that yours was a contrived example, I would say
that in practice it doesn't matter as people generally won't need to
write code like that.
Cheers,
Daniel.
== 3 of 5 ==
Date: Fri, Jan 2 2009 3:53 am
From: Daniel James
In article
news:<66bde35d-c6b4-4864-b342-8e07bb98110b@u18g2000pro.googlegroups.com>
, David Schwartz wrote:
> Right, at the time of construction. The problem is three months
> later, when you seed to add some new code in the middle of that
> scope, or at the end of that scope, that cannot run with the lock.
So you need to do a little refactoring if/when you need to change the
code ... I can't accept that as a serious objection.
You're saying that one might want to change:
{
scoped_lock locker(m)
do_thing_1
do_thing_2
}
into:
{
scoped_lock locker(m)
do_thing_1
}
do_extra_thing
{
scoped_lock another_locker(m)
do_thing_2
}
Is that really such a big change? You're just adding four (non-blank)
lines:
}
do_extra_thing
{
scoped_lock another_locker(m)
and the code remains completely self-documenting.
> But it doesn't afford any safety. If you forget to restore
> invariants, it releases the mutex automatically. How is that safe?
If you forget to restore invariants your code is screwed anyway. No
amount of clever locking code will save you.
Assuming you have your own application logic correct, the scoped lock is
a safe coding technique because it concisely and reliably handles locks
without your having to write a lot of explicit and error-prone code.
> If a scoped lock actually helps you avoid forgetting to unlock the
> mutex, it's because your code is so complicated that it's not visually
> obvious every place the mutex gets released.
On the contrary, using a scoped lock saves you from having to write a
lot of explicit lock-handling code that would make your code
complicated. The scoped lock is safe because its use is concise.
You repeatedly fail to get this point, no matter how many times it is
pointed out.
> This means your code is *unsafe*, since you cannot possibly
> be sure it restores invariants every place it needs to.
We're talking about managing locks, here, not managing invariants. The
two issues are orthogonal.
Cheers,
Daniel.
== 4 of 5 ==
Date: Fri, Jan 2 2009 4:13 am
From: "Chris M. Thomasson"
"Daniel James" <wastebasket@nospam.aaisp.org> wrote in message
news:VA.0000161c.16eb1a64@nospam.aaisp.org...
> In article news:<bJg7l.65096$ly1.6354@newsfe19.iad>, Chris M. Thomasson
> wrote:
>> It works fine, but its not quite as "flexible"; IMVHO of course.
>> How can you use separate scoped locks in the following contrived
>> pseudo-code:
>
> You can't do /exactly/ that without scoped unlock,
I also wrote that `foo_2' "needs" its call to `do_some_more_locked_stuff' to
be within any calling threads active critical-section based on `g_mutex'. I
have worked with functions that assume all calling threads already hold
specific mutexs...
How do you to that with _only_ scoped-lock RAII helper objects?
> but I'd suggest
> (IMHO, of course) that it's possible to produce an equivalent design
> using only scoped locks.
>
> [...]
How would a function/procedure called within a locked scope, subsequently
unlock the mutex?
== 5 of 5 ==
Date: Fri, Jan 2 2009 7:51 am
From: Giancarlo Niccolai
Daniel James ha scritto:
> In article news:<lD97l.30342$J84.375@tornado.fastwebnet.it>, Giancarlo
>
> If what you want is not what the automatic code does then -- of course
> -- you will have to write a block of code that exactly expresses your
> intent. In practice I have seldom, if ever, needed to do this.
>
And in practice, I have seldom, if ever, needed automatisms :-). Yet I
use them when they are useful in my job (say 5%). But this has nothing
to do with personal bias or usefulness of the tool; just, my usual work
requires a quite granular control of MT constructs. Were my job
different, I'd be using them much more.
Gian.
==============================================================================
TOPIC: Core i7 CMPXCHG-performance
http://groups.google.com/group/comp.programming.threads/t/14d357b5d0c9bfb9?hl=en
==============================================================================
== 1 of 3 ==
Date: Fri, Jan 2 2009 8:49 am
From: rani_sharoni@hotmail.com
On Dec 29 2008, 3:12 pm, David Schwartz <dav...@webmaster.com> wrote:
> On Dec 29, 1:42 pm, Elcaro Nosille <ElcaroNosi...@akapost.com> wrote:
>
> > David Schwartz schrieb:
> > > You won't get official throughput/latency numbers from Intel anymore
> > > because there are so many possibly cases. However, I have heard from
> > > Intel sources that LOCK CMPXCHG will be 40% less expensive (in terms
> > > of clock cycles) on Core i7 than it is on Core 2. The same source that
> > > LOCK CMPXCHG is 65% less expensive on Core 2 than it is on late-model
> > > P4s.
> > I've written a little program that repeatedly does LOCK CMPXCHG of
> > the same value (zero exchanged by zero). On a Core i7 of a friend,
> > each LOCK CMPXCHG takes about 22 cycles; on my QX6850 (3GHz, 65nm
> > Quadcore) it takes about 25 cycles. Not a big difference.
>
> That's about 12%, which is a far cry from the claimed 40%.
>
> However, testing in a tight loop is not always fair. For one thing,
> you're probably only testing the case where the cache line is already
> in the L1 cache. That may or may not be the case you care most about.
> For another thing, you may not be testing the effect of the locked
> instruction on the pipeline status.
>
> It's also possible that your test is accurate.
>
> DS
I heard, mainly from the STM camp, that the biggest problem with these
CPU locked operations is that they poorly scale for many cores due to
memory synchronization (and not CPU performance). Maybe Intel improved
this issue and therefore there is potential for big gain in high
contention scenarios.
Rani
== 2 of 3 ==
Date: Fri, Jan 2 2009 8:11 pm
From: David Schwartz
On Jan 2, 8:49 am, rani_shar...@hotmail.com wrote:
> I heard, mainly from the STM camp, that the biggest problem with these
> CPU locked operations is that they poorly scale for many cores due to
> memory synchronization (and not CPU performance). Maybe Intel improved
> this issue and therefore there is potential for big gain in high
> contention scenarios.
Ultimately, I think the solution is just not to have high contention.
The idea is to have the tasks done by your cores be as logically-
independent as possible. Focus on reducing the amount of contention
rather than by making the contention do less harm.
This is largely the reason I have argued that lock-free approaches are
largely movements in the wrong direction. Use locks intelligently --
so that threads that contend with each other will not run concurrently
unless there is no other way to keep a core busy.
DS
== 3 of 3 ==
Date: Fri, Jan 2 2009 8:59 pm
From: rani_sharoni@hotmail.com
On Jan 2, 8:11 pm, David Schwartz <dav...@webmaster.com> wrote:
> On Jan 2, 8:49 am, rani_shar...@hotmail.com wrote:
>
> > I heard, mainly from the STM camp, that the biggest problem with these
> > CPU locked operations is that they poorly scale for many cores due to
> > memory synchronization (and not CPU performance). Maybe Intel improved
> > this issue and therefore there is potential for big gain in high
> > contention scenarios.
>
> Ultimately, I think the solution is just not to have high contention.
> The idea is to have the tasks done by your cores be as logically-
> independent as possible. Focus on reducing the amount of contention
> rather than by making the contention do less harm.
>
> This is largely the reason I have argued that lock-free approaches are
> largely movements in the wrong direction. Use locks intelligently --
> so that threads that contend with each other will not run concurrently
> unless there is no other way to keep a core busy.
>
> DS
I think that one of the challenges of hardware vendors is to
transparently improve the current state of things for which better
scalability of such atomic operations is more than welcomed (e.g. even
making state of the art lock-free algorithms freer).
Rani
==============================================================================
You received this message because you are subscribed to the Google Groups "comp.programming.threads"
group.
To post to this group, visit http://groups.google.com/group/comp.programming.threads?hl=en
To unsubscribe from this group, send email to comp.programming.threads+unsubscribe@googlegroups.com
To change the way you get mail from this group, visit:
http://groups.google.com/group/comp.programming.threads/subscribe?hl=en
To report abuse, send email explaining the problem to abuse@googlegroups.com
==============================================================================
Google Groups: http://groups.google.com/?hl=en
No comments:
Post a Comment