www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Arc.Tango

reply Clay Smith <clayasaurus gmail.com> writes:
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
next sibling parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
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
parent reply Clay Smith <clayasaurus gmail.com> writes:
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
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
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
next sibling parent Clay Smith <clayasaurus gmail.com> writes:
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'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.


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
prev sibling next sibling parent Lars Ivar Igesund <larsivar igesund.net> writes:
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
prev sibling next sibling parent reply Sean Kelly <sean f4.ca> writes:
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
next sibling parent redsea <redsea 163.com> writes:
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
prev sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
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
parent Sean Kelly <sean f4.ca> writes:
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
prev sibling parent kris <foo bar.com> writes:
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
prev sibling next sibling parent Lutger <lutger.blijdestijn gmail.com> writes:
Great, thanks!
Sep 06 2007
prev sibling parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"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