View mode: basic / threaded / horizontal-split · Log in · Help
March 21, 2012
Re: Three Unlikely Successful Features of D
On 3/20/12, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
> What are your faves? I have a few in mind, but wouldn't want to
> influence answers.

Hey here's a big one: Phobos. Or maybe both Phobos and D2. I don't
have the numbers but I think quite a few people thought D was going to
die because of a backwards-incompatible change of a language, and the
fact that Tango was missing from D2 (it seems people avoided using
Phobos in D1 days).
March 21, 2012
Re: Three Unlikely Successful Features of D
On Mar 20, 2012, at 10:54 PM, Brad Anderson wrote:
> 
> It's probably far too early to think about this with all the other important issues you're addressing but have you given much thought to improving the hashing function?  I haven't hit any issues with the speed of the current hasher but better performance is always welcome. MurmurHash seems to be all the rage these days with a lot of languages and systems adopting it <http://en.wikipedia.org/wiki/MurmurHash> (it compiles down to ~52 instructions on x86). It'd be interesting to see benchmarks with it. I'm not sure where the current hashing function lives to see what it's like.

Druntime actually did use MurmurHash for a while and then dropped it because the site had no copyright license for the code (a mistake that has since been rectified).  I'd consider switching back, though I don't really like that MurmurHash has a number of separate implementations targeted at different platforms, each having different performance characteristics.  It's 4x faster than SuperFastHash on x86 but 10x slower than SuperFastHash on SPARC, for example.
March 21, 2012
Re: Three Unlikely Successful Features of D
On 21.03.2012 18:14, Walter Bright wrote:
> On 3/21/2012 8:21 AM, Don Clugston wrote:
>> On 21/03/12 03:47, Walter Bright wrote:
>>> And now x is an instance of a voldemort type! It's completely
>>> encapsulated.
>>
>> That idiom is already built into the language. Anonymous nested
>> classes don't
>> have a name at all.
>>
>> auto x = new class { ... }
>>
>
> True, but it's the ability to return them from a function that's new &
> cool!
>
> (Yes, I know you can return x as type "Object".)

BTW what is 'nested' about anonymous nested classes? They seem to work 
anywhere! Can we just drop that from the name?
March 21, 2012
Re: Three Unlikely Successful Features of D
"Sean Kelly" <sean@invisibleduck.org> wrote in message 
news:mailman.981.1332359368.4860.digitalmars-d@puremagic.com...
>
>Druntime actually did use MurmurHash for a while and
>then dropped it because the site had no copyright license
>for the code (a mistake that has since been rectified).  I'd
>consider switching back, though I don't really like that
>MurmurHash has a number of separate implementations
>targeted at different platforms, each having different
>performance characteristics.  It's 4x faster than SuperFastHash
>on x86 but 10x slower than SuperFastHash on SPARC,
>for example.=

People still use SPARC?

/me out of the loop
March 21, 2012
Re: Three Unlikely Successful Features of D
On 03/21/2012 09:00 PM, Don wrote:
>
> BTW what is 'nested' about anonymous nested classes? They seem to work
> anywhere! Can we just drop that from the name?
>

Seems reasonable.

BTW: They don't work in a typeof expression:
http://d.puremagic.com/issues/show_bug.cgi?id=7104
March 21, 2012
Re: Three Unlikely Successful Features of D
On 2012-03-21 18:20, Walter Bright wrote:

> I knew import would be good :-)
>
> It's because I've used languages before with an import, and as a
> compiler guy, I knew what a kludge #include is. The preprocessor in
> C/C++ is a crutch to make up for deficiencies in the language.

I've never been able to properly handle includes in C/C++. Import is SO 
much better.

-- 
/Jacob Carlborg
March 21, 2012
Re: Three Unlikely Successful Features of D
On Wednesday, 21 March 2012 at 17:20:28 UTC, Walter Bright wrote:
> On 3/21/2012 7:23 AM, Adam D. Ruppe wrote:
>> But, is import unlikely success, or is this just a
>> leftover feeling from my massive bias in the early
>> days? I have to say it is my bias, since everyone
>> else uses import and they all know it is good.
>
> I knew import would be good :-)
>
> It's because I've used languages before with an import, and as 
> a compiler guy, I knew what a kludge #include is. The 
> preprocessor in C/C++ is a crutch to make up for deficiencies 
> in the language.

On the topic of import, mixin imports are something that I 
believe will eventually become a great deal more popular than 
they are today. First, there's the advantage of being able to use 
a language/syntax more appropriate for the task at hand. For 
example, for things that output html you could just import mixin 
a raw html file. But the real advantage is that you can still do 
compile-time processing on this. Plug in an xml parser, or 
something like pegged, and you can now extend Html and generate D 
code for it. For example, if you have something like 
runat="server" on an element, just like in ASP.net you could 
create a serverside element for this and manipulate it. Because 
you know exactly which parts are static and which are dynamic, 
you could (at compile time) create buffers containing the static 
portions to prevent having to copy things many times. Unlike 
other languages, there would be no performance hit to doing this 
because it's all done at compile time. This is just one example. 
Another one would be automatically creating bindings for a 
scripting language, or even automatically creating bindings for a 
C header file.
March 21, 2012
Re: Three Unlikely Successful Features of D
On 2012-03-21 20:49, Sean Kelly wrote:

> Druntime actually did use MurmurHash for a while and then dropped it because the site had no copyright license for the code (a mistake that has since been rectified).  I'd consider switching back, though I don't really like that MurmurHash has a number of separate implementations targeted at different platforms, each having different performance characteristics.  It's 4x faster than SuperFastHash on x86 but 10x slower than SuperFastHash on SPARC, for example.

Would it be possible to use different algorithms on different platforms?

-- 
/Jacob Carlborg
March 21, 2012
Re: Three Unlikely Successful Features of D
On Wednesday, March 21, 2012 22:18:16 Jacob Carlborg wrote:
> On 2012-03-21 20:49, Sean Kelly wrote:
> > Druntime actually did use MurmurHash for a while and then dropped it
> > because the site had no copyright license for the code (a mistake that
> > has since been rectified). I'd consider switching back, though I don't
> > really like that MurmurHash has a number of separate implementations
> > targeted at different platforms, each having different performance
> > characteristics. It's 4x faster than SuperFastHash on x86 but 10x slower
> > than SuperFastHash on SPARC, for example.
>
> Would it be possible to use different algorithms on different platforms?

I'm sure that it would be, but it sounds like part of his complaint is that 
you end up with different implementations per platform with using MurmurHash, 
and using a different hash algorithm per architecture is just as bad in that 
respect. If you're trying to absolutely maximize performance though, that 
would probably be the way to go if there isn't one which is a clear winner on 
all architectures. It doesn't matter all that much for dmd at present though, 
since it's x86-only.

- Jonathan M Davis
March 21, 2012
Re: Three Unlikely Successful Features of D
Kapps wrote:
> or even automatically creating bindings for a C header file.

I've thought about that before. It would be great to have fully 
automatic linking to C libs. You could even have a cache system 
that stores .di files and only regenerates them if the .h file 
was modified.
4 5 6 7 8 9 10 11
Top | Discussion index | About this forum | D home