Question: Knowing what you know now, why do you think I make such a big deal about knowing when one is talking about a system's abstractions (and their semantics), and when one is talking about a system's implementation?

This comment was marked helpful 0 times.

I think kayvonf answered this at lecture 3, slide 35, his own comment. "the abstraction would not be particularly helpful to a programmer wanting to program this machine".

This comment was marked helpful 0 times.

I think learning an abstraction can help you reason about the correctness of a certain program but it can't necessarily address matters of efficiency whereas knowing precisely how an abstraction is implemented can lend to writing efficient code. A good example of this is the interleaved vs chunked memory accesses among ISPC instances. From the abstraction's point of view these are identical, they will result in the same output, but from an implementation point of view interleaved memory accesses will result in much higher performance. Understanding the abstraction can help you apply skills from a particular architecture across many different architectures but understanding the implementation can help you apply skills to a particular architecture efficiently. It is important to understand the difference because if you confuse the two, what may be efficient on one architecture is ridiculously inefficient on another.

This comment was marked helpful 2 times.

Difference of concurrency and parallelism also illustrates the idea of abstraction and implementation. Abstraction is from the software's perspective of view while implementation talks about hardware.

This comment was marked helpful 0 times.

I think that it is important to stress that the abstraction is different than the implementation because they are actually describing an algorithm/structure on different levels. For example, while the ISPC "foreach" abstraction launches a so-called 'gang' of instances, we don't necessarily know that this is implemented as vector instructions with vector lanes until we get into the implementation. The idea is that the implementation could change without changing the abstraction, thus maintaining the same interface for the user and not rendering previously written code invalid.

This comment was marked helpful 0 times.

@yrkumar, you are correct in your comments about the difference between abstraction and implementation, but I believe you have mischaracterized the semantics of the foreach construct. Care to make an update? Hint.

This comment was marked helpful 0 times.

Going off of Kayvon's post in the other slide, the foreach construct is just there to tell the compiler that any of these iterations can be done in parallel. However, foreach doesn't actually launch any parallel iterations. Instead, it just lets the compiler divide up the various iterations among the different threads which are already working in parallel. Thus, there are no guarantees about how or where each iteration will be executed, but that shouldn't matter because we already claimed that the order of these iterations didn't matter by designating the loop a foreach loop.

This comment was marked helpful 1 times.

@TheRandomOne: very well said.

This comment was marked helpful 0 times.