Herb Sutter on Heterosexual Computing

Looks like Microsoft is tired of HomogenousHomosexual Computing (ie. Apple/Macs) and paints a possible future of mainstream HeterogenousHeterosexual Computing.
 
http://media.ch9.ms/ch9/7655/e3d5a308-d1fb-4693-998e-9f04000f7655/AMDFusionHerbSutterKeynoteAMP_high_ch9.mp4

It's a bit Microsoft biased, made me cringe a bit in a few spots, but the bulk of the talk is rather interesting. Herb Sutter used to be the chairperson of the ISO/IEC C and C++ language committees, by the way. I wonder how the Linux kernel will adapt to heterogeneous computing? We already have OpenCL, but the kernel isn't using it itself--is there any application for this kind of stuff inside of a kernel?

is there any application for this kind of stuff inside of a kernel?
I'm gay.

I was a bit skeptical at first, but towards the end, when he mentioned that they're making C++ AMP an open, royalty-free ISO standard and that the core ISO C++ specification would evolve along with it, I started getting pumped. I just hope it doesn't end up like .NET, where even though it was standardized, there were a bunch of things, especially in the library that are Windows/Microsoft specific.

I also specifically liked when he mentioned using restrict(pure) to instruct the compiler to ensure that attributed functions don't have side-effects. If something like that makes it into the next C++ or even C language standards, we will have come full circle where imperative languages really have merged with functional languages.

At that point, who needs Lisp?

>>3
that attributed functions don't have side-effects.
It's undecidable.

Functional programming with manual memory management, and without proper tail call, is also moronic.
FP is not the only thing that makes Lisp necessary, and ``look with can lambda! lol'' doesn't replace real functional languages.

Of course IHBT.

>>4
Modern C++ compilers can detect tail recursive calls and optimize appropriately, see Clang/LLVM.

And how does manual memory management make pure functions undecidable. Sorry for being the devil's advocate.

>>5
Tail recursion != tail calls. PTC is impossible with some C calling conventions. (when the caller cleans the stack)
Right now, compilers optimize only tail calls to procedures with a compatible signature. (i.e., (int, int) -> (int, int))
There was a calling convention that permitted PTCs, but I don't see it being implemented by any compiler, and couldn't handle varargs on some architectures anyway.

>>5
You can't decide whether a procedure is pure or impure:
pure int function(int a) {
   if (0) puts("Impure");
   return a*2;
}
is pure, and a sufficiently smart compiler may detect it.
pure int function(int a) {
   if (runtime_condition_that_always_holds_false) puts("Impure");
   return a*2;
}
is also pure, because you know that that condition will always be false, but the compiler doesn't, so it will be rejected.
This example is stupid and means nothing.

Now, we don't want pure functions just to fap on their purity, pure functions have a nice property: referential transparency. But, we can achieve referential transparency using side effects:
(define (map f xs)
 (let loop ((xs xs) (r '())
   (if (null? xs) (reverse! r) ;; destructively updates r, it's a side effect.
       (loop (cdr xs) (cons (f (car xs)) r)))))
is a perfectly fine definition of the procedure map, because:
(let ((old-x (deep-copy x)))
 (and (equal? (map f x) (map f x))
      (equal? old-x x)))
will always be true (if f is also pure).

Yet, reverse! is not pure, so the compiler will reject a perfectly fine ``pure'' function.

Manual memory management is just stupid in functional languages, but it's not related to function's purity (except when the new pointer escapes from the function).

That said, IHBT again.

>>6
Right now, compilers optimize only tail calls to procedures with a compatible signature

Nope. Only real constraint is that you don't use variable argument lists via ... in function signatures.

When you mark functions with extern "C" on certain target platforms, it will use the operating system's ABI, in which case you may not get tail-call optimization. For C++, LLVM and most other compilers have their own ABIs where tail call optimization is possible.

See:

http://llvm.org/docs/CodeGenerator.html#tailcallopt

>>7
Yeah, but you're mixing pure with unpure code in your Scheme example, where the onus on ensuring referential transparency is on the programming but then bashing a hypothetical C/C++ pure function implementation for doing the same thing.

In the second C/C++ example, a simple solution would be to have the compiler emit a runtime guard that would throw an exception if it ever was about to enter the puts function, as that would obviously be the result of programmer error, while still allowing the function to compile. It would only omit such runtime checks if you called functions that were also marked as pure.

>>8
I just tried. GCC failed to optimize the tail calls, Clang/LLVM optimized:
(int) -> (int,int)
(int,int) -> (int)
(int,int) -> (int,int,int)
but not (int,int,int) -> (int,int).

Here's the code:

#include <iostream>
int fact(int);
int fact_iter(int,int);
int fact_iter2(int,int,int);
int fact(int a) {
    return fact_iter(a,1);
}

int fact_iter(int a, int r) {
    if (a==0) return r;
    else return fact_iter2(a,r*a,1);
}

int fact_iter2(int a, int r, int s) {
    return fact_iter(a-s,r);
}

int main() {
    std::cout << fact(5);
    return 0;
}

It also miscompiled:
void f() { return f() }
int main() { f(); return 0; }
to just return 0; instead of an infinite loop.

>>9
but you're mixing pure with unpure code in your Scheme example
That was the whole point of the example: map is still referentially transparent. I know that, the compiler doesn't.
The difference between Scheme and C/C++ here would be that Scheme doesn't say anything about ``guaranteed pure functions'', you know that it is pure or referentially transparent.
Again, the whole point of pure functions is referential transparency.

In the second C/C++ example, a simple solution would be to have the compiler emit a runtime guard that would throw an exception if it ever was about to enter the puts function,
Simple question: are exceptions pure?

>>11
Implementation defined at the moment. Some implementations, such as with MSVC++, make heap allocations, whereas other implementations have a small amount of reserved memory for storing exception state out of band.

>>10
Maybe you're using an older version, I just used a recent version from the SVN trunk with -O2 -fvisibility=hidden and got:

    .hidden    _Z10fact_iter2iii
    .globl    _Z10fact_iter2iii
    .align    16, 0x90
    .type    _Z10fact_iter2iii,@function
_Z10fact_iter2iii:                      # @_Z10fact_iter2iii
.Ltmp6:
    .cfi_startproc
# BB#0:                                 # %entry
    subl    %edx, %edi
    jmp    _Z9fact_iterii          # TAILCALL
.Ltmp7:
    .size    _Z10fact_iter2iii, .Ltmp7-_Z10fact_iter2iii
.Ltmp8:
    .cfi_endproc
.Leh_func_end2:

Which shows fact_iter2 tail calling fact_iter, so (int,int,int) -> (int,int) is handled.

As far as your infinite loop, apparently Clang can determine when functions don't have any side-effect and optimize out independent cycles, change it to:


int f() { return f() }
int main() { return f(); }

so that the result of the main function has a dependency on f thus ensuring the optimizer can't optimize it out and you get your tail-call optimized infinite loop. This is expected behavior of C++ and is documented in the latest C++0x draft for the new memory model and data dependencies.

>>13
Yes.

$ cat aaa.cpp
void f() { return f(); }
int main() { f(); return 0; }
$ clang aaa.cpp -fvisibility=hidden -O2 -S; cat aaa.s
    .file    "aaa.cpp"
    .text
    .hidden    _Z1fv
    .globl    _Z1fv
    .align    16, 0x90
    .type    _Z1fv,@function
[b]_Z1fv:                                  # @_Z1fv
# BB#0:
    ret[/b]
.Ltmp0:
    .size    _Z1fv, .Ltmp0-_Z1fv

    .hidden    main
    .globl    main
    .align    16, 0x90
    .type    main,@function
main:                                   # @main
# BB#0:
    xorl    %eax, %eax
    ret
.Ltmp1:
    .size    main, .Ltmp1-main


    .section    ".note.GNU-stack","",@progbits
$ clang aaa.cpp -fvisibility=hidden -O2; ./a.out
$ clang --version
clang version 2.9 (tags/RELEASE_29/final)
Target: i386-pc-linux-gnu
Thread model: posix

I'm getting the SVN trunk now.

>>14
I also noticed that clang inlines the fact_iter2 function into fact_iter function so that theformer is not even called, but you still get a tail optimized iterative loop. Its pretty aggressive at optimizing. I stuxk __attribute__((noinline)) in front of fact_iter2 just to seewhat clang would do, and emits tail optimized jumps in all cases as ypu would expect.

>>13,14
Apparently, apple is pushing hard to get clang/llvm more stable and better performing for the 3.0 release, at which time the will begin to use it for building osx and ios, getting rid of gcc 4.2. Around that time, freebsd will make the transition too, and theres word that debian and other gnu/linux distros will bbegin ofering clang compiled alternatives.

>>15,16

Why can't you type properly?

>>17
I transitioned to the hottub with myarm tablet running ubuntu, inside of awater tight ziplock bag. Part of my daily routine, but morecumbersome for typing.

>>18
hottub
water waster.

SPREAD THE FAIL WHALE

▄██████████████▄▐█▄▄▄▄█▌
██████▌▄▌▄▐▐▌███▌▀▀██▀▀
████▄█▌▄▌▄▐▐▌▀███▄▄█▌
▄▄▄▄▄██████████████▀