digitalmars.D.announce - Arc.Tango
- Clay Smith <clayasaurus gmail.com> Sep 06 2007
- Bruno Medeiros <brunodomedeiros+spam com.gmail> Sep 06 2007
- Clay Smith <clayasaurus gmail.com> Sep 06 2007
- Bill Baxter <dnewsgroup billbaxter.com> Sep 06 2007
- Clay Smith <clayasaurus gmail.com> Sep 06 2007
- Lars Ivar Igesund <larsivar igesund.net> Sep 06 2007
- Sean Kelly <sean f4.ca> Sep 06 2007
- redsea <redsea 163.com> Sep 06 2007
- Bill Baxter <dnewsgroup billbaxter.com> Sep 08 2007
- Sean Kelly <sean f4.ca> Sep 08 2007
- kris <foo bar.com> Sep 06 2007
- Lutger <lutger.blijdestijn gmail.com> Sep 06 2007
- "Jarrett Billingsley" <kb3ctd2 yahoo.com> Sep 06 2007
Arc v.02 has been successfully ported over to Tango, and will be using Tango as the only supported standard library for future releases. I put my rationale on a wiki, as well: http://www.dsource.org/projects/arclib/wiki/WhyUseTango Arc v.02 Stable Tango Branch: http://svn.dsource.org/projects/arclib/branches/arc02/tango/ Arc is a cross platform arcade game library, providing easy access to 2d graphics, sound, input, a graphical user interface, and more. ~ Clay
Sep 06 2007
Clay Smith wrote:Arc v.02 has been successfully ported over to Tango, and will be using Tango as the only supported standard library for future releases. I put my rationale on a wiki, as well: http://www.dsource.org/projects/arclib/wiki/WhyUseTango Arc v.02 Stable Tango Branch: http://svn.dsource.org/projects/arclib/branches/arc02/tango/ Arc is a cross platform arcade game library, providing easy access to 2d graphics, sound, input, a graphical user interface, and more. ~ Clay
What Tango facilities are you using (or planning to use)? -- Bruno Medeiros - MSc in CS/E student http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Sep 06 2007
Bruno Medeiros wrote:Clay Smith wrote:Arc v.02 has been successfully ported over to Tango, and will be using Tango as the only supported standard library for future releases. I put my rationale on a wiki, as well: http://www.dsource.org/projects/arclib/wiki/WhyUseTango Arc v.02 Stable Tango Branch: http://svn.dsource.org/projects/arclib/branches/arc02/tango/ Arc is a cross platform arcade game library, providing easy access to 2d graphics, sound, input, a graphical user interface, and more. ~ Clay
What Tango facilities are you using (or planning to use)?
I mostly use tango's bare minimum features, but... Using * Signals * Logging Planned * VFS * Maybe Reader, Writer * Maybe some collections * Maybe XML if tango decides to get that
Sep 06 2007
Clay Smith wrote:Bruno Medeiros wrote:Clay Smith wrote:Arc v.02 has been successfully ported over to Tango, and will be using Tango as the only supported standard library for future releases. I put my rationale on a wiki, as well: http://www.dsource.org/projects/arclib/wiki/WhyUseTango Arc v.02 Stable Tango Branch: http://svn.dsource.org/projects/arclib/branches/arc02/tango/ Arc is a cross platform arcade game library, providing easy access to 2d graphics, sound, input, a graphical user interface, and more. ~ Clay
What Tango facilities are you using (or planning to use)?
I mostly use tango's bare minimum features, but... Using * Signals * Logging Planned * VFS * Maybe Reader, Writer * Maybe some collections * Maybe XML if tango decides to get that
You make a lot of good points on that page. Have you (or anyone) tested the performance of the tango containers? I'm concerned about the performance impact of all iterators being heap-allocated, interface-accessed things, but I suspect there are ways to work around that (maybe using opApply's or scope'ing iterators). From a quick look it appears that opApply scope allocates and uses the actual iterator type, thus avoiding both the heap and virtual calls. But the iterator returned by .elements is a heap-allocated generic interface pointer. On the other hand opApply will have to go through a few delegate calls to get at your loop body. So anyway, it's not exactly clear to me what price I end up having to pay at the pump vs a more STL-like thinly-veiled-pointers approach. --bb
Sep 06 2007
Clay Smith <clayasaurus gmail.com> Bill Baxter wrote:Clay Smith wrote:Bruno Medeiros wrote:Clay Smith wrote:Arc v.02 has been successfully ported over to Tango, and will be using Tango as the only supported standard library for future releases. I put my rationale on a wiki, as well: http://www.dsource.org/projects/arclib/wiki/WhyUseTango Arc v.02 Stable Tango Branch: http://svn.dsource.org/projects/arclib/branches/arc02/tango/ Arc is a cross platform arcade game library, providing easy access to 2d graphics, sound, input, a graphical user interface, and more. ~ Clay
What Tango facilities are you using (or planning to use)?
I mostly use tango's bare minimum features, but... Using * Signals * Logging Planned * VFS * Maybe Reader, Writer * Maybe some collections * Maybe XML if tango decides to get that
You make a lot of good points on that page. Have you (or anyone) tested the performance of the tango containers?
No, but I'm planning to test the performance of the Tango containers vs. my own, and then if I find mine to be faster/better, write a patch to make the tango containers faster/better and hope it goes through :) I'mconcerned about the performance impact of all iterators being heap-allocated, interface-accessed things, but I suspect there are ways to work around that (maybe using opApply's or scope'ing iterators). From a quick look it appears that opApply scope allocates and uses the actual iterator type, thus avoiding both the heap and virtual calls. But the iterator returned by .elements is a heap-allocated generic interface pointer. On the other hand opApply will have to go through a few delegate calls to get at your loop body. So anyway, it's not exactly clear to me what price I end up having to pay at the pump vs a more STL-like thinly-veiled-pointers approach.
Yea, I don't know much about the way Tango currently does it. What I'm /assuming/ about Tango, is that, given enough time for user testing and patch submits, it will eventually offer optimal solutions. ~ Clay
Sep 06 2007
Bill Baxter wrote:You make a lot of good points on that page. Have you (or anyone) tested the performance of the tango containers? I'm concerned about the performance impact of all iterators being heap-allocated, interface-accessed things, but I suspect there are ways to work around that (maybe using opApply's or scope'ing iterators). From a quick look it appears that opApply scope allocates and uses the actual iterator type, thus avoiding both the heap and virtual calls. But the iterator returned by .elements is a heap-allocated generic interface pointer. On the other hand opApply will have to go through a few delegate calls to get at your loop body. So anyway, it's not exactly clear to me what price I end up having to pay at the pump vs a more STL-like thinly-veiled-pointers approach.
For various reasons, the Tango team also thinks that the containers probably could be more optimal, mostly because they were not originally written in D. In unofficial tests reported on #d.tango, the Tango containers seems to be comparable to STL, though. -- Lars Ivar Igesund blog at http://larsivi.net DSource, #d.tango & #D: larsivi Dancing the Tango
Sep 06 2007
Bill Baxter wrote:Have you (or anyone) tested the performance of the tango containers? I'm concerned about the performance impact of all iterators being heap-allocated, interface-accessed things, but I suspect there are ways to work around that (maybe using opApply's or scope'ing iterators).
I /really/ want a chance to work on containers someday soon, but I'd like to preserve the interface aspect for a few reasons: * It makes the Tango implementation a framework to build on rather than a reference set of containers. * Following from the previous point, it separates the container library interface from its implementation. * It allows for Java-style (ie. runtime) container access as well as C++-style (ie. template-oriented) container access. If structs are used as iterators there would be no way to prevent their being copied, and some things which could be described as iterators should not really be copyable (input iterators, ODBC cursors, etc). Also, there may be some merit in having iterator interfaces as well. But perhaps the virtual function calls here would be prohibitively expensive. I would be interested to hear opinions on performance requirements related to this. Sean
Sep 06 2007
C++ STL's qsort is much faster than C's, because C's implemement need a function call, a function not only need more CPU instructions, but effect the pipeline, prefech subsystem and cache. So if a iterator is implement with interface, I would not us it when I need high performance, it would a pain when I need to write complex datastructure. I sugesst you can consider implement an inner iterator as structure, but wrap it with a class for daily use, when one need high performance, he can switch to the raw high performance version. Sean Kelly Wrote:Bill Baxter wrote:Have you (or anyone) tested the performance of the tango containers? I'm concerned about the performance impact of all iterators being heap-allocated, interface-accessed things, but I suspect there are ways to work around that (maybe using opApply's or scope'ing iterators).
I /really/ want a chance to work on containers someday soon, but I'd like to preserve the interface aspect for a few reasons: * It makes the Tango implementation a framework to build on rather than a reference set of containers. * Following from the previous point, it separates the container library interface from its implementation. * It allows for Java-style (ie. runtime) container access as well as C++-style (ie. template-oriented) container access. If structs are used as iterators there would be no way to prevent their being copied, and some things which could be described as iterators should not really be copyable (input iterators, ODBC cursors, etc). Also, there may be some merit in having iterator interfaces as well. But perhaps the virtual function calls here would be prohibitively expensive. I would be interested to hear opinions on performance requirements related to this. Sean
Sep 06 2007
Sean Kelly wrote:Bill Baxter wrote:Have you (or anyone) tested the performance of the tango containers? I'm concerned about the performance impact of all iterators being heap-allocated, interface-accessed things, but I suspect there are ways to work around that (maybe using opApply's or scope'ing iterators).
I /really/ want a chance to work on containers someday soon, but I'd like to preserve the interface aspect for a few reasons: * It makes the Tango implementation a framework to build on rather than a reference set of containers. * Following from the previous point, it separates the container library interface from its implementation. * It allows for Java-style (ie. runtime) container access as well as C++-style (ie. template-oriented) container access.
But it does it allow the C++-style currently? It seems like currently the containers themselves have access to a way to instantiate a concrete iterator and bypassing the interfaces, but not the outside world. There's no generic alias for a containers concrete iterator type, for instance, and no function that returns an object of the actual concrete type rather than an interface pointer. At least I didn't notice any.If structs are used as iterators there would be no way to prevent their being copied, and some things which could be described as iterators should not really be copyable (input iterators, ODBC cursors, etc).
I think D2.0 is going to give you a way to have some code run after the element-wise copy, so you could throw an exception there for the iterators that shouldn't be copyable. Maybe even a static assert. But that's not much help today.Also, there may be some merit in having iterator interfaces as well. But perhaps the virtual function calls here would be prohibitively expensive. I would be interested to hear opinions on performance requirements related to this.
Don't your iterators already have interfaces? You must mean something different from what I think you mean. --bb
Sep 08 2007
Bill Baxter wrote:Sean Kelly wrote:Also, there may be some merit in having iterator interfaces as well. But perhaps the virtual function calls here would be prohibitively expensive. I would be interested to hear opinions on performance requirements related to this.
Don't your iterators already have interfaces? You must mean something different from what I think you mean.
I mean a future, theoretical implementation. Aside from some D-ification about a year ago, we really haven't spent much time on tango.util.container beyond the original port from Java. Sean
Sep 08 2007
Bill Baxter wrote: [snip]Have you (or anyone) tested the performance of the tango containers? I'm
Some tests were performed recently that indicate the HashMap is slower than AA for write, but significantly faster for read.concerned about the performance impact of all iterators being heap-allocated, interface-accessed things, but I suspect there are ways to work around that (maybe using opApply's or scope'ing iterators).
Tango containers have opApply() on the container itself, so the heap iterators are purely optional.
Sep 06 2007
"Clay Smith" <clayasaurus gmail.com> wrote in message news:fbp54u$1pt9$1 digitalmars.com...Arc v.02 has been successfully ported over to Tango, and will be using Tango as the only supported standard library for future releases.
Welcome to the light side!
Sep 06 2007