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++ :-)
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