This message originally appeared on the Phobos list, but I've grown impatient
waiting for responses and decided it needs to see a wider audience:
Now that I have time, I did some benchmarks of atomic ref counting. It is
somewhat expensive, but not obscenely so. Here's my benchmar
On Sunday 21 November 2010 17:59:35 dsimcha wrote:
> This message originally appeared on the Phobos list, but I've grown
> impatient waiting for responses and decided it needs to see a wider
> audience:
>
> Now that I have time, I did some benchmarks of atomic ref countin
On 11/21/10 7:59 PM, dsimcha wrote:
[snip]
Atomic: 258 milliseconds total (258 nanoseconds per iteration)
Non-atomic: 88 milliseconds (88 nanoseconds per iteration)
I think this is a small enough overhead that we should just make all reference
counting atomic. This would make the race condit
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s
> Thanks for taking the time to build a credibla baseline. A lot of this
> depends on the perspective. We're looking at a 2.9x slowdown after all.
Right, but this isn't a 2.9x slowdown in real world code. It's a 2.9x slowdown
in
On 11/22/10 7:27 AM, dsimcha wrote:
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s
Thanks for taking the time to build a credibla baseline. A lot of this
depends on the perspective. We're looking at a 2.9x slowdown after all.
Right, but this isn't a 2.9x slowdown in real w
the bottom line considerably. I wouldn't haste to discount a 2.9x
> factor.
> Andrei
Ok, if the destructor issue needs to be solved for the general case anyhow, then
how about making it configurable with a default of non-atomic? If you want to
share a ref counted object across thread
On 11/21/2010 8:59 PM, dsimcha wrote:
This message originally appeared on the Phobos list, but I've grown impatient
waiting for responses and decided it needs to see a wider audience:
Now that I have time, I did some benchmarks of atomic ref counting. It is
somewhat expensive, bu
On 11/23/2010 8:13 PM, Johann MacDonagh wrote:
Did you try the inline ASM block without explicit register preservation?
Walter replied to your message before
(http://www.digitalmars.com/d/archives/digitalmars/D/Register_Preservation_in_Inline_ASM_Blocks_122470.html)
and said the compiler will wor
Johann MacDonagh wrote:
Mostly OT, what was the rationale for requiring the lock prefix being a
separate statement in inline ASM? NASM and MASM keep it inline with the
statement it affects.
Simplifies the syntax considerably. rep is treated in the same way.
