3 ms·

Yeah, I tend to agree. I tried reading it even more closely, and here's how I'm interpreting it: * In a normal compiler, you have the front-end which generates

Yeah, I tend to agree. I tried reading it even more closely, and here's how I'm interpreting it: * In a normal compiler, you have the front-end which generates intermediate code in a pseudo-assembly language, and you have the back end that compiles that intermediate code into assembly language (or into JVM or CLR or even JavaScript, these days...) * In AnyDSL, the front end takes the code and compiles it into, well, the same language, only with decreasing levels of abstraction from the hardware. I don't know if you're familiar with "shader" languages (for OpenGL and DirectX and similar), but they're written in a syntax that looks very much like C. It's not precisely C, but it looks a whole lot like C -- but every statement effectively generates machine code directly, and they get executed in parallel. So if you're writing a pixel shader that makes everything more red, you'd write a statement like (pseudocode): output.r += 10; ...and when it drew the texture or polygon to the screen, it would execute your code once for each pixel. In AnyDSL, it looks like the top level language is very much like a normal (functional) language. That language gets "compiled" into an intermediate abstraction language (like the one using @iterate call), and the final "compilation" step is like the shader language, in that it's letting you define a target-specific implementation, which could include vector functions or pixel shaders or whatever. If this were C, then the second level would be internal to the compiler and completely opaque, and the final level would be the compiler backend+libraries, which might have calls to implement vector math. If you imagine lifting those backend libraries up into the same compiler, where the libraries are written in a similar language syntax, you can imagine that they can do a lot more to optimize the result, because more of the code gets built at the same time, and a lot of intermediate states can be eliminated at compile time. But yes, it still feels fundamentally like a compiler. Only a compiler where you can't just link in existing C-based libraries, because then it wouldn't be able to do its magic. So you therefore need to reinvent all the wheels?

mikkom 10y ago
> * In AnyDSL, the front end takes the code and compiles it into, well, the same language, only with decreasing levels of abstraction from the hardware. I thought this was called a macro.
- sddfd 10y ago
  The exact point is that instead of macros, higher-order functions are used.
  - pka 10y ago
    Why can't you use higher-order functions in macros?
sddfd 10y ago
Basically the idea is that a compiler that does partial evaluation and can generate extremely efficient code for higher-order functions provides a nice framework for Deals. I wouldn't call it reinventing the wheel.
- SomeCallMeTim 10y ago
  It's reinventing the wheel if you need rewrite functionality that's otherwise available in C libraries. Has anyone who you can trust written encryption code in AnyDSL? If not, then you either need to write it yourself (reinventing the wheel, and generally considered A Bad Idea with encryption code), or you need to call a C library, obviating much of the optimization advantage of using AnyDSL.
kagebe 10y ago
In most compilers today, the front-end generates an AST, from which an(other) intermediate representation (IR, named Thorin in AnyDSL[1]) is generated. On that IR, the "middle-end" already optimizes a lot and the back-end finally generates whatever output formats the compiler targets (for AnyDSL: LLVM, CUDA/NVVM, OpenCL). > * In AnyDSL, the front end takes the code and compiles it into, well, the same language, only with decreasing levels of abstraction from the hardware. The AnyDSL language (Impala) compiler works exactly like my compiler description above. However, the levels of abstraction you refer to here, are all written in the same "top level" language (a "host" language in DSL literature terms) and are basically just libraries on top of each other. The @ on the iterate call partially evaluates the call (aggressive inlining and specialization) at compile time on the Thorin IR. This feature allows the compiler to remove the layers of abstraction again and bake the code together, like you say. > But yes, it still feels fundamentally like a compiler. Only a compiler where you can't just link in existing C-based libraries, because then it wouldn't be able to do its magic. So you therefore need to reinvent all the wheels? Yes, it is a compiler - but you don't need to write one for your DSL (unless you really need other syntax). You're correct with regard to external libraries: If you need to remove the abstraction overhead (e.g. function calls) of your external library for performance reasons you'd need to re-implement that in AnyDSL. 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.. [1] See the paper: http://compilers.cs.uni-saarland.de/papers/lkh15_cgo.pdf http://compilers.cs.uni-saarland.de/papers/lkh15_cgo.pdf
- SomeCallMeTim 10y ago
  >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.

mikkom 10y ago

> * In AnyDSL, the front end takes the code and compiles it into, well, the same language, only with decreasing levels of abstraction from the hardware. I thought this was called a macro.

sddfd 10y ago
The exact point is that instead of macros, higher-order functions are used.
- pka 10y ago
  Why can't you use higher-order functions in macros?

sddfd 10y ago

Basically the idea is that a compiler that does partial evaluation and can generate extremely efficient code for higher-order functions provides a nice framework for Deals. I wouldn't call it reinventing the wheel.

SomeCallMeTim 10y ago
It's reinventing the wheel if you need rewrite functionality that's otherwise available in C libraries. Has anyone who you can trust written encryption code in AnyDSL? If not, then you either need to write it yourself (reinventing the wheel, and generally considered A Bad Idea with encryption code), or you need to call a C library, obviating much of the optimization advantage of using AnyDSL.

kagebe 10y ago

In most compilers today, the front-end generates an AST, from which an(other) intermediate representation (IR, named Thorin in AnyDSL[1]) is generated. On that IR, the "middle-end" already optimizes a lot and the back-end finally generates whatever output formats the compiler targets (for AnyDSL: LLVM, CUDA/NVVM, OpenCL). > * In AnyDSL, the front end takes the code and compiles it into, well, the same language, only with decreasing levels of abstraction from the hardware. The AnyDSL language (Impala) compiler works exactly like my compiler description above. However, the levels of abstraction you refer to here, are all written in the same "top level" language (a "host" language in DSL literature terms) and are basically just libraries on top of each other. The @ on the iterate call partially evaluates the call (aggressive inlining and specialization) at compile time on the Thorin IR. This feature allows the compiler to remove the layers of abstraction again and bake the code together, like you say. > But yes, it still feels fundamentally like a compiler. Only a compiler where you can't just link in existing C-based libraries, because then it wouldn't be able to do its magic. So you therefore need to reinvent all the wheels? Yes, it is a compiler - but you don't need to write one for your DSL (unless you really need other syntax). You're correct with regard to external libraries: If you need to remove the abstraction overhead (e.g. function calls) of your external library for performance reasons you'd need to re-implement that in AnyDSL. 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.. [1] See the paper: http://compilers.cs.uni-saarland.de/papers/lkh15_cgo.pdf http://compilers.cs.uni-saarland.de/papers/lkh15_cgo.pdf

SomeCallMeTim 10y ago
>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.