[SomeCallMeTim]

>However, that holds true for any DSL framework and compiler, unless you compile everything to (C) binaries and do partial evaluation at link time. But at that point you've already lost a lot of information that a compiler can usefully exploit to generate better code: more abstract types, higher-order functions, scheduling info, alias info, etc..

For quite some time, C and C++ linkers have had the ability to look back at the original C/C++ code and literally rebuild the code differently to optimize the program across objects. In the Microsoft compile chain this is called "Global Optimizations". So I don't see AnyDSL's ability to do the same as a completely unique proposition.

The other issue that I see with this is that 98% of code doesn't need to be optimized down to the level that AnyDSL enables. JIT compilers are really good at optimizing the execution path without having to involve programmers at the intermediate and low levels, for example.

In the few cases where you need to target LLVM, CUDA and OpenCL for a particularly performance critical routine, I could see this as being useful, as long as the resulting code can be called from a more standard language. I'd like to see really trivial C bindings (via exported .h files) at a minimum, but C++, Go, Rust, JavaScript, Python, and other modern languages could really hit the performance required of 98% of the code, leaving only the extreme performance code for something like AnyDSL.

But I'd say that front-and-center: "AnyDSL is about creating ultra optimized cross-hardware performance critical code, targeting LLVM, CUDA, and OpenCL code based on the same high level code." All of the talk about theory is just distracting people from the actual "killer app" of AnyDSL.

[kagebe]

Partial evaluation (whether online/offline) is not implemented in any (current) C/C++/Rust compiler, for very good reasons. "Global Optimizations" may do a significant number of optimizations that partial evaluation may do and some that partial evaluation is unable to do (depending on your abstractions, e.g. code motion).

I totally agree that these kinds of optimizations are unnecessary for most applications, which is why we target and compare against High-Performance Computing algorithms and DSLs. Have a look at the publications and comparisons with OpenCV and similar.

If you want to wrap AnyDSL HPC code with some other language, sure. There is an experimental compiler flag --emit-c-interface right now. :)

However, most of the current HPC DSL frameworks generate some C code from Python/etc by stitching together library calls to BLAS/etc. in some haphazard, mostly untyped way - not ideal.

> But I'd say that front-and-center: "AnyDSL is about creating ultra optimized cross-hardware performance critical code, targeting LLVM, CUDA, and OpenCL code based on the same high level code." All of the talk about theory is just distracting people from the actual "killer app" of AnyDSL.

Thanks, I agree. Presentation could definitely use some work. As it stands, it's mostly a presentation of the published research work and not yet addressed to users.