Re: Slow performance compared to C++, ideas?

On 05/31/2013 06:29 AM, Juan Manuel Cabo wrote: I just shaved 1.2 seconds trying with dmd by changing the dot function from: Yep, using -profile on the original code shows that 33% is spend in Sphere.intersect. And the asm for the dot product is horrible.

Re: Slow performance compared to C++, ideas?

On 06/01/2013 08:22 PM, Walter Bright wrote:> On 5/30/2013 7:56 PM, Andrei Alexandrescu wrote: >> On 5/30/13 9:26 PM, finalpatch wrote: >>> https://dl.dropboxusercontent.com/u/974356/raytracer.d >>> https://dl.dropboxusercontent.com/u/974356/raytracer.cpp >> >> Manu's gonna love this one: make al

Re: Runtime reflection idea

Am 02.06.2013 15:28, schrieb Rainer Schuetze: On 02.06.2013 11:33, Benjamin Thaut wrote: I think this is a very good idea. The only question is how complete this RTTI should be. This again highly depends on what it will be used for. For some users it might be ok to do a full RTTI, which will i

Re: A Small Contribution to Phobos

On 6/2/13 11:41 AM, monarch_dodra wrote: On Sunday, 2 June 2013 at 13:07:18 UTC, Andrei Alexandrescu wrote: [1, 2, 3, 4].map!(n => n.writeln).reduce; Andrei One of the problems with using "map" for something such as this, is that the resulting object is not a range, since "front" now returns

Re: Labels as values and threaded-code interpretation

On 02-06-2013 10:52, Dmitry Olshansky wrote: 01-Jun-2013 20:13, Timon Gehr пишет: On 06/01/2013 07:29 AM, Alex Rønne Petersen wrote: Hi, I'm sure this has been brought up before, but I feel I need to bring it up again (because I'm going to be writing a threaded-code interpreter): http://gcc.gn

Re: Labels as values and threaded-code interpretation

On 02-06-2013 08:44, Paulo Pinto wrote: Am 02.06.2013 06:49, schrieb Walter Bright: On 6/1/2013 7:35 PM, Alex Rønne Petersen wrote: On 01-06-2013 09:59, bearophile wrote: "Recently" the Python C interpreter was modified and speed up thanks to this non-standard feature. CPython source code has

Re: Slow performance compared to C++, ideas?

On 06/02/2013 05:53 PM, Roy Obena wrote: > You're making this up. I'm sure they do a lot of data-driven > tests or simulations that make most errors detectable. They may > not be savvy programmers, and their programs may not be > error-free, but boat-loads of errors? C'mon. I don't think he's maki

Re: Slow performance compared to C++, ideas?

On 6/2/13 12:16 PM, John Colvin wrote: A lot of HPC scientific code is, at best, horribly fragile. Reminds me of that internal joke at www.llnl.gov. "If we make a mistake, millions of people will live." True story. Andrei

Re: A Small Contribution to Phobos

On Sunday, 2 June 2013 at 13:07:18 UTC, Andrei Alexandrescu wrote: On 6/2/13 1:58 AM, Meta wrote: For reference type ranges and input ranges which are not forward ranges, this will consume the range and return nothing. I originally wrote it to accept forward ranges and use save, but I wanted

Re: Slow performance compared to C++, ideas?

On 6/2/13 9:59 AM, Manu wrote: I've never said that virtuals are bad. The key function of a class is polymorphism. But the reality is that in non-tool or container/foundational classes (which are typically write-once, use-lots; you don't tend to write these daily), a typical class will have a cou

Re: A Small Contribution to Phobos

On 6/2/13 9:20 AM, bearophile wrote: Andrei Alexandrescu: [1, 2, 3, 4].map!(n => n.writeln).reduce; I have to shot this down for many reasons: I think it's better to give that final function a different name (like "consume" or something like that) because it's used for very different purpose

Re: Slow performance compared to C++, ideas?

On Sunday, 2 June 2013 at 15:53:58 UTC, Roy Obena wrote: On Sunday, 2 June 2013 at 14:34:43 UTC, Manu wrote: On 2 June 2013 21:46, Joseph Rushton Wakeling Well this is another classic point actually. I've been asked by my friends at Cambridge to give their code a once-over for them on many o

Re: Slow performance compared to C++, ideas?

On Sunday, 2 June 2013 at 15:59:38 UTC, Joseph Rushton Wakeling wrote: GDC and LDC both have their own equivalent flags -- for GDC it's -finline-functions (which as Iain says is already covered by -O3), for LDC it's -enable-inlining. It probably won't make any difference for LDC either with -O

Re: Slow performance compared to C++, ideas?

On 06/02/2013 02:26 PM, finalpatch wrote: > IIRC -inline is a DMD specific switch. Adding this to gdc command line > produces this: > > gdc.exe: error: unrecognized command line option '-inline' GDC and LDC both have their own equivalent flags -- for GDC it's -finline-functions (which as Iain say

Re: Slow performance compared to C++, ideas?

On Sunday, 2 June 2013 at 14:34:43 UTC, Manu wrote: On 2 June 2013 21:46, Joseph Rushton Wakeling Well this is another classic point actually. I've been asked by my friends at Cambridge to give their code a once-over for them on many occasions, and while I may not understand exactly what thei

Re: A Small Contribution to Phobos

On Sunday, 2 June 2013 at 13:07:18 UTC, Andrei Alexandrescu wrote: On 6/2/13 1:58 AM, Meta wrote: For reference type ranges and input ranges which are not forward ranges, this will consume the range and return nothing. I originally wrote it to accept forward ranges and use save, but I wanted

Re: Runtime reflection idea

On Sunday, 2 June 2013 at 13:28:28 UTC, Rainer Schuetze wrote: and TypeInfo.rtInfo() would then return a pointer to RTInfoData instead of void*. This doesn't make it modifiable from outside object.di, but I have no idea how that could be possible to begin with (without recompiling the runtime l

Re: A Small Contribution to Phobos

I think consuming all of a range evaluating front and doing nothing should be the role of reduce with only one parameter (the range). That overload would take the range to be "exhausted" and return void. Thus your example becomes: Maybe, then, it would be best to have a template that calls re

Re: The non allocating D subset

W dniu 01.06.2013 07:45, SomeDude pisze: Following this idea, I believe a fairly large chunk of Phobos could be ported to compile with this minimal D sublanguage, and that one could use the allocating D and its added sugar on top of it. So in the end, the user could decide between working with th

Re: Runtime reflection idea

On Sunday, 2 June 2013 at 09:33:27 UTC, Benjamin Thaut wrote: I think this is a very good idea. The only question is how complete this RTTI should be. For now, I'm going for just a UDA based thing, so it is almost all opt-in. Though one downside of my idea here is it may be slow, since it pul

Re: The non allocating D subset

This is super-interesting research! Lessons learned here should attempt to be rolled back into the main compiler/libs if they are applicable. This sort of work is what may open D up to ' proper embedded' usage. I'd really like to see escape analysis and lowering of small dynamic arrays onto the st

Re: The non allocating D subset

On Sunday, 2 June 2013 at 14:32:56 UTC, Adam D. Ruppe wrote: So I tried to get moduleinfo looping working and found some success. If you use it with libc, it works. On bare metal, it works thanks to a linker script hack. It doesn't work on the minimal linux setup. I wasted a lot of hours tr

Re: The non allocating D subset

So I tried to get moduleinfo looping working and found some success. If you use it with libc, it works. On bare metal, it works thanks to a linker script hack. It doesn't work on the minimal linux setup. I wasted a lot of hours trying to do it, but there seems to be some elf section magic g

Re: Slow performance compared to C++, ideas?

On 2 June 2013 21:46, Joseph Rushton Wakeling wrote: > On 06/02/2013 08:33 AM, Manu wrote: > > Most of these guys are mathematicians and physicists first, and > programmers second. > > You've hit the nail on the head, but it's also a question of priorities. > It's > _essential_ that the maths or

Re: Arch AUR DMD missing?

On Sunday, 2 June 2013 at 14:04:51 UTC, simendsjo wrote: What happened to the DMD package in Arch AUR? New name or something? Does anyone have a link to the package? It's in [community] now: https://www.archlinux.org/packages/?sort=&q=dmd&maintainer=&flagged=

Re: Slow performance compared to C++, ideas?

On 2 June 2013 20:16, Jonathan M Davis wrote: > On Sunday, June 02, 2013 11:53:26 Jacob Carlborg wrote: > > On 2013-06-01 23:08, Jonathan M Davis wrote: > > > If you don't need polymorphism, then in general, you shouldn't use a > class > > > (though sometimes it might make sense simply because it

Arch AUR DMD missing?

What happened to the DMD package in Arch AUR? New name or something? Does anyone have a link to the package?

Re: Slow performance compared to C++, ideas?

On 2 June 2013 19:53, Jacob Carlborg wrote: > On 2013-06-01 23:08, Jonathan M Davis wrote: > > If you don't need polymorphism, then in general, you shouldn't use a class >> (though sometimes it might make sense simply because it's an easy way to >> get a >> reference type). Where it becomes more

Re: Error after installing DMD v2.063

I've just run: sudo ln -s /usr/lib/x86_64-linux-gnu/libphobos2.so /usr/lib/x86_64-linux-gnu/libphobos2.so.0.63 for now but i've never had to do that before. Is this a problem with the installer?

Re: Runtime reflection idea

On 02.06.2013 11:33, Benjamin Thaut wrote: I think this is a very good idea. The only question is how complete this RTTI should be. This again highly depends on what it will be used for. For some users it might be ok to do a full RTTI, which will increase the executable size significantly. Othe

Re: A Small Contribution to Phobos

Andrei Alexandrescu: [1, 2, 3, 4].map!(n => n.writeln).reduce; I have to shot this down for many reasons: I think it's better to give that final function a different name (like "consume" or something like that) because it's used for very different purposes and it returns nothing. Re-using t

Re: Slow performance compared to C++, ideas?

But avoiding heap allocations for array literals is a change that needs to be discussed. In the meantime I have written a small ER regarding escape analysis for dynamic arrays: http://d.puremagic.com/issues/show_bug.cgi?id=10242 Bye, bearophile

Re: A Small Contribution to Phobos

On 6/2/13 1:58 AM, Meta wrote: For reference type ranges and input ranges which are not forward ranges, this will consume the range and return nothing. I originally wrote it to accept forward ranges and use save, but I wanted to make it as inclusive as possible. I guess I overlooked the case of

Error after installing DMD v2.063

Hi, I get the following error while running a simple hello world program compiled with the new v2.063 compiler. This is on Ubuntu 12.04. error while loading shared libraries: libphobos2.so.0.63: cannot open shared object file: No such file or directory

Re: Slow performance compared to C++, ideas?

Joseph, IIRC -inline is a DMD specific switch. Adding this to gdc command line produces this: gdc.exe: error: unrecognized command line option '-inline' Besides, the improvements mainly come from unrolling short loops not from inlining. Joseph Rushton Wakeling writes: > On 06/02/2013 11:32 AM

Re: A Small Contribution to Phobos

Meta: perform is pretty badly named, but I couldn't come up with a better one. It can be inserted in a UFCS chain and perform some operation with side-effects. It doesn't alter its argument, just returns it for the next function in the chain. T perform(alias dg, T)(ref T val) { dg();

Re: Slow performance compared to C++, ideas?

Am 02.06.2013 13:08, schrieb John Colvin: On Sunday, 2 June 2013 at 07:32:10 UTC, Manu wrote: On 2 June 2013 01:19, Paulo Pinto wrote: Am 01.06.2013 16:24, schrieb Benjamin Thaut: Am 01.06.2013 01:30, schrieb Manu: On 1 June 2013 09:15, bearophile mailto:bearophileHUGS@lycos.**com >> wro

Re: Slow performance compared to C++, ideas?

On 06/02/2013 08:33 AM, Manu wrote: > Most of these guys are mathematicians and physicists first, and programmers > second. You've hit the nail on the head, but it's also a question of priorities. It's _essential_ that the maths or physics be understood and done right. It's essential that the p

Re: Slow performance compared to C++, ideas?

On 2 June 2013 12:05, Joseph Rushton Wakeling wrote: > On 06/02/2013 11:32 AM, finalpatch wrote: >> The flags I used >> OSX LDC: -O3 -release >> WIN GDC: -O3 -fno-bounds-check -frelease > > Does adding -inline make a difference to initial performance (i.e. before your > manual interventions)? I g

Re: Slow performance compared to C++, ideas?

On Sunday, 2 June 2013 at 07:32:10 UTC, Manu wrote: On 2 June 2013 01:19, Paulo Pinto wrote: Am 01.06.2013 16:24, schrieb Benjamin Thaut: Am 01.06.2013 01:30, schrieb Manu: On 1 June 2013 09:15, bearophile > wrote: Manu: On 1 June 2013 0

Re: Slow performance compared to C++, ideas?

On 06/02/2013 11:32 AM, finalpatch wrote: > The flags I used > OSX LDC: -O3 -release > WIN GDC: -O3 -fno-bounds-check -frelease Does adding -inline make a difference to initial performance (i.e. before your manual interventions)? I guess it's already covered by -O3 in both cases, but a while bac

Re: Slow performance compared to C++, ideas?

On Sunday, June 02, 2013 11:53:26 Jacob Carlborg wrote: > On 2013-06-01 23:08, Jonathan M Davis wrote: > > If you don't need polymorphism, then in general, you shouldn't use a class > > (though sometimes it might make sense simply because it's an easy way to > > get a reference type). Where it beco

Re: Slow performance compared to C++, ideas?

On 2013-06-01 23:08, Jonathan M Davis wrote: If you don't need polymorphism, then in general, you shouldn't use a class (though sometimes it might make sense simply because it's an easy way to get a reference type). Where it becomes more of a problem is when you need a few polymorphic functions

Re: Labels as values and threaded-code interpretation

On 2 June 2013 17:25, Brad Roberts wrote: > On 6/1/13 9:49 PM, Walter Bright wrote: > >> On 6/1/2013 7:35 PM, Alex Rønne Petersen wrote: >> >>> On 01-06-2013 09:59, bearophile wrote: >>> "Recently" the Python C interpreter was modified and speed up thanks to this non-standard feature. C

Re: Slow performance compared to C++, ideas?

Hi Joseph, The flags I used OSX LDC: -O3 -release WIN GDC: -O3 -fno-bounds-check -frelease Joseph Rushton Wakeling writes: > On 06/01/2013 04:58 PM, finalpatch wrote: >> However I retested on a windows 7 machine with GDC compiler and the results >> were >> very different. >> >> orignal: 545m

Re: Runtime reflection idea

I think this is a very good idea. The only question is how complete this RTTI should be. This again highly depends on what it will be used for. For some users it might be ok to do a full RTTI, which will increase the executable size significantly. Other users might prefer a minimal RTTI or even

Re: Slow performance compared to C++, ideas?

On 06/01/2013 04:58 PM, finalpatch wrote: > However I retested on a windows 7 machine with GDC compiler and the results > were > very different. > > orignal: 545ms > * the first 2 optimizations which helped the most on OSX with LDC has almost > zero effect > * hand unroll overloaded vector arithm

Re: Labels as values and threaded-code interpretation

On Saturday, 1 June 2013 at 05:29:28 UTC, Alex Rønne Petersen wrote: Hi, I'm sure this has been brought up before, but I feel I need to bring it up again (because I'm going to be writing a threaded-code interpreter): http://gcc.gnu.org/onlinedocs/gcc/Labels-as-Values.html This is an incredi

Re: Labels as values and threaded-code interpretation

01-Jun-2013 20:13, Timon Gehr пишет: On 06/01/2013 07:29 AM, Alex Rønne Petersen wrote: Hi, I'm sure this has been brought up before, but I feel I need to bring it up again (because I'm going to be writing a threaded-code interpreter): http://gcc.gnu.org/onlinedocs/gcc/Labels-as-Values.html Th

Re: What exactly does "@safe" mean?

On Sunday, June 02, 2013 09:59:08 monarch_dodra wrote: > On Saturday, 1 June 2013 at 22:15:00 UTC, Jonathan M Davis wrote: > > On Saturday, June 01, 2013 23:41:32 monarch_dodra wrote: > >> Now, it was *my* fault for calling emplace with an already > >> built > >> object, but it was the (@trusted) e

Re: Slow performance compared to C++, ideas?

Am 02.06.2013 08:33, schrieb Manu: On 2 June 2013 01:19, Paulo Pinto mailto:pj...@progtools.org>> wrote: [...] At least when I did my traineeship at CERN (2003-2004) that was the case. I hope CERN has better software engineers than Cambridge University ;) Most of these guys are mathema

Re: DMD under 64-bit Windows 7 HOWTO

The last issue is the announcement that VS 2012 update 3 is the last one and developers will need to buy VS.Next for the remaining C++11 updates and the by side updates are actually not going to happen. I think they will start a new release circle of product, but compiler tools will remain

Re: Slow performance compared to C++, ideas?

On Friday, 31 May 2013 at 09:43:05 UTC, Manu wrote: - Require explicitly export when you want to create shared objects. This one is an enabler for an optimizer to finalize virtual method. With this mechanism in place, the compile knows all the override and can finalize many calls during LTO.

Re: What exactly does "@safe" mean?

On Saturday, 1 June 2013 at 22:15:00 UTC, Jonathan M Davis wrote: On Saturday, June 01, 2013 23:41:32 monarch_dodra wrote: OK. But by that standard, can't (mostly) anything be trusted? What about something that writes garbage, to a memory location it was *asked* to write to? Or if wrong usage

Re: Slow performance compared to C++, ideas?

On Saturday, 1 June 2013 at 21:14:43 UTC, Marco Leise wrote: Does it really change anything? Today people forget the final keyword and tomorrow they forget the virtual keyword? :D What you prefer here depends on what languages you are used to do (e.g. C++, Java), how much you use OOP for anythin

Re: Labels as values and threaded-code interpretation

On 6/2/13 12:33 AM, Paulo Pinto wrote: Am 02.06.2013 09:25, schrieb Brad Roberts: On 6/1/13 9:49 PM, Walter Bright wrote: On 6/1/2013 7:35 PM, Alex Rønne Petersen wrote: On 01-06-2013 09:59, bearophile wrote: "Recently" the Python C interpreter was modified and speed up thanks to this non-sta

Re: Labels as values and threaded-code interpretation

Am 02.06.2013 09:25, schrieb Brad Roberts: On 6/1/13 9:49 PM, Walter Bright wrote: On 6/1/2013 7:35 PM, Alex Rønne Petersen wrote: On 01-06-2013 09:59, bearophile wrote: "Recently" the Python C interpreter was modified and speed up thanks to this non-standard feature. CPython source code has t

Re: Slow performance compared to C++, ideas?

On 2 June 2013 01:19, Paulo Pinto wrote: > Am 01.06.2013 16:24, schrieb Benjamin Thaut: > > Am 01.06.2013 01:30, schrieb Manu: >> >>> On 1 June 2013 09:15, bearophile >> > wrote: >>> >>> Manu: >>> >>> On 1 June 2013 01:12, bearophile >>

Re: Labels as values and threaded-code interpretation

On 6/1/13 9:49 PM, Walter Bright wrote: On 6/1/2013 7:35 PM, Alex Rønne Petersen wrote: On 01-06-2013 09:59, bearophile wrote: "Recently" the Python C interpreter was modified and speed up thanks to this non-standard feature. CPython source code has two versions, one with computed gotos and one

Re: Labels as values and threaded-code interpretation

Am 02.06.2013 06:49, schrieb Walter Bright: On 6/1/2013 7:35 PM, Alex Rønne Petersen wrote: On 01-06-2013 09:59, bearophile wrote: "Recently" the Python C interpreter was modified and speed up thanks to this non-standard feature. CPython source code has two versions, one with computed gotos and

Re: A Small Contribution to Phobos

For reference type ranges and input ranges which are not forward ranges, this will consume the range and return nothing. I originally wrote it to accept forward ranges and use save, but I wanted to make it as inclusive as possible. I guess I overlooked the case of ref ranges. As for ranges th

Re: Why is D slower than LuaJIT?

Am Wed, 22 Dec 2010 17:04:21 -0500 schrieb 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: > > >auto L = iota(0.0, 1000.0); > >auto L2 = map!"a / 2"(L); > >auto L3 = map!"a

Re: A Small Contribution to Phobos

On Sunday, 2 June 2013 at 04:10:15 UTC, Jonathan M Davis wrote: On Sunday, June 02, 2013 04:57:53 Meta wrote: The callable bit won't work. It'll just call front. You'd have to do something like static if(isCallable!(ElementType!R)) r.front()(); Also, if front were pure, then calling it an

<    1   2