It's just a port so that should be the case.
On 7 Nov 2013 09:25, "Suliman" <bubnenkoff@gmail.com> wrote:

> The C library is relatively small, clocking in at about ~11.000
>>
> lines
> Do I right understand that rewriting code from C to D did not make it's
> more compact? I tried to calculate D source lines, and get ~11.000
>

On 11/7/13, Suliman <bubnenkoff@gmail.com> wrote:
>>The C library is relatively small, clocking in at about ~11.000
> lines
> Do I right understand that rewriting code from C to D did not
> make it's more compact? I tried to calculate D source lines, and
> get ~11.000

I did not refactor, it's a straight port.

On 11/7/13, Sergei Nosov <sergei.nosov@gmail.com> wrote:
> I don't have the numbers (I
> didn't find where to look for the FPS), but it hinders exactly
> the same as dmd.

Hmm, I have the same issue. It might be an issue with the port. Or worse-case scenario, something wrong with the front-end (since all 3 major compilers use the same front-end).

On 11/7/13, Andrej Mitrovic <andrej.mitrovich@gmail.com> wrote:
> Hmm, I have the same issue. It might be an issue with the port.

I did some profiling. I had some excessive opengl error check calls, which I've fixed in git-head. And I was wrong about -O not working, it works but it takes ~1-2 minutes to compile.

Anyway in -release -inline -O -noboundscheck mode the sample now works perfectly smooth! In debug mode it's a little slow, but this is expected as the C++ sample also lags a lot in debug mode.

What's really interesting is that DMD beats VC in debug mode, but maybe this has something to do with debug information that VC includes in a debug build (perhaps profiling hooks? who knows..)

On 11/8/13, Andrej Mitrovic <andrej.mitrovich@gmail.com> wrote:
> Anyway in -release -inline -O -noboundscheck mode the sample now works perfectly smooth!

Well, as long as you use float and not double via -version=CHIP_USE_DOUBLES . Chipmunk actually uses doubles by default, although I'm not sure whether it uses reals for computations (more specifically, whether VC/C++ uses reals). So there's a difference there.

> I did not refactor, it's a straight port.
Could you say how much code lines can be approximately saved after porting with refactoring?

On Friday, 8 November 2013 at 05:04:45 UTC, Suliman wrote:
>> I did not refactor, it's a straight port.
> Could you say how much code lines can be approximately saved after porting with refactoring?

This question doesn't make much sense. I guess one could write the same thing from scratch in D in half the LOC. But a reduced line count wouldn't be the only benefit, a more maintainable and safer codebase would be other benefits.

On Friday, 8 November 2013 at 04:39:11 UTC, Andrej Mitrovic wrote:
> On 11/8/13, Andrej Mitrovic <andrej.mitrovich@gmail.com> wrote:
>> Anyway in -release -inline -O -noboundscheck mode the sample now works
>> perfectly smooth!
>
> Well, as long as you use float and not double via
> -version=CHIP_USE_DOUBLES . Chipmunk actually uses doubles by default,
> although I'm not sure whether it uses reals for computations (more
> specifically, whether VC/C++ uses reals). So there's a difference
> there.

I've done some experiments regarding dmd/ldc comparison.

Machine: Ubuntu 12.04 (x86_64), Intel® Core™ i5-3470 CPU @ 3.20GHz × 4
Compilers: DMD64 D Compiler v2.064, LDC - the LLVM D compiler (0.12.0):
  based on DMD v2.063.2 and LLVM 3.3.1
  Default target: x86_64-unknown-linux-gnu
  Host CPU: core-avx-i

I've made 2 builds:
$ dub --build=release
$ dub --build=release --compiler=ldc2

And 2 runs of
new_demo -bench -trial
(note, I've modified the source to make both keys usable simultaneously)
It runs a 1000 iteration for every demo in 'bench' set and prints it's time in ms.

DMD output:
5105.89
2451.94
477.079
12709.9
4259.14
775.686
8842.77
4233.86
784.804
939.7
1643.85
1589.28
5368.47
11042.3
380.893
740.671
9.53658

LDC output:
4645.74
2236.77
434.833
10483.6
3577.5
693.307
7339.49
3445.02
627.396
856.486
1291.23
1333.11
4831.46
9002.18
361.624
605.19
9.64545

So, the ratio is something like 0.81-0.83 in favor of ldc.

On 11/11/13, Sergei Nosov <sergei.nosov@gmail.com> wrote:
> I've done some experiments regarding dmd/ldc comparison.
>
> Machine: Ubuntu 12.04 (x86_64), Intel® Core™ i5-3470 CPU @
> 3.20GHz × 4
> Compilers: DMD64 D Compiler v2.064, LDC - the LLVM D compiler
> (0.12.0):
>    based on DMD v2.063.2 and LLVM 3.3.1
>    Default target: x86_64-unknown-linux-gnu
>    Host CPU: core-avx-i
>
> I've made 2 builds:
> $ dub --build=release
> $ dub --build=release --compiler=ldc2

Which flags does release imply?

> So, the ratio is something like 0.81-0.83 in favor of ldc.

Cool! Thanks for benchmarking.

On Monday, 11 November 2013 at 15:29:20 UTC, Andrej Mitrovic wrote:
> On 11/11/13, Sergei Nosov <sergei.nosov@gmail.com> wrote:
>> I've done some experiments regarding dmd/ldc comparison.
>>
>> Machine: Ubuntu 12.04 (x86_64), Intel® Core™ i5-3470 CPU @
>> 3.20GHz × 4
>> Compilers: DMD64 D Compiler v2.064, LDC - the LLVM D compiler
>> (0.12.0):
>>    based on DMD v2.063.2 and LLVM 3.3.1
>>    Default target: x86_64-unknown-linux-gnu
>>    Host CPU: core-avx-i
>>
>> I've made 2 builds:
>> $ dub --build=release
>> $ dub --build=release --compiler=ldc2
>
> Which flags does release imply?

In my version of dub it's "-release -inline -O". I've tried also adding the -noboundscheck flag and it yielded the same results. I guess the setup for ldc is similar.