5 ms·

I'm not sure that will ever happen, at least without changing languages. Autovectorization alone is difficult in C and C++ because the languages provide almost

I'm not sure that will ever happen, at least without changing languages. Autovectorization alone is difficult in C and C++ because the languages provide almost no useful information about aliasing. Precise aliasing info is just the tip of the iceberg regarding what you would need for GPU-based autovectorization.

moosingin3space 9y ago
Is there any discussion about doing this in Rust? (maybe surrounding the SIMD RFCs)
willvarfar 9y ago
(On the Mill CPU the retire stations snoop/snarf writes and spot aliasing as it happens at runtime. This is a big part of our auto-vectorisation)
- nicwilson 9y ago
  Cool, I'm looking forward to seeing more news about the mill.
  - willvarfar 9y ago
    https://news.ycombinator.com/item?id=14797350 https://news.ycombinator.com/item?id=14797350 probably won't get on the front page of HN :|
- CyberDildonics 9y ago
  Interesting, are there benchmarks I can look at?
WalterBright 9y ago
D has array expressions, which look like: a[] = c * b[]; The idea of them is they are parallelizable, and do not require an auto-vectoring loop optimizer. Auto-vectorizing is fraught with problems, like the user not being aware if the auto-vectorizing succeeded or not. Another aspect of D that enables parallization is the use of ranges + algorithms. Although currently unexploited, it has the potential to be able to express parallel algorithms, and then take advantage of that.
- VHRanger 9y ago
  > Another aspect of D that enables parallization is the use of ranges + algorithms. Is that similar to the C++ std::algorithm execution policy features introduced in C++17?
  - nicwilson 9y ago
    No. What Walter is talking about in D is if you have Foo[] foo = ...; foreach(f; foo) { f.bar.baz.quux; } and the computation is parallelisable then you can write import std.parallelism; foreach(f; parallel(foo)) { f.bar.baz.quux; } and it will parallelised across threads. I guess std.parallelism's parallel might be more analogous to an "instance" of an executor.
    - VHRanger 9y ago
      So that's similar to OpenMP parallel for looping?
  - WalterBright 9y ago
    I'm not familiar with that aspect of C++17.
    - nicwilson 9y ago
      Its the tag based dispatching for the `par` in std::sort(par,a.begin(),a.end()); to call a parallel implementation of sort on `a`.
- Athas 9y ago
  This can be vectorised for CPU execution (which is nice!), but it will not solve the problem for GPUs. Moving just that scalar-vector multiplication to a GPU would be detrimental to performance, because the run-time would be dominated by the cost of moving the 'b' array to the GPU, followed by moving the 'a' array back. You get into all kinds of issues with where to leave data that has no obvious right answer. It also does not help with problems that are not as embarrassingly parallel, but could still benefit from vectorisation, such as summations (or reductions in general), or things that contain their own inner control flow (think a Mandelbrot set, where you have a larger outer parallel loop with an inner serial while-loop).

moosingin3space 9y ago

Is there any discussion about doing this in Rust? (maybe surrounding the SIMD RFCs)

willvarfar 9y ago

(On the Mill CPU the retire stations snoop/snarf writes and spot aliasing as it happens at runtime. This is a big part of our auto-vectorisation)

nicwilson 9y ago
Cool, I'm looking forward to seeing more news about the mill.
- willvarfar 9y ago
  https://news.ycombinator.com/item?id=14797350 https://news.ycombinator.com/item?id=14797350 probably won't get on the front page of HN :|
CyberDildonics 9y ago
Interesting, are there benchmarks I can look at?

WalterBright 9y ago

D has array expressions, which look like: a[] = c * b[]; The idea of them is they are parallelizable, and do not require an auto-vectoring loop optimizer. Auto-vectorizing is fraught with problems, like the user not being aware if the auto-vectorizing succeeded or not. Another aspect of D that enables parallization is the use of ranges + algorithms. Although currently unexploited, it has the potential to be able to express parallel algorithms, and then take advantage of that.

VHRanger 9y ago
> Another aspect of D that enables parallization is the use of ranges + algorithms. Is that similar to the C++ std::algorithm execution policy features introduced in C++17?
- nicwilson 9y ago
  No. What Walter is talking about in D is if you have Foo[] foo = ...; foreach(f; foo) { f.bar.baz.quux; } and the computation is parallelisable then you can write import std.parallelism; foreach(f; parallel(foo)) { f.bar.baz.quux; } and it will parallelised across threads. I guess std.parallelism's parallel might be more analogous to an "instance" of an executor.
  - VHRanger 9y ago
    So that's similar to OpenMP parallel for looping?
- WalterBright 9y ago
  I'm not familiar with that aspect of C++17.
  - nicwilson 9y ago
    Its the tag based dispatching for the `par` in std::sort(par,a.begin(),a.end()); to call a parallel implementation of sort on `a`.
Athas 9y ago
This can be vectorised for CPU execution (which is nice!), but it will not solve the problem for GPUs. Moving just that scalar-vector multiplication to a GPU would be detrimental to performance, because the run-time would be dominated by the cost of moving the 'b' array to the GPU, followed by moving the 'a' array back. You get into all kinds of issues with where to leave data that has no obvious right answer. It also does not help with problems that are not as embarrassingly parallel, but could still benefit from vectorisation, such as summations (or reductions in general), or things that contain their own inner control flow (think a Mandelbrot set, where you have a larger outer parallel loop with an inner serial while-loop).