Hello everyone,
gently pinging to bring this back to life given the last patch I emailed.
Best regards,
-- Nuno Diegues
On Mon, Aug 24, 2015 at 12:51 PM, Nuno Diegues wrote:
> Hello everyone,
>
> after a summer internship and some backlog catching up in the past
> weeks, I have
Hello everyone,
after a summer internship and some backlog catching up in the past
weeks, I have finally got around to review the patch according to the
latest discussion.
The changes have not caused regression, and the latest speedup results
are coherent with what we had before.
In the followi
Hello everyone,
just wanted to ping back to say that I have been overwhelmed with work
and will be back on this as soon as possible, most likely during July.
Best regards,
-- Nuno Diegues
On Tue, May 19, 2015 at 3:17 PM, Torvald Riegel wrote:
> On Mon, 2015-05-18 at 23:27 -0400, Nuno Dieg
On Mon, May 18, 2015 at 5:29 PM, Torvald Riegel wrote:
>
> First of all, sorry for taking so long to review this. Thank you for
> the contribution.
Hello Torvald,
thanks for taking the time to look into this!
> My major concern is about rdtsc being used. The relation to frequency
> adaption
Today I have received the news that the Copyright Assignment was
completed with the FSF.
On Thu, Apr 30, 2015 at 8:10 AM, Nuno Diegues wrote:
>
> > Patch looks good to me now. It would be perhaps nice to have an
> > environment variable to turn the adaptive algorithm off for
ment from the Free Software Foundation to
deal exactly with those matters for this patch to the libitm. Torvald
Riegel had advised me to do so.
I have not, however, received any further information; so I'm left
wondering if it went through or if it is still hanging. I will ping
back to FSF to chec
(1 << 0)
#define _XABORT_RETRY (1 << 1)
+#define _XABORT_CAPACITY (1 << 3)
.text
@@ -108,9 +110,12 @@ SYM(_ITM_beginTransaction):
.Ltxn_abort:
/* If it might make sense to retry the HTM fast path, let the C++
code decide. */
- testl $(_XABORT_RETRY|_XABORT_EXPLICIT), %eax
s right. But it's very nasty to change the users RNG state.
> A common pattern for repeatable benchmarks is to start with srand(1)
> and then use the random numbers to run the benchmark, so it always does
> the same thing. If you non deterministically (transaction aborts are not
> determi
Thank you for the feedback. Comments inline.
On Wed, Apr 8, 2015 at 3:05 PM, Andi Kleen wrote:
>
> Nuno Diegues writes:
>
> What workloads did you test this on?
On the STAMP suite of benchmarks for transactional memory (described here [1]).
I have ran an unmodified GCC 5.0.0
off-line sampling of the application.
The implementation in this patch follows closely the following work:
[1] "Self-Tuning Intel Transactional Synchronization Extensions", Nuno
Diegues and Paolo Romano, Proceedings of the International Conference
on Autonomic Computing, ICAC
10 matches
Mail list logo
