Question: I used the term "abstraction distance" in this summary without ever defining it in the lecture. What do you think I meant here? (note: my comment on slide 35 is relevant)
This comment was marked helpful 0 times.
ron
I understand this as how strongly associated the top-level programming language/library and the hardware instruction architecture are, how closely they reflect each other, or how many details of hardware implementation are hidden by the programming language (the 'abstraction'). The SIMD vector intrinsics we work with in Program 2 (if they really did translate into vector instructions for the CPU) are thus an example of really low abstraction distance, while a functional language like SML is an example of high abstraction distance. Because the logic we use to develop programs and algorithms usually doesn't involve thinking in terms of hardware loads/stores and bit-wise operations, a high abstraction distance can allow for a more intuitive programming model; but makes it difficult to have fine-grained control over performance at the hardware level since those details are often hidden.
This comment was marked helpful 0 times.
asinha
Applying the term abstraction distance to this lecture, ISPC tasks definitely have a greater abstraction distance than Pthreads. With Pthreads, the programmer has finer control over targeting each thread to complete a specific task, so much of the abstraction is taken away. However with ISPC tasks, the programmer has the actual functionality hidden from view through the layer of abstraction that is the gang of instances, which decide themselves how to complete a task without programmer input.
This comment was marked helpful 0 times.
jinsikl
I think "abstraction distance" is a measurement of how much work it takes to go from the abstraction to the actual implementation. So for example C would have a low abstraction distance compared to other higher level languages. The slide is mentioning that an abstraction should shoot for the right amount of abstraction distance. Too much would mean that programs become unpredictable, and too little would mean that the abstraction becomes inflexible.
Question: I used the term "abstraction distance" in this summary without ever defining it in the lecture. What do you think I meant here? (note: my comment on slide 35 is relevant)
This comment was marked helpful 0 times.
I understand this as how strongly associated the top-level programming language/library and the hardware instruction architecture are, how closely they reflect each other, or how many details of hardware implementation are hidden by the programming language (the 'abstraction'). The SIMD vector intrinsics we work with in Program 2 (if they really did translate into vector instructions for the CPU) are thus an example of really low abstraction distance, while a functional language like SML is an example of high abstraction distance. Because the logic we use to develop programs and algorithms usually doesn't involve thinking in terms of hardware loads/stores and bit-wise operations, a high abstraction distance can allow for a more intuitive programming model; but makes it difficult to have fine-grained control over performance at the hardware level since those details are often hidden.
This comment was marked helpful 0 times.
Applying the term abstraction distance to this lecture, ISPC tasks definitely have a greater abstraction distance than Pthreads. With Pthreads, the programmer has finer control over targeting each thread to complete a specific task, so much of the abstraction is taken away. However with ISPC tasks, the programmer has the actual functionality hidden from view through the layer of abstraction that is the gang of instances, which decide themselves how to complete a task without programmer input.
This comment was marked helpful 0 times.
I think "abstraction distance" is a measurement of how much work it takes to go from the abstraction to the actual implementation. So for example C would have a low abstraction distance compared to other higher level languages. The slide is mentioning that an abstraction should shoot for the right amount of abstraction distance. Too much would mean that programs become unpredictable, and too little would mean that the abstraction becomes inflexible.
This comment was marked helpful 0 times.