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

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

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

Great, thanks!

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

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

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

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

"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!

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