www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Ideas for Phobos.

reply "Zz" <zz nospam.com> writes:
Features in the following libraries are really good.
IT would be really good if phobos incorporates what they have.

Just put here for reference:

General Pourpose:
POCO
http://pocoproject.org/features.html
It's a c++ library that is under Boost Software License 1.0.

JUCE
http://www.rawmaterialsoftware.com/jucefeatures.php
Good lib

Graphics and Windows.

Anti-Grain Geometry 2D
http://www.antigrain.com/
Used this before.

MigLayout - Java Layout Manager
http://www.miglayout.com
GUI layout management done right.

Winn32++
http://win32-framework.sourceforge.net/index.htm

Aswang - Win32 Wrapper
http://aswang.sourceforge.net/
Simple and straight forward.

Zz
Mar 16 2012
next sibling parent reply "Jay Norwood" <jayn prismnet.com> writes:
On Friday, 16 March 2012 at 12:48:39 UTC, Zz wrote:
 Features in the following libraries are really good.
 IT would be really good if phobos incorporates what they have.

 Just put here for reference:

 General Pourpose:
 POCO
 http://pocoproject.org/features.html
 It's a c++ library that is under Boost Software License 1.0.

 JUCE
 http://www.rawmaterialsoftware.com/jucefeatures.php
 Good lib

 Graphics and Windows.

 Anti-Grain Geometry 2D
 http://www.antigrain.com/
 Used this before.

I don't know what the license is, but this guy doing U++ development did his own implementation of the subpixel rendering technique described by agg. He says it added about 100 lines of code to his Painter library. He discusses it in these posts. http://www.ultimatepp.org/forum/index.php?t=msg&goto=20174& It looks pretty nice to me when used in one of the graphing project in their examples. http://www.ultimatepp.org/srcdoc$PlotLib$PlotLib$en-us.html
Mar 16 2012
next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
  On 03/16/2012 02:39 PM, Jay Norwood wrote:
 On Friday, 16 March 2012 at 13:20:39 UTC, Jay Norwood wrote:

 btw, the u++ page claims in the link below to be faster than D by 70% on
 some operations, which they attribute to their STL rewrite. Maybe
 someone should take a look at what they've done. Or maybe this
 comparison is out of date...

 http://www.ultimatepp.org/www$uppweb$vsd$en-us.html

"Means C++ is still well ahead of D (by 70%) if not being hold back by standard library design and average implementation..." They explain the former results with differences in implementations and their new results with differences in languages, after having optimized the implementation in one language but not in the other. x)
Mar 16 2012
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/16/12 8:39 AM, Jay Norwood wrote:
 On Friday, 16 March 2012 at 13:20:39 UTC, Jay Norwood wrote:

 btw, the u++ page claims in the link below to be faster than D by 70% on
 some operations, which they attribute to their STL rewrite. Maybe
 someone should take a look at what they've done. Or maybe this
 comparison is out of date...

 http://www.ultimatepp.org/www$uppweb$vsd$en-us.html

The test uses a specific data structure, an indexed contiguous array. To conclude from here that C++ is faster than D is quite a stretch. Andrei
Mar 16 2012
prev sibling next sibling parent "Jay Norwood" <jayn prismnet.com> writes:
On Friday, 16 March 2012 at 13:20:39 UTC, Jay Norwood wrote:

btw, the u++ page claims in the link below to be faster than D by 
70% on some operations, which they attribute to their STL 
rewrite. Maybe someone should take a look at what they've done.  
Or maybe this comparison is out of date...

http://www.ultimatepp.org/www$uppweb$vsd$en-us.html
Mar 16 2012
prev sibling next sibling parent "Jay Norwood" <jayn prismnet.com> writes:
On Friday, 16 March 2012 at 14:26:19 UTC, Andrei Alexandrescu 
wrote:
 http://www.ultimatepp.org/www$uppweb$vsd$en-us.html

The test uses a specific data structure, an indexed contiguous array. To conclude from here that C++ is faster than D is quite a stretch. Andrei

In fact the claim is no longer true. I pulled down their latest build and tested with a large Alice (duplicated many times to get it up to measureable consistently). I used the library stopwatch measurements for each. The results come out about the same ... theirs is a few msec faster on 10MB of input with their optimizations for speed turned on. This is on a win7-64 corei7 box, but compiling for 32 bit with msvc for their code. this is for upp, 4193 build G:\upp\out\MyApps\MSC9.Force_Speed.Sse2>alice2 lines words bytes file 224160 1825140 10050960 alice2.txt time: 93 ms skey: zip sval: 60 map size;3482 this is for d 2.058 G:\d\alice2\alice2\alice2\Release>alice2 lines words bytes file 224160 1825140 10050960 alice2.txt time: 97 ms skey: zip sval: 60 dictionary length:3482
Mar 16 2012
prev sibling parent "Jay Norwood" <jayn prismnet.com> writes:
On Friday, 16 March 2012 at 14:26:19 UTC, Andrei Alexandrescu 
wrote:
 On 3/16/12 8:39 AM, Jay Norwood wrote:
 On Friday, 16 March 2012 at 13:20:39 UTC, Jay Norwood wrote:

 btw, the u++ page claims in the link below to be faster than D 
 by 70% on
 some operations, which they attribute to their STL rewrite. 
 Maybe
 someone should take a look at what they've done. Or maybe this
 comparison is out of date...

 http://www.ultimatepp.org/www$uppweb$vsd$en-us.html

The test uses a specific data structure, an indexed contiguous array. To conclude from here that C++ is faster than D is quite a stretch. Andrei

Ok, but maybe the the upp arrayMap is pretty efficient for certain things ... by their benchmarks 4x faster than STL on whatever they were doing. I tried rewriting the D example code, and upp is consistently a bit faster when running on a single core. http://www.ultimatepp.org/src$Core$ArrayMap$en-us.html A D std.parallelism library rewrite of the example runs about 2x faster than the current upp example code on a corei7 box, if you give it several files to work on. The execution doesn't scale as much as I expected, probably because the dictionary gets duplicated in the parallel case, while the single thread just increments counts in the same dictionary. I believe the TDPL book mentioned some research on non-locking, shared memory containers, but I didn't see anything documented in the D libraries. There is the workerLocalStorage area ... but it wouldn't help with the problem of the dictionary getting duplicated in this case. It look like there would be a reduce step required to merge the dictionary counts at the end.
Mar 17 2012