July 13, 2011
> 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
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
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
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
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
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
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
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
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
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.
1 2 3 4 5 6 7 8
Next ›   Last »