Low-overhead components

2013-07-27 Thread Vladimir Panteleev
Not really an article or anything - this was planned as just a post to this newsgroup, but I decided to put it somewhere suitable for larger blocks of text with formatting: http://blog.thecybershadow.net/2013/07/28/low-overhead-components/

Re: Low-overhead components

2013-07-28 Thread Kagamin
For a hashtable to know about its container is probably more wasteful than having a pointer to the allocator. If you don't like deep nesting, write a shortcut function, which will do the entire job for you similar to the read function: http://dlang.org/phobos/std_file.html#.read

Re: Low-overhead components

2013-07-28 Thread Andrei Alexandrescu
On 7/27/13 11:20 PM, Vladimir Panteleev wrote: Not really an article or anything - this was planned as just a post to this newsgroup, but I decided to put it somewhere suitable for larger blocks of text with formatting: http://blog.thecybershadow.net/2013/07/28/low-overhead-components/ Nice

Re: Low-overhead components

2013-07-28 Thread Kagamin
BTW, there's no fast way to boundcheck two-ptr range. It should work similar to opSlice: T opIndex(size_t index) { static if (CHECKED) assert(index < end-ptr); return *(ptr + index); }

Re: Low-overhead components

2013-07-28 Thread Vladimir Panteleev
On Sunday, 28 July 2013 at 12:31:46 UTC, Kagamin wrote: For a hashtable to know about its container is probably more wasteful than having a pointer to the allocator. Why? The difference is one indirection. Are you referring to the impact of template bloat and code cache misses? If you don't

Re: Low-overhead components

2013-07-28 Thread Vladimir Panteleev
On Sunday, 28 July 2013 at 18:51:15 UTC, Kagamin wrote: BTW, there's no fast way to boundcheck two-ptr range. It should work similar to opSlice: T opIndex(size_t index) { static if (CHECKED) assert(index < end-ptr); return *(ptr + index); } That's a bug, thanks. But non-release-build

Re: Low-overhead components

2013-07-29 Thread Luís.Marques
-overhead-components/ BTW, slightly off-topic, but could you clarify something for me? In the phrase "I understand that STL allocators are stateless, which is boring ", does the expression "I understand that" mean "I think the following is true, but I'm not sure" or

Re: Low-overhead components

2013-07-29 Thread Andrei Alexandrescu
On 7/27/13 11:20 PM, Vladimir Panteleev wrote: Not really an article or anything - this was planned as just a post to this newsgroup, but I decided to put it somewhere suitable for larger blocks of text with formatting: http://blog.thecybershadow.net/2013/07/28/low-overhead-components/ Vote

Re: Low-overhead components

2013-07-29 Thread Walter Bright
On 7/27/2013 11:20 PM, Vladimir Panteleev wrote: Not really an article or anything - this was planned as just a post to this newsgroup, but I decided to put it somewhere suitable for larger blocks of text with formatting: http://blog.thecybershadow.net/2013/07/28/low-overhead-components

Re: Low-overhead components

2013-07-29 Thread Vladimir Panteleev
://blog.thecybershadow.net/2013/07/28/low-overhead-components/ Please include your name as author on this! Fixed, thanks. I wasn't sure if the post was ready for Reddit, as it's mainly some thoughts written down for advanced D users.

Re: Low-overhead components

2013-07-29 Thread Jonathan A Dunlap
Fixed, thanks. I wasn't sure if the post was ready for Reddit, as it's mainly some thoughts written down for advanced D users. Thanks for writing this. Aside from the primary purpose of the article, I was able to learn along the way more about D's mixins because of it. As a game architect, I

Re: Low-overhead components

2013-07-30 Thread Faux Amis
On 28-7-2013 08:20, Vladimir Panteleev wrote: Not really an article or anything - this was planned as just a post to this newsgroup, but I decided to put it somewhere suitable for larger blocks of text with formatting: http://blog.thecybershadow.net/2013/07/28/low-overhead-components/ I do

Re: Low-overhead components

2013-07-30 Thread Dicebot
On Tuesday, 30 July 2013 at 12:37:26 UTC, Faux Amis wrote: I do not understand what this code should help with: struct LAYER(BASE) { BASE base; // ... use base ... } Any advice on what I should read to get it? (no C++ exp) It is meant to do "has-a" (http://en.wikipedia.org/wiki/Has-a)

Re: Low-overhead components

2013-07-30 Thread Dicebot
-overhead-components/ On topic of proposals: what to you think about embedding context pointer into struct when such alias is used? That will require some enforcement from compiler if template instance will be actually used as member field in same struct but avoid template bloat and fits with existing

Re: Low-overhead components

2013-07-30 Thread Vladimir Panteleev
formatting: http://blog.thecybershadow.net/2013/07/28/low-overhead-components/ On topic of proposals: what to you think about embedding context pointer into struct when such alias is used? That will require some enforcement from compiler if template instance will be actually used as member field in

Re: Low-overhead components

2013-07-30 Thread Faux Amis
On 30-7-2013 14:48, Dicebot wrote: On Tuesday, 30 July 2013 at 12:37:26 UTC, Faux Amis wrote: I do not understand what this code should help with: struct LAYER(BASE) { BASE base; // ... use base ... } Any advice on what I should read to get it? (no C++ exp) It is meant to do "has-a"

Re: Low-overhead components

2013-07-30 Thread Dicebot
On Tuesday, 30 July 2013 at 14:21:55 UTC, Vladimir Panteleev wrote: While not a bad proposal in itself, it's not very interesting in terms of performance. If we are to do pointers, then pointers to the lower layer aren't much harder to do by hand and save you the ECX (this pointer) adjustment w

Re: Low-overhead components

2013-07-30 Thread Vladimir Panteleev
On Tuesday, 30 July 2013 at 14:33:59 UTC, Faux Amis wrote: like this:? struct LAYER(BASE) { BASE base; // ... use base ... void func(){}; } struct Base { alias LAYER!(Base) Layer; Layer layer; layer.base = this; layer.func(); // ... }

Re: Low-overhead components

2013-07-30 Thread Kagamin
On Sunday, 28 July 2013 at 21:03:43 UTC, Vladimir Panteleev wrote: Why? The difference is one indirection. Are you referring to the impact of template bloat and code cache misses? bloat Yes, but you still need to write it. That's what we do. You need to write it anyway to provide simple int

Re: Low-overhead components

2013-07-30 Thread Faux Amis
On 30-7-2013 17:22, Vladimir Panteleev wrote: On Tuesday, 30 July 2013 at 14:33:59 UTC, Faux Amis wrote: like this:? struct LAYER(BASE) { BASE base; // ... use base ... void func(){}; } struct Base { alias LAYER!(Base) Layer; Layer layer; layer.base = this; layer.fu

Re: Low-overhead components

2013-07-30 Thread Vladimir Panteleev
On Tuesday, 30 July 2013 at 15:57:50 UTC, Kagamin wrote: On Sunday, 28 July 2013 at 21:03:43 UTC, Vladimir Panteleev wrote: Why? The difference is one indirection. Are you referring to the impact of template bloat and code cache misses? bloat In most cases, only one template instance will be

Re: Low-overhead components

2013-07-31 Thread Kagamin
On Tuesday, 30 July 2013 at 16:48:42 UTC, Vladimir Panteleev wrote: In most cases, only one template instance will be "hot" at one time, so I don't think it would be a problem in general. You need to load templates from disk. I'm thinking about Adobe products, though I don't know why they're s

Re: Low-overhead components

2013-07-31 Thread Vladimir Panteleev
On Wednesday, 31 July 2013 at 08:04:35 UTC, Kagamin wrote: On Tuesday, 30 July 2013 at 16:48:42 UTC, Vladimir Panteleev wrote: In most cases, only one template instance will be "hot" at one time, so I don't think it would be a problem in general. You need to load templates from disk. Loaded