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
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
parent reply "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
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 reply 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
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