View mode: basic / threaded / horizontal-split · Log in · Help
March 16, 2012
Ideas for Phobos.
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
March 16, 2012
Re: Ideas for Phobos.
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
March 16, 2012
Re: Ideas for Phobos., u++ STL speed comparison
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
March 16, 2012
Re: Ideas for Phobos., u++ STL speed comparison
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)
March 16, 2012
Re: Ideas for Phobos., u++ STL speed comparison
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
March 16, 2012
Re: Ideas for Phobos., u++ STL speed comparison
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
March 18, 2012
Re: Ideas for Phobos., u++ STL speed comparison
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.
Top | Discussion index | About this forum | D home