www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - DConf 2013 Day 2 Talk 6: Higgs, an experimental JIT compiler written

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Reddit: 
http://www.reddit.com/r/programming/comments/1fv4zx/dconf_2013_day_2_talk_6_higgs_an_experimental_jit/

Hackernews: https://news.ycombinator.com/item?id=5839283

Twitter: https://twitter.com/D_Programming/status/343019685744369664

Facebook: http://facebook.com/dlang.org/posts/652988644714820

Youtube: http://youtube.com/watch?v=hJUNHX0vakI

Please drive discussions on the social channels, they help D a lot.


Andrei
Jun 07 2013
next sibling parent "Graham Fawcett" <fawcett uwindsor.ca> writes:
On Friday, 7 June 2013 at 15:05:15 UTC, Andrei Alexandrescu wrote:
 Reddit: 
 http://www.reddit.com/r/programming/comments/1fv4zx/dconf_2013_day_2_talk_6_higgs_an_experimental_jit/

 Hackernews: https://news.ycombinator.com/item?id=5839283

 Twitter: 
 https://twitter.com/D_Programming/status/343019685744369664

 Facebook: http://facebook.com/dlang.org/posts/652988644714820

 Youtube: http://youtube.com/watch?v=hJUNHX0vakI

 Please drive discussions on the social channels, they help D a 
 lot.


 Andrei
I've also cross-posted it to "/r/d_language": http://redd.it/1fv8y2 /r/programming is great for PR and engagement, but I like /r/d_language for its very high signal:noise (for one thing, it's easier to find past posts!). /r/d_language currently has 857 subscribers (http://stattit.com/r/d_language/). Looking forward to some growth there, as all these videos attract interested newcomers. Regards, Graham
Jun 07 2013
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Fri, 07 Jun 2013 11:05:14 -0400
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:

 Reddit: 
 http://www.reddit.com/r/programming/comments/1fv4zx/dconf_2013_day_2_talk_6_higgs_an_experimental_jit/
 
 Hackernews: https://news.ycombinator.com/item?id=5839283
 
 Twitter: https://twitter.com/D_Programming/status/343019685744369664
 
 Facebook: http://facebook.com/dlang.org/posts/652988644714820
 
 Youtube: http://youtube.com/watch?v=hJUNHX0vakI
 
 Please drive discussions on the social channels, they help D a lot.
 
 
 Andrei
Torrents up, and list of links updated: http://semitwist.com/download/misc/dconf2013/
Jun 07 2013
prev sibling next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:

 http://www.reddit.com/r/programming/comments/1fv4zx/dconf_2013_day_2_talk_6_higgs_an_experimental_jit/
A nice talk. Some comments on the slides: ------------------------ Slide 34:
 - If you know C++, you can write D code
 - Similar enough, easy adaptation
 - Slightly less verbose
If you write functional-style D code that uses UCFS a lot, the code is different from the usual C++ code and much shorter (and slower). ------------------------ Slide 53:
 Needed template with list of integer arguments
I agree that arrays as template arguments is a natural enhancement for D. ------------------------ Slide 57:
 Unit Tests Blocks
 - Don't support naming unit tests
 - Failing tests not reported at the end
 - The main function is still called normally
   Higgs starts a REPL by default
 - No way to select which tests are run
 - Tempted to write our own framework
I agree that in the built-in unittests some essential features are missing. ------------------------ Slide 58: static this() { codeGenFns[&SET_TRUE] = &gen_set_true; codeGenFns[&SET_FALSE] = &gen_set_false; codeGenFns[&SET_UNDEF] = &gen_set_undef; codeGenFns[&SET_MISSING] = &gen_set_missing; codeGenFns[&SET_NULL] = &gen_set_null; ... } ==> static this() { codeGenFns = [&SET_TRUE: &gen_set_true, &SET_FALSE: &gen_set_false, &SET_UNDEF: &gen_set_undef, &SET_MISSING: &gen_set_missing, &SET_NULL: &gen_set_null, ...]; } (That associative array can even be generated with a string mixin, if there's enough RAM). ------------------------ Slide 64:
 Precompile most library code used in CTFE
Where to put such compiled code? ------------------------ Slide 67: - D integer types have guaranteed sizes, but they're not obvious from the name - Why not have int8, uint8, int32, uint32, etc. in default namespace, encourage their use? I agree. It's hard to guess the size and signedness of types as byte, ubyte, wchar, dchar. I prefer names that are more clear. Bye, bearophile
Jun 08 2013
next sibling parent =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 06/08/2013 02:23 PM, bearophile wrote:

 Slide 67:

 - D integer types have guaranteed sizes, but
    they're not obvious from the name
 - Why not have int8, uint8, int32, uint32, etc. in
    default namespace, encourage their use?

 I agree. It's hard to guess the size and signedness of types as byte,
 ubyte, wchar, dchar. I prefer names that are more clear.
There is std.stdint but it is not used much: http://dlang.org/phobos/std_stdint.html Ali
Jun 08 2013
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/8/2013 2:23 PM, bearophile wrote:
 - D integer types have guaranteed sizes, but
    they're not obvious from the name
 - Why not have int8, uint8, int32, uint32, etc. in
    default namespace, encourage their use?

 I agree. It's hard to guess the size and signedness of types as byte, ubyte,
 wchar, dchar. I prefer names that are more clear.
It would only be a trivial problem for 5 minutes, only for ex-C/C++ programmers who are used to suffering under variable sized ints, and will never be a problem again. Is it really a problem to guess the size of 'byte'? Or that 'ubyte' is unsigned? Come on, bearophile! And frankly, int32, long64, etc., have a large 'yech' factor for me. Besides, if you really do want them, import core.stdc.stdint;
Jun 08 2013
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Walter Bright:

 It would only be a trivial problem for 5 minutes, only for 
 ex-C/C++ programmers who are used to suffering under variable 
 sized ints, and will never be a problem again.

 Is it really a problem to guess the size of 'byte'? Or that 
 'ubyte' is unsigned? Come on, bearophile!
The size of "byte" is easy, it's 1 byte, but if you ask me a byte is unsigned. I have learnt to be careful with byte/ubyte in D and now I think I don't use one for the other by mistake, but I have had some bugs caused by them. It took me two or three years to to remember what's the length of dchar and wchar. New D programmer should not be need to learn such arbitrary naming scheme, inherited from C++ :-)
 And frankly, int32, long64, etc., have a large 'yech' factor 
 for me.
I think you meant to say int32 and int64 :-) Bye, bearophile
Jun 08 2013
next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 6/9/13, bearophile <bearophileHUGS lycos.com> wrote:
 The size of "byte" is easy, it's 1 byte, but if you ask me a byte
 is unsigned. I have learnt to be careful with byte/ubyte in D
You, me, and Don, and probably others as well. It's easy to forget though that bytes are signed.
Jun 08 2013
parent Marco Leise <Marco.Leise gmx.de> writes:
Am Sun, 9 Jun 2013 01:53:23 +0200
schrieb Andrej Mitrovic <andrej.mitrovich gmail.com>:

 On 6/9/13, bearophile <bearophileHUGS lycos.com> wrote:
 The size of "byte" is easy, it's 1 byte, but if you ask me a byte
 is unsigned. I have learnt to be careful with byte/ubyte in D
You, me, and Don, and probably others as well. It's easy to forget though that bytes are signed.
I found the integer names and sizes intuitive from the beginning! And there was no confusion for me ever. It starts with a 'u', it is unsigned, signed otherwise. And the sizes are common in other programming languages, too. long being the only confusing one, but since int is already the 32-bit version it should be clear that it must be 64-bit. Though I can understand people who think of a byte as an unsigned type, I was much more confused by C's signed chars. Oh really? A character can be negative? Is this programming or sociology? -- Marco
Jun 08 2013
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 6/8/2013 4:08 PM, bearophile wrote:
 It took me two or three years to to remember what's the length of dchar and
wchar.
I don't believe that!
 New D programmer should not be need to learn such arbitrary naming scheme,
 inherited from C++ :-)
It's also seen in other obscure languages like Java and C#.
Jun 08 2013
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday, June 08, 2013 15:55:17 Walter Bright wrote:
 On 6/8/2013 2:23 PM, bearophile wrote:
 - D integer types have guaranteed sizes, but
 
    they're not obvious from the name
 
 - Why not have int8, uint8, int32, uint32, etc. in
 
    default namespace, encourage their use?
 
 I agree. It's hard to guess the size and signedness of types as byte,
 ubyte, wchar, dchar. I prefer names that are more clear.
It would only be a trivial problem for 5 minutes, only for ex-C/C++ programmers who are used to suffering under variable sized ints, and will never be a problem again. Is it really a problem to guess the size of 'byte'? Or that 'ubyte' is unsigned? Come on, bearophile! And frankly, int32, long64, etc., have a large 'yech' factor for me. Besides, if you really do want them, import core.stdc.stdint;
If I had been designing the language, I might have gone for int8, uint8, int16, uint16, etc. (in which case, _all_ of them would have had sizes with no aliases without - it seems overkill to me to have both), but I also don't think that it's a big deal for them to not have the numbers either, and I don't understand why anyone would think that it's all that hard to learn and remember what the various sizes are - especially when Java did something very close to what we did, and programmers seem to be fine with that. And the signed vs unsigned integers should be generally clear given that all of the integral types which are unsigned start with u and all those that don't, don't. The only exception is size_t which is already a bit of an oddity among the others, since its size can vary. So, while some people might find the sizes of the types to be a little confusing at first, I find it very hard to believe that anyone finds them to be confusing for long. It's all quite straightforward on the whole. - Jonathan M Davis
Jun 08 2013
prev sibling next sibling parent Peter Williams <pwil3058 bigpond.net.au> writes:
On 09/06/13 14:03, Jonathan M Davis wrote:
 If I had been designing the language, I might have gone for int8, uint8,
 int16, uint16, etc. (in which case, _all_ of them would have had sizes with no
 aliases without - it seems overkill to me to have both), but I also don't
 think that it's a big deal for them to not have the numbers either, and I
 don't understand why anyone would think that it's all that hard to learn and
 remember what the various sizes are
It's the ghost of problems past when the sizes many of the various integer/natural types in C were "implementation dependent". Maybe it only afflicts programmers over a certain age :-) Platform dependent macros such as int32 mapping to the appropriate type for the implementation were a mechanism for making code portable and old habits die hard. Peter PS the numbered int/uint versions would allow "short" and "long" to be removed from the set of keywords (eventually). PPS I think the numbering paradigm would be good for floating point types as well. The mathematician in me is unsettled by a digital type called "real" as real numbers can't be represented in digital form - only approximated. So, if it wasn't already too late, I'd go for float32, float64 and float80.
Jun 08 2013
prev sibling parent "Rob T" <alanb ucora.com> writes:
On Saturday, 8 June 2013 at 22:55:20 UTC, Walter Bright wrote:
 On 6/8/2013 2:23 PM, bearophile wrote:
 - D integer types have guaranteed sizes, but
   they're not obvious from the name
 - Why not have int8, uint8, int32, uint32, etc. in
   default namespace, encourage their use?

 I agree. It's hard to guess the size and signedness of types 
 as byte, ubyte,
 wchar, dchar. I prefer names that are more clear.
It would only be a trivial problem for 5 minutes, only for ex-C/C++ programmers who are used to suffering under variable sized ints, and will never be a problem again. Is it really a problem to guess the size of 'byte'? Or that 'ubyte' is unsigned? Come on, bearophile! And frankly, int32, long64, etc., have a large 'yech' factor for me. Besides, if you really do want them, import core.stdc.stdint;
It was a relief to go from C++ to D and be guaranteed the sizes. No 'u' is signed, 'u' is unsigned, simple as simple gets. Took me a little while to learn and adjust, but not much. I didn't know about core.stdc.stdint; I may use it for the few cases where the size is very important with no room for erroneously choosing the wrong one. Slam dunk! --rt
Jun 13 2013
prev sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Slide 61:

 - Be open minded: faster CTFE opens doors
   - Generating procedural content at compile time
   - "If you build it, they will come"
There are many applications for compile-time computation, this small thread discusses about applications of a compile-time constraint solver: http://lambda-the-ultimate.org/node/4762 The question:
C's type system can be seen as a constraint checker; Haskell's 
as a constraint solver. If you had a general purpose constraint 
solver at compile-time what could you use it for other than type 
checking?<
Bye, bearophile
Jun 13 2013
prev sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, June 09, 2013 15:40:40 Peter Williams wrote:
 On 09/06/13 14:03, Jonathan M Davis wrote:
 If I had been designing the language, I might have gone for int8, uint8,
 int16, uint16, etc. (in which case, _all_ of them would have had sizes
 with no aliases without - it seems overkill to me to have both), but I
 also don't think that it's a big deal for them to not have the numbers
 either, and I don't understand why anyone would think that it's all that
 hard to learn and remember what the various sizes are
It's the ghost of problems past when the sizes many of the various integer/natural types in C were "implementation dependent". Maybe it only afflicts programmers over a certain age :-) Platform dependent macros such as int32 mapping to the appropriate type for the implementation were a mechanism for making code portable and old habits die hard.
I'm well aware of that. I work in C++ for a living and have to deal with variable-sized integral types all the time. But that doesn't mean that it's not easy to learn and remember that D made its integral types fixed size and what that size is for each of them.
 PPS I think the numbering paradigm would be good for floating point
 types as well.  The mathematician in me is unsettled by a digital type
 called "real" as real numbers can't be represented in digital form -
 only approximated. So, if it wasn't already too late, I'd go for
 float32, float64 and float80.
The size of real is implementation defined. You have no guarantee whatsoever that you even _have_ float80. real is defined to be the largest floating point type provided by the architecture or double - whichever is larger. On x86, that happens to be 80 bits, but it won't necessarily be 80 bits on other architectures. - Jonathan M Davis
Jun 08 2013