From: erik quanstrom <quanstro@quanstro.net>
To: 9fans@9fans.net
Subject: Re: [9fans] waitfree
Date: Mon, 19 May 2014 22:12:37 -0400 [thread overview]
Message-ID: <1203fd06e0a13df9c23d4a5e1ac1aad0@ladd.quanstro.net> (raw)
In-Reply-To: <CAFgOgC-=2z7JknR74-4geMwm2haV52FgtVA+U9wmOU11oTwrxQ@mail.gmail.com>
> It is an ordering, but I don't think it's a valid one: your ellipses
> suggest an unbounded execution time (given the context of the
> discussion). I don't think that's valid because the protocol can't
> possibly negotiate execution for more instructions than it has space
> for in its pipeline. Furthermore, the pipeline cannot possibly be
yes it is an unbounded set of instruction. i am wondering if it isn't
possible for the same core to keep winning the MESI(F) arbitration.
i don't see tying µ-ops to cachelines. load/store buffers i believe
is where cachelines come in to play.
> filled with LOCK-prefixed instructions because it also needs to
> schedule instruction loading, and it pipelines μops, not whole
i didn't read that in the arch guide. where did you see this?
> instructions anyway. Furthermore, part of the execution cycle is
> decomposing an instruction into its μop parts. At some point, that
> processor is not going to be executing a LOCK instruction, it is going
> to be executing some other μop (like decoding the next LOCK-prefixed
> instruction it wants to execute). This won't be done with any
> synchronization. When this happens, other processors will execute
> their LOCK-prefixed instructions.
and this is an additional assumtion that i was trying to avoid. i'm
interested if LOCK XADD is wait free in a theory.
> further instructions. Instruction load and decode stages are shared,
this is not always true. and i think hints at the issue that it might be
inaccurate to generalize from your cpu to all MESI cpus.
i get a 126% difference executing lock xadd 1024*1024 times
with no branches using cores 4-7 of a xeon e3-1230. i'm sure it would
be quite a bit more impressive if it were a bit easier to turn the timer
interrupt off.
i really wish i had a four package system to play with right now. that
could yield some really fun numbers. :-)
- erik
example run. output core/cycles.
; 6.lxac
4 152880511
7 288660939
6 320991900
5 338755451
next prev parent reply other threads:[~2014-05-20 2:12 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-19 17:34 erik quanstrom
2014-05-19 19:49 ` Devon H. O'Dell
2014-05-19 20:21 ` erik quanstrom
2014-05-19 21:01 ` Devon H. O'Dell
2014-05-19 22:05 ` erik quanstrom
2014-05-19 22:14 ` ron minnich
2014-05-19 22:18 ` erik quanstrom
2014-05-20 1:10 ` Devon H. O'Dell
2014-05-20 2:12 ` erik quanstrom [this message]
2014-05-20 14:47 ` Devon H. O'Dell
2014-05-20 15:41 ` erik quanstrom
2014-05-20 19:14 ` Devon H. O'Dell
2014-05-20 19:30 ` erik quanstrom
2014-05-20 20:32 ` Devon H. O'Dell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1203fd06e0a13df9c23d4a5e1ac1aad0@ladd.quanstro.net \
--to=quanstro@quanstro.net \
--cc=9fans@9fans.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).