There was a nice blog-post about implementing low-lock singletons in D, here:
http://davesdprogramming.wordpress.com/2013/05/06/low-lock-singletons/
One suggestion on Reddit was by dawgfoto (I think this is Martin
Nowak?), to use atomic primitives instead:
http://www.reddit.com/r/programming/comme
You forgot to make the flag static for AtomicSingleton. I'd also
move the timing into the threads themselves, for fairness :)
http://codepad.org/gvm3A88k
Timings on my machine:
ldc2 -unittest -release -O3:
Test time for LockSingleton: 537 msecs.
Test time for SyncSingleton: 2 msecs.
Test time
31-Jan-2014 12:25, Andrej Mitrovic пишет:
There was a nice blog-post about implementing low-lock singletons in D, here:
http://davesdprogramming.wordpress.com/2013/05/06/low-lock-singletons/
One suggestion on Reddit was by dawgfoto (I think this is Martin
Nowak?), to use atomic primitives instea
I was thinking about implementing a typical Java singleton in D,
and then decided to first check whether someone already did that,
and guess what - yes, someone did. Chech this URL:
http://dblog.aldacron.net/2007/03/03/singletons-in-d/
Something like this (taken from the article above) in the
On Friday, 31 January 2014 at 10:26:50 UTC, Dejan Lekic wrote:
I should have mentioned two things in my previous post.
1) There are no locks involved. No need, because the solution
relies on the fact that static member variables are guaranteed
to be created the first time they are accessed.
On Friday, 31 January 2014 at 10:20:45 UTC, Dejan Lekic wrote:
I was thinking about implementing a typical Java singleton in
D, and then decided to first check whether someone already did
that, and guess what - yes, someone did. Chech this URL:
http://dblog.aldacron.net/2007/03/03/singletons-in
I should have mentioned two things in my previous post.
1) There are no locks involved. No need, because the solution
relies on the fact that static member variables are guaranteed to
be created the first time they are accessed.
2) Note that we have constructor disabled. This is important not
On 1/31/14, Stanislav Blinov wrote:
> You forgot to make the flag static for AtomicSingleton.
Ah. It was copied verbatim from reddit, I guess we both missed it.
> Timings on my machine:
>
> ldc2 -unittest -release -O3:
>
> Test time for LockSingleton: 537 msecs.
> Test time for SyncSingleton: 2
On 1/31/14, Dmitry Olshansky wrote:
> Also keep in mind that atomic
> ops are _relatively_ cheap on x86 the stuff should get even better on
> say ARM.
Hmm yeah, but I was expecting better numbers. Even after the 'static'
fix in the bug as noted by Stanislav the atomic version is slower.
On Friday, 31 January 2014 at 10:39:19 UTC, Andrej Mitrovic wrote:
On 1/31/14, Stanislav Blinov wrote:
You forgot to make the flag static for AtomicSingleton.
Ah. It was copied verbatim from reddit, I guess we both missed
it.
Yeah, with D's verbosity in this cases it's easy to miss.
Here
On Friday, 31 January 2014 at 10:27:28 UTC, Namespace wrote:
Why is someone interested in implementing such an Ani Pattern
like Singletons?
Why is someone overquoting without reason? ;)
In most of all cases Singletons are misused.
Any sort of shared (as in, between threads) resource is oft
On 1/31/14, Andrej Mitrovic wrote:
> Hmm yeah, but I was expecting better numbers. Even after the 'static'
> fix in the bug as noted by Stanislav the atomic version is slower.
Actually, I think I understand why this happens. Logically, the atomic
version will do an atomic read for *every* access,
On Friday, 31 January 2014 at 10:50:57 UTC, Stanislav Blinov
wrote:
On Friday, 31 January 2014 at 10:27:28 UTC, Namespace wrote:
Why is someone interested in implementing such an Ani Pattern
like Singletons?
Why is someone overquoting without reason? ;)
I know so many people and have read s
What use would the const version have? You'd still need some
way to access the instance, right? Cast away const?
I believe it should have been "final" instead of "const".
On Friday, 31 January 2014 at 10:57:53 UTC, Andrej Mitrovic wrote:
The atomic implementation probably beats the TLS version when a
lot of
new threads are being spawned at once and they only retrieve the
singleton which has already been initialized. E.g., say a 1000
threads
are spawned.
Easy
On 1/31/14, Stanislav Blinov wrote:
> First, subsequent runs on my machine show interleaving results.
> It also seems that either there *is* a race in there somewhere,
> or maybe a bug?.. Some runs just flat freeze (even on small
> thread counts) :\
Hmm.. Well I know we've had some issues with th
On Friday, 31 January 2014 at 11:08:42 UTC, Dejan Lekic wrote:
I believe it should have been "final" instead of "const".
But D doesn't have "final" :) In any event, that article by Mike
Parker is about D1.
On 1/31/14, Stanislav Blinov wrote:
> On Friday, 31 January 2014 at 11:08:42 UTC, Dejan Lekic wrote:
>
>> I believe it should have been "final" instead of "const".
>
> But D doesn't have "final" :) In any event, that article by Mike
> Parker is about D1.
>
AFAIK D1's final was equivalent to D2's
Here is an updated Andrej's code:
http://dpaste.dzfl.pl/c85f487c7f70
SingletonSimple is a winner, followed by the SyncSingleton and
SingletonLazy.
Am 31.01.2014 10:18, schrieb Stanislav Blinov:
You forgot to make the flag static for AtomicSingleton. I'd also move
the timing into the threads themselves, for fairness :)
http://codepad.org/gvm3A88k
Timings on my machine:
ldc2 -unittest -release -O3:
Test time for LockSingleton: 537 msecs.
On 1/31/14, Dejan Lekic wrote:
> SingletonSimple is a winner
Well yeah, but that's not really the only thing what a singleton is
about. It's also about being able to initialize the singleton at an
arbitrary time, rather than in a module constructor before main() is
called.
On 1/31/14, Benjamin Thaut wrote:
> For x86 CPUs you don't really need MemoryOrder.acq as reads are atomic
> by default.
Hmm, I guess we could use a version(X86) block to pick this. When you
say x86, do you also imply X86_64? Where can I read about the memory
reads being atomic by default?
On Friday, 31 January 2014 at 11:18:03 UTC, Andrej Mitrovic wrote:
On 1/31/14, Stanislav Blinov wrote:
First, subsequent runs on my machine show interleaving results.
It also seems that either there *is* a race in there somewhere,
or maybe a bug?.. Some runs just flat freeze (even on small
thre
On Friday, 31 January 2014 at 11:34:13 UTC, Dejan Lekic wrote:
SingletonSimple is a winner, followed by the SyncSingleton and
SingletonLazy.
Dejan, your singletons are thread-local :)
On Friday, 31 January 2014 at 11:42:29 UTC, Andrej Mitrovic wrote:
On 1/31/14, Dejan Lekic wrote:
SingletonSimple is a winner
Well yeah, but that's not really the only thing what a
singleton is
about. It's also about being able to initialize the singleton
at an
arbitrary time, rather than i
On 1/31/14, Dejan Lekic wrote:
> SingletonLazy.
SingletonLazy isn't thread-safe. :)
On 2014-01-31 12:27, Andrej Mitrovic wrote:
AFAIK D1's final was equivalent to D2's immutable. But I maybe
remembering that wrong.
In D2 if if a variable is immutable or const you can not call non-const
non-immutable methods via that variable. D1 didn't have any concept of
this. "const" and
On Friday, 31 January 2014 at 11:44:10 UTC, Stanislav Blinov
wrote:
On Friday, 31 January 2014 at 11:34:13 UTC, Dejan Lekic wrote:
SingletonSimple is a winner, followed by the SyncSingleton and
SingletonLazy.
Dejan, your singletons are thread-local :)
YAY, that is correct! :'(
But D doesn't have "final" :) In any event, that article by
Mike Parker is about D1.
Well, "final" still works. Until it does not we will agree that D
does not have it. ;) That article applies to D2 as well, without
any problems.
SingletonLazy isn't thread-safe. :)
EEK!
On 1/31/14, Jacob Carlborg wrote:
> In D2 if if a variable is immutable or const you can not call non-const
> non-immutable methods via that variable. D1 didn't have any concept of
> this. "const" and "final" in D1 as more, you cannot change this variable.
So in D1 const is non-transitive?
On Friday, 31 January 2014 at 11:45:56 UTC, Andrej Mitrovic wrote:
On 1/31/14, Dejan Lekic wrote:
SingletonLazy.
SingletonLazy isn't thread-safe. :)
I made it thread-safe, and guess what - I ended up with
SyncSingleton-like solution! So SyncSingleton is a clean winner
if you want to make
On Friday, 31 January 2014 at 12:09:49 UTC, Andrej Mitrovic wrote:
On 1/31/14, Jacob Carlborg wrote:
In D2 if if a variable is immutable or const you can not call
non-const
non-immutable methods via that variable. D1 didn't have any
concept of
this. "const" and "final" in D1 as more, you canno
On Friday, 31 January 2014 at 11:31:53 UTC, Benjamin Thaut wrote:
For x86 CPUs you don't really need MemoryOrder.acq as reads are
atomic by default.
Uhm... atomicLoad() itself guarantees that the read is atomic.
It's not about atomicity of operation, it's about sequential
consistency. Using
In fact #2, I think it's even safe to pull that store out of the
synchronized block:
// (2)
if (!atomicLoad!(MemoryOrder.raw)(_instantiated))
{
// (1)
synchronized
{ // <- this is 'acquire'
if (_instance is null) {
Am 31.01.2014 12:44, schrieb Andrej Mitrovic:
On 1/31/14, Benjamin Thaut wrote:
For x86 CPUs you don't really need MemoryOrder.acq as reads are atomic
by default.
Hmm, I guess we could use a version(X86) block to pick this. When you
say x86, do you also imply X86_64? Where can I read about th
If you need the details, read:
http://lwn.net/Articles/250967/
Kind Regards
Benjamin Thaut
Is it just me or does the implementation of atomic.d look grossly
inefficient and badly in need of a rewrite?
On 1/31/14, Benjamin Thaut wrote:
> If you need the details, read:
>
> http://lwn.net/Articles/250967/
Aye it's been on my todo list forever, even though I've read the first
part when it was a single blost post, afair.
Am 31.01.2014 15:27, schrieb Jonathan Bettencourt:
Is it just me or does the implementation of atomic.d look grossly
inefficient and badly in need of a rewrite?
I can't really judge that, as I don't have much experience in lock free
programming. But if someone is to rewrite this module, then i
Am 31.01.2014 15:30, schrieb Andrej Mitrovic:
On 1/31/14, Benjamin Thaut wrote:
If you need the details, read:
http://lwn.net/Articles/250967/
Aye it's been on my todo list forever, even though I've read the first
part when it was a single blost post, afair.
You should really take the tim
31-Jan-2014 17:26, Stanislav Blinov пишет:
In fact #2, I think it's even safe to pull that store out of the
synchronized block:
// (2)
if (!atomicLoad!(MemoryOrder.raw)(_instantiated))
{
// (1)
synchronized
{ // <- this is 'acquir
On 1/31/14, 3:42 AM, Andrej Mitrovic wrote:
On 1/31/14, Dejan Lekic wrote:
SingletonSimple is a winner
Well yeah, but that's not really the only thing what a singleton is
about. It's also about being able to initialize the singleton at an
arbitrary time, rather than in a module constructor be
On Friday, 31 January 2014 at 17:10:08 UTC, Andrei Alexandrescu
wrote:
On 1/31/14, 3:42 AM, Andrej Mitrovic wrote:
On 1/31/14, Dejan Lekic wrote:
SingletonSimple is a winner
Well yeah, but that's not really the only thing what a
singleton is
about. It's also about being able to initialize t
On Friday, 31 January 2014 at 15:18:43 UTC, Dmitry Olshansky
wrote:
31-Jan-2014 17:26, Stanislav Blinov пишет:
In fact #2, I think it's even safe to pull that store out of
the
synchronized block:
// (2)
if (!atomicLoad!(MemoryOrder.raw)(_instantiated))
{
//
On Friday, 31 January 2014 at 23:35:25 UTC, Stanislav Blinov
wrote:
// (2)
if (!atomicLoad!(MemoryOrder.raw)(_instantiated))
{
// (1)
synchronized
{ // <- this is 'acquire'
if (_instance is null) {
//(3)
_
01-Feb-2014 18:23, Stanislav Blinov пишет:
On Friday, 31 January 2014 at 23:35:25 UTC, Stanislav Blinov wrote:
// (2)
if (!atomicLoad!(MemoryOrder.raw)(_instantiated))
{
// (1)
synchronized
{ // <- this is 'acquire'
if (_insta
On 1/31/14, Stanislav Blinov wrote:
> I've reworked the unittest a little, to accomodate for multiple
> runs:
>
> http://codepad.org/ghZdjvUE
I've finally managed to build LDC2 on Windows (MinGW version), here
are the timings between DMD and LDC2:
$ dmd -release -inline -O -noboundscheck -unitte
On Tuesday, 4 February 2014 at 09:44:04 UTC, Andrej Mitrovic
wrote:
I've finally managed to build LDC2 on Windows (MinGW version),
here
are the timings between DMD and LDC2:
$ dmd -release -inline -O -noboundscheck -unittest singleton_2.d
-oftest.exe && test.exe
Test time for LockSingleton:
On 2/4/14, Andrej Mitrovic wrote:
> I haven't figured out exactly what you're trying to swap there. Do you
> have a full example:
s/:/?
On 2/4/14, Stanislav Blinov wrote:
> Have you also included fixes from
> http://forum.dlang.org/post/khidcgetalmguhass...@forum.dlang.org ?
I haven't figured out exactly what you're trying to swap there. Do you
have a full example:
> How do the test results look in multiple runs? Is AtomicSingle
On Tuesday, 4 February 2014 at 14:23:51 UTC, Andrej Mitrovic
wrote:
On 2/4/14, Stanislav Blinov wrote:
Have you also included fixes from
http://forum.dlang.org/post/khidcgetalmguhass...@forum.dlang.org
?
I haven't figured out exactly what you're trying to swap there.
Do you
have a full exa
"Stanislav Blinov" writes:
> On Tuesday, 4 February 2014 at 09:44:04 UTC, Andrej Mitrovic wrote:
>
>> I've finally managed to build LDC2 on Windows (MinGW version), here
>> are the timings between DMD and LDC2:
>>
>> $ dmd -release -inline -O -noboundscheck -unittest singleton_2.d
>> -oftest.exe
On 2/4/14, Stanislav Blinov wrote:
> Both atomicLoad and atomicStore use raw MemoryOrder, and also the
> atomicStore is out of the synchronized {} section:
>
> http://dpaste.dzfl.pl/291abc51bb0e
No difference, but maybe the timing precision isn't proper. It always
displays one of 3/3.25/4 msecs.
On Wednesday, 5 February 2014 at 00:11:58 UTC, Jerry wrote:
Here's the best and worst times I get on my linux laptop.
These are
with 2.064.2 dmd and gdc 4.9 with 2.064.2
On Ubuntu x86_64:
~/dmd2/linux/bin64/dmd -O -release -inline -noboundscheck
-unittest singleton.d
Test 2 time for SyncS
On Wednesday, 5 February 2014 at 08:39:08 UTC, Andrej Mitrovic
wrote:
No difference, but maybe the timing precision isn't proper. It
always displays one of 3/3.25/4 msecs.
Hmm... It should be as proper as it gets, judging from
StopWatch's docs.
Anywho what's important is that Atomic is rea
On Wednesday, 5 February 2014 at 09:30:51 UTC, Stanislav Blinov
wrote:
On Wednesday, 5 February 2014 at 08:39:08 UTC, Andrej Mitrovic
wrote:
No difference, but maybe the timing precision isn't proper. It
always displays one of 3/3.25/4 msecs.
Hmm... It should be as proper as it gets, judging
"Stanislav Blinov" writes:
> On Wednesday, 5 February 2014 at 00:11:58 UTC, Jerry wrote:
>
>> Here's the best and worst times I get on my linux laptop. These are
>> with 2.064.2 dmd and gdc 4.9 with 2.064.2
>>
>> On Ubuntu x86_64:
>>
>> ~/dmd2/linux/bin64/dmd -O -release -inline -noboundscheck -
On Wednesday, 5 February 2014 at 21:47:40 UTC, Jerry wrote:
I downloaded the test program yesterday.
Here's my latest revision: http://dpaste.dzfl.pl/5b54df1c7004
Andrej, I hope you don't mind me fiddling with that code? I've
put that atomic fix in there, also switched timing to use hnsecs
"Stanislav Blinov" writes:
> On Wednesday, 5 February 2014 at 21:47:40 UTC, Jerry wrote:
>
>> I downloaded the test program yesterday.
>
> Here's my latest revision: http://dpaste.dzfl.pl/5b54df1c7004
>
> Andrej, I hope you don't mind me fiddling with that code? I've put that atomic
> fix in ther
Weird. atomicLoad(raw) should be the same as atomicLoad(acq),
and atomicStore(raw) should be the same as atomicStore(rel). At
least on x86. I don't know why that change made a difference in
performance.
On Friday, 31 January 2014 at 08:25:16 UTC, Andrej Mitrovic wrote:
class LockSingleton
{
static LockSingleton get()
{
__gshared LockSingleton _instance;
synchronized
{
if (_instance is null)
_instance = new LockSingleton;
}
On 7 February 2014 10:25, TC wrote:
> On Friday, 31 January 2014 at 08:25:16 UTC, Andrej Mitrovic wrote:
>>
>> class LockSingleton
>> {
>> static LockSingleton get()
>> {
>> __gshared LockSingleton _instance;
>>
>> synchronized
>> {
>> if (_instance is n
On Friday, 7 February 2014 at 08:10:58 UTC, Sean Kelly wrote:
Weird. atomicLoad(raw) should be the same as atomicLoad(acq),
and atomicStore(raw) should be the same as atomicStore(rel).
At least on x86. I don't know why that change made a
difference in performance.
huh?
--8<-- core/atomic.
On Friday, 7 February 2014 at 04:06:40 UTC, Jerry wrote:
"Stanislav Blinov" writes:
Here's my latest revision: http://dpaste.dzfl.pl/5b54df1c7004
Yup, that helps out the AtomicSingleton a lot. Here's best and
worst times for each for dmd and gdc:
Cool, I almost started to research that C
On Friday, 7 February 2014 at 10:25:52 UTC, TC wrote:
Should't be the LockSingleton implemented like this instead?
class LockSingleton
{
static auto get()
{
if (_instance is null)
(_instance is null) will most likely not be an atomic operation.
References are two words. Imagi
"Stanislav Blinov" wrote in message
news:idrxthgkumydmiszd...@forum.dlang.org...
(_instance is null) will most likely not be an atomic operation.
References are two words.
References are one word.
On Friday, 7 February 2014 at 11:36:23 UTC, Daniel Murphy wrote:
"Stanislav Blinov" wrote in message
news:idrxthgkumydmiszd...@forum.dlang.org...
(_instance is null) will most likely not be an atomic
operation. References are two words.
References are one word.
Heh, indeed. Need to go have
On Friday, 7 February 2014 at 11:31:14 UTC, Stanislav Blinov
wrote:
On Friday, 7 February 2014 at 10:25:52 UTC, TC wrote:
Should't be the LockSingleton implemented like this instead?
class LockSingleton
{
static auto get()
{
if (_instance is null)
(_instance is null) will most l
On Friday, 7 February 2014 at 11:17:49 UTC, Stanislav Blinov
wrote:
On Friday, 7 February 2014 at 08:10:58 UTC, Sean Kelly wrote:
Weird. atomicLoad(raw) should be the same as atomicLoad(acq),
and atomicStore(raw) should be the same as atomicStore(rel).
At least on x86. I don't know why that
On Friday, 7 February 2014 at 15:42:06 UTC, Sean Kelly wrote:
Oops. I thought that since Intel has officially defined loads
as having acquire semantics, I had eliminated the barrier
requirement there. But I guess not. I suppose it's an issue
worth discussing. Does anyone know offhand what
On Friday, 7 February 2014 at 16:36:03 UTC, Stanislav Blinov
wrote:
No barriers in sight.
Awesome. Then I think we can go back to the old logic.
On 7 Feb 2014 15:45, "Sean Kelly" wrote:
>
> On Friday, 7 February 2014 at 11:17:49 UTC, Stanislav Blinov wrote:
>>
>> On Friday, 7 February 2014 at 08:10:58 UTC, Sean Kelly wrote:
>>>
>>> Weird. atomicLoad(raw) should be the same as atomicLoad(acq), and
atomicStore(raw) should be the same as ato
There's a lot more to these singletons than meets the eye.
- It would seem that such usage of raw MemoryOrder in
AtomicSingleton would be wrong (e.g. return to acq/rel is in
order, which should not pose any performance issues on X86, as
Sean mentioned).
- The instance references should be qu
On Friday, 7 February 2014 at 20:09:29 UTC, Stanislav Blinov
wrote:
There's a lot more to these singletons than meets the eye.
- It would seem that such usage of raw MemoryOrder in
AtomicSingleton would be wrong (e.g. return to acq/rel is in
order, which should not pose any performance issues
On Friday, 7 February 2014 at 16:57:50 UTC, Sean Kelly wrote:
On Friday, 7 February 2014 at 16:36:03 UTC, Stanislav Blinov
wrote:
No barriers in sight.
Awesome. Then I think we can go back to the old logic.
Cool. Also, from
http://en.cppreference.com/w/cpp/atomic/memory_order:
--8<--
O
Am Wed, 05 Feb 2014 16:47:40 -0500
schrieb Jerry :
> "Stanislav Blinov" writes:
>
> > On Wednesday, 5 February 2014 at 00:11:58 UTC, Jerry wrote:
> >
> >> Here's the best and worst times I get on my linux laptop. These are
> >> with 2.064.2 dmd and gdc 4.9 with 2.064.2
> >>
> >> On Ubuntu x86_6
Am Fri, 07 Feb 2014 17:10:06 +
schrieb "Stanislav Blinov" :
> On Friday, 7 February 2014 at 16:57:50 UTC, Sean Kelly wrote:
> > On Friday, 7 February 2014 at 16:36:03 UTC, Stanislav Blinov
> > wrote:
> >>
> >> No barriers in sight.
> >
> > Awesome. Then I think we can go back to the old logi
Am Fri, 7 Feb 2014 18:42:29 +
schrieb Iain Buclaw :
> On 7 Feb 2014 15:45, "Sean Kelly" wrote:
> >
> > On Friday, 7 February 2014 at 11:17:49 UTC, Stanislav Blinov wrote:
> >>
> >> On Friday, 7 February 2014 at 08:10:58 UTC, Sean Kelly wrote:
> >>>
> >>> Weird. atomicLoad(raw) should be the
On 02/07/2014 06:10 PM, Stanislav Blinov wrote:
On Friday, 7 February 2014 at 16:57:50 UTC, Sean Kelly wrote:
--8<--
On strongly-ordered systems (x86, SPARC, IBM mainframe), release-acquire
ordering is automatic for the majority of operations. No additional CPU
instructions are issued for this s
On 31.1.2014. 9:25, Andrej Mitrovic wrote:
> There was a nice blog-post about implementing low-lock singletons in D, here:
> http://davesdprogramming.wordpress.com/2013/05/06/low-lock-singletons/
>
> One suggestion on Reddit was by dawgfoto (I think this is Martin
> Nowak?), to use atomic primitiv
On Sunday, 9 February 2014 at 01:40:51 UTC, Martin Nowak wrote:
So, who is going to fix core.atomic?
I was under impression that Sean was onto it.
On Sunday, 9 February 2014 at 12:20:54 UTC, luka8088 wrote:
What about swapping function pointer so the check is done only
once per
thread? (Thread is tldr so I am sorry if someone already
suggested this)
That is an interesting idea indeed, though it seems to be faster
only for dmd. I haven'
On 02/09/2014 01:20 PM, luka8088 wrote:
class FunctionPointerSingleton {
private static __gshared typeof(this) instance_;
// tls
@property static typeof(this) function () get;
You don't even need to make this TLS, right?
static this () {
get = {
synchronized {
On 02/09/2014 03:07 PM, Stanislav Blinov wrote:
On Sunday, 9 February 2014 at 01:40:51 UTC, Martin Nowak wrote:
So, who is going to fix core.atomic?
I was under impression that Sean was onto it.
Can you please submit a bug report, so we don't loose track of this.
On Sunday, 9 February 2014 at 18:07:50 UTC, Martin Nowak wrote:
Can you please submit a bug report, so we don't loose track of
this.
Sure:
https://d.puremagic.com/issues/show_bug.cgi?id=12121
On Sunday, 9 February 2014 at 18:06:46 UTC, Martin Nowak wrote:
On 02/09/2014 01:20 PM, luka8088 wrote:
class FunctionPointerSingleton {
private static __gshared typeof(this) instance_;
// tls
@property static typeof(this) function () get;
You don't even need to make this TLS, right?
On 8 Feb 2014 01:20, "Marco Leise" wrote:
>
> Am Fri, 7 Feb 2014 18:42:29 +
> schrieb Iain Buclaw :
>
> > On 7 Feb 2014 15:45, "Sean Kelly" wrote:
> > >
> > > On Friday, 7 February 2014 at 11:17:49 UTC, Stanislav Blinov wrote:
> > >>
> > >> On Friday, 7 February 2014 at 08:10:58 UTC, Sean Kel
Isn't it great how a simple benchmark thread can reveal such
valuable insights and important problems?
On 9.2.2014. 15:09, Stanislav Blinov wrote:
> On Sunday, 9 February 2014 at 12:20:54 UTC, luka8088 wrote:
>
>> What about swapping function pointer so the check is done only once per
>> thread? (Thread is tldr so I am sorry if someone already suggested this)
>
> That is an interesting idea indeed
On 9.2.2014. 19:51, Stanislav Blinov wrote:
> On Sunday, 9 February 2014 at 18:06:46 UTC, Martin Nowak wrote:
>> On 02/09/2014 01:20 PM, luka8088 wrote:
>>> class FunctionPointerSingleton {
>>>
>>> private static __gshared typeof(this) instance_;
>>>
>>> // tls
>>> @property static typeof(thi
On 2/9/14, luka8088 wrote:
> What about swapping function pointer so the check is done only once per
> thread? (Thread is tldr so I am sorry if someone already suggested this)
Interesting solution for sure.
> // tls
> @property static typeof(this) function () get;
This confused me for a sec
On 2/9/14, luka8088 wrote:
> private static __gshared typeof(this) instance_;
Also, "static __gshared" is really meaningless here, it's either
static (TLS), or globally shared, either way it's not a class
instance, so you can type __gshared alone here. Otherwise I'm not sure
what the semantics
On 2/9/14, luka8088 wrote:
> dmd -release -inline -O -noboundscheck -unittest -run singleton.d
>
> Test time for LockSingleton: 901 msecs.
> Test time for SyncSingleton: 20.75 msecs.
> Test time for AtomicSingleton: 169 msecs.
> Test time for FunctionPointerSingleton: 7.5 msecs.
C:\dev\code\d_cod
On 10.2.2014. 10:52, Andrej Mitrovic wrote:
> On 2/9/14, luka8088 wrote:
>> What about swapping function pointer so the check is done only once per
>> thread? (Thread is tldr so I am sorry if someone already suggested this)
>
> Interesting solution for sure.
>
>> // tls
>> @property static t
On 10.2.2014. 10:54, Andrej Mitrovic wrote:
> On 2/9/14, luka8088 wrote:
>> private static __gshared typeof(this) instance_;
>
> Also, "static __gshared" is really meaningless here, it's either
> static (TLS), or globally shared, either way it's not a class
> instance, so you can type __gshared
On 10.2.2014. 10:59, Andrej Mitrovic wrote:
> On 2/9/14, luka8088 wrote:
>> dmd -release -inline -O -noboundscheck -unittest -run singleton.d
>>
>> Test time for LockSingleton: 901 msecs.
>> Test time for SyncSingleton: 20.75 msecs.
>> Test time for AtomicSingleton: 169 msecs.
>> Test time for Fun
On 10.2.2014. 13:44, luka8088 wrote:
> On 10.2.2014. 10:54, Andrej Mitrovic wrote:
>> On 2/9/14, luka8088 wrote:
>>> private static __gshared typeof(this) instance_;
>>
>> Also, "static __gshared" is really meaningless here, it's either
>> static (TLS), or globally shared, either way it's not a
On 2/10/14, luka8088 wrote:
> "static" does not mean it must be tls, as "static shared" is valid.
Yes you're right. I'm beginning to really dislike the 20 different
meanings of "static". :)
"Andrej Mitrovic" wrote in message
news:mailman.111.1392039607.21734.digitalmar...@puremagic.com...
Yes you're right. I'm beginning to really dislike the 20 different
meanings of "static". :)
Don't forget that __gshared static and static __gshared do different things!
1 - 100 of 110 matches
Mail list logo
