www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Why aren't Ranges Interfaces?

reply "Jack Stouffer" <jack jackstouffer.com> writes:
I have been learning D over the past three weeks and I came to 
the chapter in "Programming in D" on Ranges. And I am a little 
confused on the choice to make Ranges based on the methods you 
have in the struct, but not use a interface. With all of the 
isInputRange!R you have to write everywhere, it just seems like 
it would have made a lot more sense and made everyone's jobs 
easier if the different types of Ranges where just interfaces 
that you could inherit from.

The only reason I can think of to not do it this way is the weird 
distinction between structs and classes in D.
Jun 26 2015
next sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Friday, 26 June 2015 at 18:37:51 UTC, Jack Stouffer wrote:
 The only reason I can think of to not do it this way is the 
 weird distinction between structs and classes in D.
If anything, C++ is the weird one in having two keywords that mean the same thing... But the reason comes down to three things: 1) They are! http://dlang.org/phobos/std_range_interfaces.html That works in some cases, but not all. They aren't typically used though because of the other reasons: 2) interfaces have an associated runtime cost, which ranges wanted to avoid. They come with hidden function pointers and if you actually use it through them, you can get a performance hit. In theory, the compiler could optimize that in some cases, making the interface syntax sugar for the isInputRange thing, but that still doesn't solve... 3) Ranges don't just meet an interface, they can also have other optional elements, like infiniteness or additional methods, that aren't expressible through inherited methods. Some of that could be solved by having many interfaces together, but not all of it. Infiniteness, for example, is seen by the fact that empty is a constant false rather than a method. Perhaps you could reengineer this too, but then the interfaces don't look as clean as they otherwise would. (Look at how many variants there are in that std.range.interfaces, and it still doesn't actually cover everything!) These two items together mean ranges typically don't fit the interface model well. If you're looking at a case where it is a good fit though, you can use the provided interfaces and wrappers.
Jun 26 2015
parent reply "Jack Stouffer" <jack jackstouffer.com> writes:
Thanks for the reply! I understand the reasoning now.

On Friday, 26 June 2015 at 18:46:03 UTC, Adam D. Ruppe wrote:
 2) interfaces have an associated runtime cost, which ranges 
 wanted to avoid. They come with hidden function pointers and if 
 you actually use it through them, you can get a performance hit.
How much of a performance hit are we talking about? Is the difference between using an interface and not using one noticeable?
Jun 26 2015
next sibling parent reply "rsw0x" <anonymous anonymous.com> writes:
On Friday, 26 June 2015 at 19:26:57 UTC, Jack Stouffer wrote:
 Thanks for the reply! I understand the reasoning now.

 On Friday, 26 June 2015 at 18:46:03 UTC, Adam D. Ruppe wrote:
 2) interfaces have an associated runtime cost, which ranges 
 wanted to avoid. They come with hidden function pointers and 
 if you actually use it through them, you can get a performance 
 hit.
How much of a performance hit are we talking about? Is the difference between using an interface and not using one noticeable?
It can be in a tight loop. http://eli.thegreenplace.net/2013/12/05/the-cost-of-dynamic-virtual-calls-vs-static-crtp-dispatch-in-c this is for C++, but it applies directly to D. Interestingly, CRTP is a gigantic C++ hack that D gets for free with alias this.
Jun 26 2015
parent "Jack Stouffer" <jack jackstouffer.com> writes:
On Friday, 26 June 2015 at 19:40:41 UTC, rsw0x wrote:
 On Friday, 26 June 2015 at 19:26:57 UTC, Jack Stouffer wrote:
 Thanks for the reply! I understand the reasoning now.

 On Friday, 26 June 2015 at 18:46:03 UTC, Adam D. Ruppe wrote:
 2) interfaces have an associated runtime cost, which ranges 
 wanted to avoid. They come with hidden function pointers and 
 if you actually use it through them, you can get a 
 performance hit.
How much of a performance hit are we talking about? Is the difference between using an interface and not using one noticeable?
It can be in a tight loop. http://eli.thegreenplace.net/2013/12/05/the-cost-of-dynamic-virtual-calls-vs-static-crtp-dispatch-in-c this is for C++, but it applies directly to D. Interestingly, CRTP is a gigantic C++ hack that D gets for free with alias this.
In my code I need to use polymorphism. But, if I replace the code for my interface inheritance with an inherit of an class that implements empty methods and my methods just override the empty ones I get an essentially free performance boost 0_0? Good to know; thanks for the link.
Jun 26 2015
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
On Friday, 26 June 2015 at 19:26:57 UTC, Jack Stouffer wrote:
 How much of a performance hit are we talking about? Is the 
 difference between using an interface and not using one 
 noticeable?
It can be huge difference if you take inlning in mind. LDC is capable of flattening most simple range-based pipelines into simple in-place loop during optimization - something you can't do with interfaces unless some sort of runtime profiling optimization is involved.
Jun 26 2015
prev sibling parent Justin Whear <justin economicmodeling.com> writes:
On Fri, 26 Jun 2015 19:26:56 +0000, Jack Stouffer wrote:

 Thanks for the reply! I understand the reasoning now.
 
 On Friday, 26 June 2015 at 18:46:03 UTC, Adam D. Ruppe wrote:
 2) interfaces have an associated runtime cost, which ranges wanted to
 avoid. They come with hidden function pointers and if you actually use
 it through them, you can get a performance hit.
How much of a performance hit are we talking about? Is the difference between using an interface and not using one noticeable?
For some real numbers, a while back I wrote up several variations on a "big data" type process for a presentation on memory performance and the importance of cache hits. The classic Java-style class-based version ran in 4 seconds while the lazy range struct version ran in 0.83 seconds. Using LDC to inline (impossible with interfaces) brought the runtime down to 0.38 seconds.
Jun 26 2015
prev sibling next sibling parent "rsw0x" <anonymous anonymous.com> writes:
On Friday, 26 June 2015 at 18:37:51 UTC, Jack Stouffer wrote:
 I have been learning D over the past three weeks and I came to 
 the chapter in "Programming in D" on Ranges. And I am a little 
 confused on the choice to make Ranges based on the methods you 
 have in the struct, but not use a interface. With all of the 
 isInputRange!R you have to write everywhere, it just seems like 
 it would have made a lot more sense and made everyone's jobs 
 easier if the different types of Ranges where just interfaces 
 that you could inherit from.

 The only reason I can think of to not do it this way is the 
 weird distinction between structs and classes in D.
They're essentially compile-time interfaces. I would prefer having a real name/binding implementation for this, like contract.
Jun 26 2015
prev sibling parent =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 06/26/2015 11:37 AM, Jack Stouffer wrote:

 easier if the different types of Ranges where
 just interfaces that you could inherit from.
If you think you need polymorphic interfaces, the next chapter talks about inputRangeObject(): http://ddili.org/ders/d.en/ranges_more.html#ix_ranges_more.polymorphism,%20run-time Ali
Jun 26 2015