On Mar 21, 2012, at 2:18 PM, 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?

Depends whether there's any reason to have different platforms attempt to generate the same hash for a given input.

On Mar 21, 2012, at 1:24 PM, Nick Sabalausky wrote:

> "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

Yup.  Though these days it seems more common to use x86 Solaris instead, and even that subset is transitioning to Linux.

"Kapps" <opantm2+spam@gmail.com> wrote in message news:nnqtlpjqwdnzuwiqcycr@forum.dlang.org...
> 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.

Oh yea, definitely. I'm already using HTML mixin imports for the little bit of sever-side web stuff I've started playing around with in D.

"F i L" <witte2008@gmail.com> wrote in message news:sofbqiiyvragxjaxqbix@forum.dlang.org...
> 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.
>

That hits on the one irritating limitation of CTFE: No I/O. So that cache system would be a no-go right now.

On 2012-03-21 22:32, F i L wrote:
> 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.

I've been thinking on that as well since I'm writing a tool for converting header files. But I was thinking more of modifying the compiler and adding a new pragma that calls into my library.

-- 
/Jacob Carlborg

On Wednesday, 21 March 2012 at 21:38:16 UTC, Nick Sabalausky wrote:
> "F i L" <witte2008@gmail.com> wrote in message
> news:sofbqiiyvragxjaxqbix@forum.dlang.org...
>> 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.
>>
>
> That hits on the one irritating limitation of CTFE: No I/O. So that cache
> system would be a no-go right now.

Didn't realize that. Well until IO in CTFE is possible, converting a .h file into a .di file is still possible. Once that's done then it could just be wrapped up into a mixin cache system. D already has a tool to do this I believe (htod). Never used it though.

Le 21/03/2012 19:32, Andrei Alexandrescu a écrit :
> On 3/21/12 12:14 PM, F i L wrote:
>> And for my third favorite (in no order), I like custom
>> allocators/deallocators.
>
> They don't exist anymore.
>
> Andrei
>

And we are waiting for the replacement !

Jacob Carlborg wrote:
> But I was thinking more of modifying the compiler and adding a new pragma that calls into my library.

That would probably be a better option I think. In fact, eventually DMD could just have the cache system built in and the ability to import .h files just like .d ones. Now that would be pretty cool. All the .di cache files could be stored in ~/.dmd/ (or equivalent) or converted manually (dmd -CtoD file.h) for distribution.

On 03/21/2012 10:37 PM, Nick Sabalausky wrote:
> "F i L"<witte2008@gmail.com>  wrote in message
> news:sofbqiiyvragxjaxqbix@forum.dlang.org...
>> 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.
>>
>
> That hits on the one irritating limitation of CTFE: No I/O. So that cache
> system would be a no-go right now.
>
>

I once cached CTFE results by wrapping some templates into another template that would generate pragma(msg, ...) output that was then fitered out by an external d program and written to temporary files. On the next compilation run, the wrapper template would notice the existence of a suitable cache file and use its contents instead of starting the CTFE execution.

On Wed, Mar 21, 2012 at 10:18:16PM +0100, 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?
[...]

Should be as simple as adding version() to rt.util.hash.hashOf, I think. But I don't know if there may be potential issues with that.


T

-- 
If you want to solve a problem, you need to address its root cause, not just its symptoms. Otherwise it's like treating cancer with Tylenol...