3 ms·

That's a very specific special case. For instance, if you have more iterations than cores or processors, you'll still need to do looping somewhere. In the gene

That's a very specific special case. For instance, if you have more iterations than cores or processors, you'll still need to do looping somewhere. In the general case, the statement is still true.

ModernMech 5y ago
It's a specific case but not a very specific case, and one that is becoming more common as core counts are exploding. And anyway, even if it were a very specific case it's still an existence proof that disproves the assertions that "all that abstraction is being turned into loops and jumps." as one other poster put it. The replies here are speaking in very absolute terms ("you don’t have any choice", "loops and jumps cannot ever go away regardless of the higher level abstractions"), which are not true in an absolute sense. The OP said: > Do you mean for all imperative languages? Functional or declarative languages can do away with loops and jumps And everyone here is answering them so far from the perspective of imperative languages. But depending on the program, it's not necessarily the general case in declarative languages, where we have much more freedom to compile things as we want, including without loops where they would be used in an imperative language. Since this is a thread about language design and we're talking about alternative paradigms and how things get compiled to instructions, it's absolutely true that if our problem can be parallelized we don't have to loop at all. This is not a special case, but something that is generally applicable to many kinds of situations. Now that we're entering a world of potentially 1000s of cores available on consumer CPUs in the near future, what I'm saying is going to become the general case more and more.
- jstimpfle 5y ago
  If the iteration bounds are statically known (i.e. 0...10 in above example) you can avoid the loop by unrolling it, or using some kind of explicit parallelism, like SIMD for example. In general, the iteration bounds aren't known and some kind of loop is required.

That's a very specific special case. For instance, if you have more iterations than cores or processors, you'll still need to do looping somewhere. In the general case, the statement is still true.

ModernMech 5y ago

It's a specific case but not a very specific case, and one that is becoming more common as core counts are exploding. And anyway, even if it were a very specific case it's still an existence proof that disproves the assertions that "all that abstraction is being turned into loops and jumps." as one other poster put it. The replies here are speaking in very absolute terms ("you don’t have any choice", "loops and jumps cannot ever go away regardless of the higher level abstractions"), which are not true in an absolute sense. The OP said: > Do you mean for all imperative languages? Functional or declarative languages can do away with loops and jumps And everyone here is answering them so far from the perspective of imperative languages. But depending on the program, it's not necessarily the general case in declarative languages, where we have much more freedom to compile things as we want, including without loops where they would be used in an imperative language. Since this is a thread about language design and we're talking about alternative paradigms and how things get compiled to instructions, it's absolutely true that if our problem can be parallelized we don't have to loop at all. This is not a special case, but something that is generally applicable to many kinds of situations. Now that we're entering a world of potentially 1000s of cores available on consumer CPUs in the near future, what I'm saying is going to become the general case more and more.

jstimpfle 5y ago
If the iteration bounds are statically known (i.e. 0...10 in above example) you can avoid the loop by unrolling it, or using some kind of explicit parallelism, like SIMD for example. In general, the iteration bounds aren't known and some kind of loop is required.