Neal Becker wrote:
AFAIK both shared libraries and x86_64 code have been working
for years with GDC, even though that is not the case with DMD.
Phobos is still static, though.
But you can't link shared obj to static lib (Phobos), except on i386 - so
you really can't use shared obj on x86_64 (i
== Quote from Neal Becker (ndbeck...@gmail.com)'s article
> Anders F Björklund wrote:
> > Neal Becker wrote:
> >> Does this support building shared libs now (on x86_64)?
> >>
> > ...
> >>> I uploaded the packages to SourceForge, if anyone else
> >>> wants to try them... It's made for Fedora 14 (x86
== Quote from Iain Buclaw (ibuc...@ubuntu.com)'s article
> == Quote from Neal Becker (ndbeck...@gmail.com)'s article
> > Anders F Björklund wrote:
> > > Neal Becker wrote:
> > >> Does this support building shared libs now (on x86_64)?
> > >>
> > > ...
> > >>> I uploaded the packages to SourceForge,
On 21.12.2010 18:45, Bruno Medeiros wrote:
On 09/12/2010 21:55, Simon Buerger wrote:
From a pragmatic viewpoint you are right, copying containers is rare.
But on the other hand, classes imply a kind of identity, so that a set
is a different obejct then an other object with the very same elements
Iain Buclaw wrote:
AFAIK both shared libraries and x86_64 code have been working
for years with GDC, even though that is not the case with DMD.
But you can't link shared obj to static lib (Phobos), except on i386 - so
you really can't use shared obj on x86_64 (if you need phobos).
As far as
On Tue, 21 Dec 2010 17:16:57 -0500, Rob wrote:
Walter Bright wrote:
Michel Fortin wrote:
Exceptions are slow, that's a fact of life. The idea is that an
exception should be exceptional, so the case to optimize for is the
case where you don't have any exception: a try...catch that doesn't
thro
On Tue, 21 Dec 2010 17:25:09 -0500, Rob wrote:
Steven Schveighoffer wrote:
An exception is a recoverable error,
Not necessarily. At some point, all the handling options could have been
tried but all failed in which case there is nothing left to do except for
letting something higher up (lik
Mariusz GliwiÅski Wrote:
> Hello,
> Why don't You make htod opensource? I don't think it has commercial
> potential,
> or I'm wrong? I'm asking, because it's a shame that people who wants publish
> D
> bindings have to make their own scripts for that (so bindings can be
> generated
> on !wi
== Quote from Sean Kelly (s...@invisibleduck.org)'s article
> Mariusz Gliwiński Wrote:
> > Hello,
> > Why don't You make htod opensource? I don't think it has commercial
potential,
> > or I'm wrong? I'm asking, because it's a shame that people who wants publish
D
> > bindings have to make their own
On 22/12/2010 16:19, Sean Kelly wrote:
I hate to say it, but I've found that creating the D headers by hand is faster
than running htod and hand-editing to fix screw-ups. Particularly if there are
any #if statements to contend with.
Did you consider to use SWIG instead of htod ?
BLS Wrote:
> On 22/12/2010 16:19, Sean Kelly wrote:
> > I hate to say it, but I've found that creating the D headers by hand is
> > faster than running htod and hand-editing to fix screw-ups. Particularly
> > if there are any #if statements to contend with.
>
> Did you consider to use SWIG ins
Hello,
Is it possible use rdmd (to automagically link against imported D modules),
when also calling C funcs? I tried to add the C file at the end of the building
command, like eg (removed all dmd options):
rdmd --build-only -ofmyProg myProg.d myCFuncs.o
but rdmd does not seem to transmi
I agree with you.
We should ask a woman how she felt about that.
On 12/22/10 12:13 PM, spir wrote:
Hello,
Is it possible use rdmd (to automagically link against imported D modules),
when also calling C funcs? I tried to add the C file at the end of the building
command, like eg (removed all dmd options):
rdmd --build-only -ofmyProg myProg.d myCFuncs
== Quote from Anders F Björklund (a...@algonet.se)'s article
> Iain Buclaw wrote:
> >>> AFAIK both shared libraries and x86_64 code have been working
> >>> for years with GDC, even though that is not the case with DMD.
> >> But you can't link shared obj to static lib (Phobos), except on i386 - so
>
Steven Schveighoffer wrote:
> On Tue, 21 Dec 2010 17:16:57 -0500, Rob wrote:
>
>> Walter Bright wrote:
>>> Michel Fortin wrote:
Exceptions are slow, that's a fact of life. The idea is that an
exception should be exceptional, so the case to optimize for is the
case where you don't ha
Steven Schveighoffer wrote:
> On Tue, 21 Dec 2010 17:25:09 -0500, Rob wrote:
>
>> Steven Schveighoffer wrote:
>>
>>> An exception is a recoverable error,
>>
>> Not necessarily. At some point, all the handling options could have
>> been tried but all failed in which case there is nothing left to do
On 2010-12-21 22:58, Mariusz Gliwiński wrote:
Hello,
Why don't You make htod opensource? I don't think it has commercial potential,
or I'm wrong? I'm asking, because it's a shame that people who wants publish D
bindings have to make their own scripts for that (so bindings can be generated
on !win
On Wed, 22 Dec 2010 15:21:52 -0500, Rob wrote:
Steven Schveighoffer wrote:
On Tue, 21 Dec 2010 17:16:57 -0500, Rob wrote:
Walter Bright wrote:
Michel Fortin wrote:
Exceptions are slow, that's a fact of life. The idea is that an
exception should be exceptional, so the case to optimize for
Well, Clang can build binaries on Windows. AFAIK the only problem is
exceptions on Windows.
On 12/22/10, Jacob Carlborg wrote:
> On 2010-12-21 22:58, Mariusz Gliwiński wrote:
>> Hello,
>> Why don't You make htod opensource? I don't think it has commercial
>> potential,
>> or I'm wrong? I'm asking
While you're waiting I've assembled the code that I've written from
TDPL. It's not complete, and there's likely a bunch of typos here and
there. But it's better than nothing:
http://dl.dropbox.com/u/9218759/TDPL_Source%28unofficial.beta%29.zip
On 12/4/10, Andrei Alexandrescu wrote:
> On 12/4/1
"Don" wrote:
> It's not that complicated. Once you can load the library and call *one*
> function in it, the problem is solved.
> But at a deeper level, I'm not sure what you'd hope to achieve with this.
> I mean (excluding some not-yet implemented features), CTFE allows you to
> execute any pur
To see what performance advantage D would give me over using a scripting
language, I made a small benchmark. It consists of this code:
>auto L = iota(0.0, 1000.0);
>auto L2 = map!"a / 2"(L);
>auto L3 = map!"a + 2"(L2);
>auto V = reduce!"a + b"(L3);
It runs in 281 ms on my com
On 22/12/2010 19:11, Sean Kelly wrote:
BLS Wrote:
On 22/12/2010 16:19, Sean Kelly wrote:
I hate to say it, but I've found that creating the D headers by hand is faster
than running htod and hand-editing to fix screw-ups. Particularly if there are
any #if statements to contend with.
Did yo
Or is D, unlike I thought, not suitable for high performance computing?
What should I do?
LuaJIT seems to have a really good backend.
You better compare with ldc or gdc.
On Wed, 22 Dec 2010 17:04:21 -0500, Andreas Mayer wrote:
To see what performance advantage D would give me over using a scripting
language, I made a small benchmark. It consists of this code:
auto L = iota(0.0, 1000.0);
auto L2 = map!"a / 2"(L);
auto L3 = map!"a + 2"(L2);
au
On 22/12/2010 23:06, Steven Schveighoffer wrote:
(also, ensure you use -O -release -inline for the most optimized code).
quote...
// D version, with std.algorithm
// ~ 281 ms, using dmd 2.051 (dmd -O -release -inline)
Sometimes having a look at the source helps :)
Trass3r Wrote:
> LuaJIT seems to have a really good backend.
> You better compare with ldc or gdc.
Maybe someone could do that for me? I don't have ldc or gdc here. There are
some Debian packages, but they are D version 1 only?
Andreas Mayer Wrote:
> To see what performance advantage D would give me over using a scripting
> language, I made a small benchmark. It consists of this code:
>
> >auto L = iota(0.0, 1000.0);
> >auto L2 = map!"a / 2"(L);
> >auto L3 = map!"a + 2"(L2);
> >auto V = reduce!"a +
== Quote from Andreas Mayer (s...@bacon.eggs)'s article
> To see what performance advantage D would give me over using a scripting
language, I made a small benchmark. It consists of this code:
One corner case doesn't amount to an end-all be-all proof to anything.
> >auto L = iota(0.0, 100
On 22/12/2010 23:31, Gary Whatmore wrote:
Not intending to start a religious war but if your native code runs slower
than*JIT* code, you're doing something wrong. D will always beat JIT.
You talk like a prayer, don't you ? No need to measure. I believe ...
Anyway I don't care about LUA. The
Lua is a proven, robust language
Lua has been used in many industrial applications (e.g., Adobe's
Photoshop Lightroom), with an emphasis on embedded systems (e.g., the
Ginga middleware for digital TV in Brazil) and games (e.g., World of
Warcraft). Lua is currently the leading scripting language in
On Wed, 22 Dec 2010 17:04:21 -0500
Andreas Mayer wrote:
> To see what performance advantage D would give me over using a scripting
> language, I made a small benchmark. It consists of this code:
>
> >auto L = iota(0.0, 1000.0);
> >auto L2 = map!"a / 2"(L);
> >auto L3 = map!"a +
Ary Borenszweig Wrote:
> Lua is a proven, robust language
>
> Lua has been used in many industrial applications (e.g., Adobe's
> Photoshop Lightroom), with an emphasis on embedded systems (e.g., the
> Ginga middleware for digital TV in Brazil) and games (e.g., World of
> Warcraft). Lua is current
Steven Schveighoffer wrote:
> I would guess this has something to do with
> the lack of inlining for algorithmic functions.
Yeah, this is almost certainly the problem. I rewrote the
code using a traditional C style loop, no external functions,
and I'm getting roughly equal performance.
You said Lua is a joke language. It doesn't seem to be one...
Adam D. Ruppe Wrote:
> Steven Schveighoffer wrote:
> > I would guess this has something to do with
> > the lack of inlining for algorithmic functions.
>
> Yeah, this is almost certainly the problem. I rewrote the
> code using a traditional C style loop, no external functions,
> and I'm getting r
Ary Borenszweig Wrote:
> You said Lua is a joke language. It doesn't seem to be one...
Okay then, maybe it's not completely true. I meant it doesn't work in large
scale applications unlike a static systems programming language. Need to study
how extensively it's used in that game. I just tihkn
Gary Whatmore Wrote:
> Andreas Mayer Wrote:
>
> > To see what performance advantage D would give me over using a scripting
> > language, I made a small benchmark. It consists of this code:
> >
> > >auto L = iota(0.0, 1000.0);
> > >auto L2 = map!"a / 2"(L);
> > >auto L3 = map!"a
Andreas Mayer wrote:
Or is D, unlike I thought, not suitable for high performance computing? What
should I do?
I notice you are using doubles in D. dmd currently uses the x87 to evaluate
doubles, and on some processors the x87 is slow relative to using the XMM
instructions. Also, dmd's back
Walter Bright Wrote:
> I notice you are using doubles in D. dmd currently uses the x87 to evaluate
> doubles, and on some processors the x87 is slow relative to using the XMM
> instructions. Also, dmd's back end doesn't align the doubles on 16 byte
> boundaries, which can also slow down the flo
Walter Bright wrote:
Andreas Mayer wrote:
Or is D, unlike I thought, not suitable for high performance
computing? What
should I do?
I forgot to mention. In the D version, use integers as a loop counter, not
doubles.
Iain Buclaw Wrote:
> Another may be simply that there is a lot
> more going on behind the scenes than what you give credit for in D.
What else does it do? I want to add it to the Lua version.
Andreas Mayer:
> To see what performance advantage D would give me over using a scripting
> language, I made a small benchmark. It consists of this code:
I have done (and I am doing) many benchmarks with D, and I too have seen
similar results. I have discussed this topic two times in past, this
Andreas Mayer wrote:
I shouldn't use D now? How long until it is ready?
It depends on what you want to do. A lot of people are successfully using D.
loser:
> So is it justified enough to throw my W's incompetence card on the table at
> this point? How else it is possible that a simple scripting language with
> simple JIT optimization heuristics can outperform a performance oriented
> systems programming language.
It's not wise to premature
On Wed, 22 Dec 2010 18:26:33 -0500
Gary Whatmore wrote:
> Ary Borenszweig Wrote:
>
> > You said Lua is a joke language. It doesn't seem to be one...
>
> Okay then, maybe it's not completely true. I meant it doesn't work in large
> scale applications unlike a static systems programming language
On 12/22/10, Steven Schveighoffer wrote:
> Without any imperical testing, I would guess this has something to do with
> the lack of inlining for algorithmic functions. This is due primarily to
> uses of enforce, which use lazy parameters, which are currently not
> inlinable (also, ensure you use
On 12/22/2010 5:31 PM, Gary Whatmore wrote:
5) you were using old d runtime garbage collector. One fellow here made a
precise state of the art GC which beats even Java's 20 year old GC and C#.
Patch your dmd to use this instead.
Could you point me to more information? This sounds interesting
bearophile wrote:
Surely Lua looks like a far worse language regarding optimization
opportunities. But people around here (like you) must start to realize that
JIT compilation is not what it used to be. Today the JIT compilation done by
the JavaVM is able to perform de-virtualization, dynamic loo
Andrej Mitrovic wrote:
I have just tried removing enforce usage from Phobos and recompiling
the library, and compiling again with -O -release -inline. It doesn't
appear to make a difference in the timing speed over multiple runs.
Try looking at the obj2asm dump of the inner loop.
> I think you forget that I wrote on a Java compiler way back in the day
I remember it :-)
> dmd does cross-module inlining.
I didn't know this, much...
Bye,
bearophile
On 12/22/10 4:04 PM, Andreas Mayer wrote:
To see what performance advantage D would give me over using a scripting
language, I made a small benchmark. It consists of this code:
auto L = iota(0.0, 1000.0);
auto L2 = map!"a / 2"(L);
auto L3 = map!"a + 2"(L2);
auto V = reduce!
Andrei:
> As this test essentially measures the performance of
> iota and reduce, it would be hasty to generalize the assessment.
>From other tests I have seen that often FP-heavy code is faster with Lua-JIT
>than with D-DMD. But on average the speed difference is much less than 10
>times, ge
import std.stdio;
import std.demangle;
import std.traits;
void main()
{
void test()
{
}
auto mystr = mangledName!(test); // ---
demangle4mainFAAyaZv4testMFZv
writeln(demangle(mystr));// writes back
demangle4mainFAAyaZv4testMFZv
}
Also, the example cod
Okay, this works:
import std.stdio;
import std.demangle;
import std.traits;
void main()
{
void test()
{
}
auto mystr = "_D3std5stdio4File17LockingTextWriter11__T3putTAaZ3putMFAaZv";
writeln(demangle(mystr)); // void
std.stdio.File.LockingTextWriter.put!(char[]).put(char[])
}
It's really weird though, because I can only demangle a few names from
a .log file when using -profile with DMD. Is this normal?
std.demangle is moderately broken. Use core.demangle instead. I meant to have
std.demangle call core.demangle for this release, but forgot to make the change.
On 12/22/10 4:04 PM, Andreas Mayer wrote:
To see what performance advantage D would give me over using a scripting
language, I made a small benchmark. It consists of this code:
auto L = iota(0.0, 1000.0);
auto L2 = map!"a / 2"(L);
auto L3 = map!"a + 2"(L2);
auto V = reduce!
Nick Sabalausky wrote:
Sounds a bit Zen Buddhist or maybe Taoist to me.
Gravity - it's the law.
Wednesday 22 December 2010 @ 23:02:44 BLS:
> tried SWIG for C++ to D. But frankly said I am not able to offer
> substantial feedback 'cause every binding I have created was more or
> less in a toy area..
Thanks for answers everyone,
swig looks interesting. Again, it strips const so probably D1
Sean Kelly Wrote:
> std.demangle is moderately broken. Use core.demangle instead. I meant to
> have std.demangle call core.demangle for this release, but forgot to make the
> change.
Okay, I'm about to check in this change. With it, demangle works on the string
you supplied provided it's pr
On 12/23/10, Sean Kelly wrote:
> Okay, I'm about to check in this change. With it, demangle works on the
> string you supplied provided it's prefixed with "_D8" or "D8". Simply
> having "demangle4mainFAAyaZv4testMFZv" isn't a complete symbol.
>
Thanks. It works for _D3 as well. But not all of t
Please file a bug against druntime with any symbols that it can't handle.
If you know the symbol name it should decode to, that'd help.
On Thu, 23 Dec 2010, Andrej Mitrovic wrote:
> On 12/23/10, Sean Kelly wrote:
> > Okay, I'm about to check in this change. With it, demangle works on the
>
That's odd, I'm getting opposite results:
iota = 78ms
baseline = 187ms
Andreas' old code gives:
421ms
This is over multiple runs so I'm getting the average out of about 20 runs.
On 12/23/10, Andrei Alexandrescu wrote:
> On 12/22/10 4:04 PM, Andreas Mayer wrote:
>> To see what performance advan
Andrei Alexandrescu Wrote:
> Andreas, any chance you could run this on your machine and compare it
> with Lua? (I don't have Lua installed.) Thanks!
Your version: 40 ms (iota and baseline give the same timings)
LuaJIT with map calls removed: 21 ms
Interesting results.
On 12/22/10 11:06 PM, Andreas Mayer wrote:
Andrei Alexandrescu Wrote:
Andreas, any chance you could run this on your machine and compare it
with Lua? (I don't have Lua installed.) Thanks!
Your version: 40 ms (iota and baseline give the same timings)
LuaJIT with map calls removed: 21 ms
Inter
On Wed, 22 Dec 2010, Andrei Alexandrescu wrote:
> On 12/22/10 11:06 PM, Andreas Mayer wrote:
> > Andrei Alexandrescu Wrote:
> >
> > > Andreas, any chance you could run this on your machine and compare it
> > > with Lua? (I don't have Lua installed.) Thanks!
> >
> > Your version: 40 ms (iota and
"Andrei Alexandrescu" wrote in message
news:iethab$2dj...@digitalmars.com...
> On 12/22/10 12:13 PM, spir wrote:
>> Hello,
>>
>> Is it possible use rdmd (to automagically link against imported D
>> modules), when also calling C funcs? I tried to add the C file at the end
>> of the building comm
69 matches
Mail list logo
