View mode: basic / threaded / horizontal-split · Log in · Help
July 13, 2011
Re: dmd 1.069 and 2.054 release
> Looks like it fails to build under Linux using linux.mak makefile due to  
> missing
> intrange.c / intrange.o in file lists. Linking stage errors. When I add  
> them
> manually, everything works like a charm.

I think compiling it worked just fine for me.
July 13, 2011
Re: dmd 1.069 and 2.054 release
On 7/13/2011 9:58 AM, &#1052 wrote:
> Looks like it fails to build under Linux using linux.mak makefile due to missing
> intrange.c / intrange.o in file lists. Linking stage errors. When I add them
> manually, everything works like a charm.
> Could this one be fixed?

Use posix.mak for the linux builds now.
July 13, 2011
Re: dmd 1.069 and 2.054 release
Damn, I am getting some impressive results comparing VC C++ builds and
DMD D builds. I'm using the PortAudio library and a stress-test that
comes with the project. It tries to generate as many sinewaves as
possible until some maximum is reached. The PortAudio C DLL library is
built in release mode, and is then implicitly linked with a C or D
project. Here's the results:

Stops on 500 max sines, or 0.80 max cpu.

C debug:
numSines = 229, CPU load = 0.802464  // cpu max reached

C release:
numSines = 500, CPU load = 0.793717  // max sines reached

D debug:
numSines = 258, CPU load = 0.800412  // cpu max reached

D release:
numSines = 500, CPU load = 0.629622  // max sines reached


Notice how the C version barely made it to 500 sines in release mode
(almost hit 0.80 CPU), but the D version had plenty of free CPU left
(this is all done on a single core).

I've enabled debug symbols and explicitly enabled floating-point
exceptions in debug builds in the realtime-priority callback function,
via:
   version (Debug)
   {
       import std.math;
       FloatingPointControl fpc;
       fpc.enableExceptions(FloatingPointControl.severeExceptions);
   }

and that still beats C's debug build by a small margin. There were 3
function macros which I've converted to auto templates, I think those
got inlined in release mode. I'm using exceptions in the D version
compared to C's use of goto's.

Here's the C version code: http://codepad.org/4ERFVcSS
And the D version: http://codepad.org/a7XL8wNW

D debug switches (I had to use Debug instead of debug due to a
critical bug): -g -version=Debug
D release switches: -release -inline -O -noboundscheck

Anyway if you want to try it yourself (Windows only for now), do:
git clone https://github.com/AndrejMitrovic/DPortAudio

cd and run \portaudio\build.bat
cd and run \samples\build.bat

The C examples are in the PortAudio project and if you want to compare
with those you'll have to build them yourself.
July 13, 2011
Re: dmd 1.069 and 2.054 release
Is this really that much impressive considering the fact that you 
compare results where the most work is done in the linked DLL itself no 
matter what code calls it, whether it is D or C, Debug or Release ??

On 14.07.2011 00:26, Andrej Mitrovic wrote:
> Damn, I am getting some impressive results comparing VC C++ builds and
> DMD D builds. I'm using the PortAudio library and a stress-test that
> comes with the project. It tries to generate as many sinewaves as
> possible until some maximum is reached. The PortAudio C DLL library is
> built in release mode, and is then implicitly linked with a C or D
> project. Here's the results:
>
> Stops on 500 max sines, or 0.80 max cpu.
>
> C debug:
> numSines = 229, CPU load = 0.802464  // cpu max reached
>
> C release:
> numSines = 500, CPU load = 0.793717  // max sines reached
>
> D debug:
> numSines = 258, CPU load = 0.800412  // cpu max reached
>
> D release:
> numSines = 500, CPU load = 0.629622  // max sines reached
>
>
> Notice how the C version barely made it to 500 sines in release mode
> (almost hit 0.80 CPU), but the D version had plenty of free CPU left
> (this is all done on a single core).
>
> I've enabled debug symbols and explicitly enabled floating-point
> exceptions in debug builds in the realtime-priority callback function,
> via:
>      version (Debug)
>      {
>          import std.math;
>          FloatingPointControl fpc;
>          fpc.enableExceptions(FloatingPointControl.severeExceptions);
>      }
>
> and that still beats C's debug build by a small margin. There were 3
> function macros which I've converted to auto templates, I think those
> got inlined in release mode. I'm using exceptions in the D version
> compared to C's use of goto's.
>
> Here's the C version code: http://codepad.org/4ERFVcSS
> And the D version: http://codepad.org/a7XL8wNW
>
> D debug switches (I had to use Debug instead of debug due to a
> critical bug): -g -version=Debug
> D release switches: -release -inline -O -noboundscheck
>
> Anyway if you want to try it yourself (Windows only for now), do:
> git clone https://github.com/AndrejMitrovic/DPortAudio
>
> cd and run \portaudio\build.bat
> cd and run \samples\build.bat
>
> The C examples are in the PortAudio project and if you want to compare
> with those you'll have to build them yourself.
July 13, 2011
Re: dmd 1.069 and 2.054 release
It's a simplistic test, I agree.

The work done in PortAudio is initalization and release of hardware,
and conversion of different sample rates and buffer sizes, and buffer
types, when necessary.

The Pa_GetStreamCpuLoad() call measures how long it takes for
patestCallback() to finish and based on that calculates the CPU usage.
July 14, 2011
Re: dmd 1.069 and 2.054 release
Is there any reason for linux.mak to still exist there then?
http://www.digitalmars.com/d/2.0/dmd-linux.html#compiling_dmd seems outdated then
and I really would like to get it right - maintaining dmd2 in Arch Linux User
Repository is my responsibility ( and I was using linux.mak till now ).
July 14, 2011
Re: dmd 1.069 and 2.054 release
On Thursday 14 July 2011 12:44:29 М и х а и 
л С т р а ш у н wrote:
> Is there any reason for linux.mak to still exist there then?
> http://www.digitalmars.com/d/2.0/dmd-linux.html#compiling_dmd seems outdated
> then and I really would like to get it right - maintaining dmd2 in Arch
> Linux User Repository is my responsibility ( and I was using linux.mak till
> now ).

It's not in github. I expect that it's a result of Walter not creating the zip 
file from scratch every time. So, it was cruft that didn't get cleaned out.

- Jonathan M Davis
July 20, 2011
Re: dmd 1.069 and 2.054 release
Walter Bright wrote:
> Continuing the trend, more people contributed to this release than any 
> other!
> 
> http://www.digitalmars.com/d/1.0/changelog.html
> http://ftp.digitalmars.com/dmd.1.069.zip
> 
> http://www.digitalmars.com/d/2.0/changelog.html
> http://ftp.digitalmars.com/dmd.2.054.zip

The new CTFE docs got left out somehow.
July 20, 2011
Re: dmd 1.069 and 2.054 release
On 7/20/2011 2:29 PM, Don wrote:
> The new CTFE docs got left out somehow.

Not sure what you're referring to?
July 21, 2011
Re: dmd 1.069 and 2.054 release
Walter Bright wrote:
> On 7/20/2011 2:29 PM, Don wrote:
>> The new CTFE docs got left out somehow.
> 
> Not sure what you're referring to?

Sorry, it seems something went wrong with my repository. When I pushed, 
it didn't push to anything...
I'll redo it.
Next ›   Last »
4 5 6 7 8
Top | Discussion index | About this forum | D home