Previous | Next --- Slide 22 of 58
Back to Lecture Thumbnails
oulgen

I feel like there is a major problem with this paradigm of programming. There is tons of hand holding and almost everything that the compiler is doing is hidden from the user. This means that the user has to trust the compiler. In my experience, trust is not a good value while writing code. If I were to know how the compiler will implement a certain data structure, I could use this to my benefit while writing the code. By benefit, I entirely mean efficiency. For example, if I were to know whether the neighbor operation for a vertex on a graph is O(1) or O(logn), I could write my program accordingly.

VP7

@oulgen. I understand your point.

  1. But by the time a programming paradigm enters a production environment, it would have under gone sufficient stress testing in regards of correctness and efficiency. Halide is a really good example for that.

  2. Another important aspect to consider here is the factors summarized in slide 14. It is a trade off between productivity and performance. Although it is debatable, one would prefer a piece of highly portable domain specific code with reasonably high performance over a less/ non-portable high performing code.

  3. Another experimental example would be Darkroom, a domain specific programming language embedded in Terra (which is a low level interface to lua) which aim's at synthesizing hardware logic for a given algorithm described functionally.

cgjdemo

Unlike a general-purpose language, DSL is limited in scope and capabilities. DSL has better execution plan and extract better parallelism for the functionalities it provides. So to some extent we can safely trust the compiler. But if the program is a complicated combination of these functionalities, we may not get the desirable performance we want. Also there are many reasons that we use DSL such as productivity and conciseness. So I think it is acceptable that sometimes the compiler does not give us the best performance.

ericwang

I think besides tradeoff between performance and productivity, another reason we may want to use DSL is portability.

Using general-purpose language, every time the program is transplanted to a different platform, programmers need to refactor code.

However, with DSL, the code itself only describes the business requirement without much detail. So hopefully there is little need to re-fit the code with a new platform.

HLAHat

One other thing that seems important to note is that DSL's are likely to be used by people who are not programmers. Of course we would want to know everything to optimize our code or algorithm, but for most users, they just want something easy to learn so they can get the job done without too much headache. They have to trust the system because that's all they know how to use.

Also, one common theme in this class is optimizing for the common case. Most applications that DSL's will be used for will not be terribly complicated and will fit neatly in the scope the DSL was designed for. This means the compiler's assumptions will generally line up with the intent of the programmer and provide solid results.

Of course, maybe an actual programmer would find a lot of use in these DSL's for quick prototyping or fun thought experiments and would like to have more information available in order to better port and specialize a completed program or algorithm. However, I think having the compiler rigorously communicate its thought process could be more trouble than it's worth.

yuel1

@ericwang The way I see it, for portability at least, we would still need to look at each piece of hardware and decide how to make the most of the hardware for the provided primitives.