Jump to content

  • Log In with Google      Sign In   
  • Create Account


#ActualHodgman

Posted 03 May 2013 - 03:18 AM

// In this example the first 4 squares will be filled in parallel and the final one will not happen until
// they are all complete because it overlaps them all

I find that feature very interesting! Does this basically mean, that when scheduling that parallel block, you can determine every byte that the function-calls in the block could possibly touch? That seems like a tricky thing for a compiler to figure out; how robust is it - can you fool it with pointer math or too much indirection?

How do you wait on these parallel jobs to complete? Does the closing brace act as a "join" point, or do you again automatically detect when a later function reads from their output regions and insert a 'wait' marker at that point?

 

Also, there may be some cases where you want to pass the same output array to every thread, but you know algorithmically that those threads will write to unpredictable but unique regions of the array. e.g. with a parallel radix sort, each thread will read from a non-overlapping range of the input array, but will write to non-overlapping, but also non-contiguous elements in the output array. Is there a way to kick off these kinds of "dangerous" parallel function calls (with undefined behaviour if the user is wrong about their algorithmic safety)?

 

Having said all that, I'm very keen for people to use it and if you think that just putting the source code out there regardless
of bugs would help to make that happen then I'll consider it. Please let me know if you have any thoughts about how I should proceed.

I recently decided to start using the ispc language, alongside C++ in my game, which was a big decision to commit to! Swaying users to a new language is no easy feat. Some of the things that swayed me were:

* The source code is published, so if it's abandoned by the authors, it's development can still continue. This is quite different to the author saying that they will publish the source at some point in the future.

* They use LLVM for back-end code generation, which reduces the complexity of the project and gives me a bit more faith in the general ability for the project to be maintained.

* The compiler spits out standard C object files, conforming to C's ABI, so I can integrate it into my project very easily, and do easy interop between ispc/c/c++.

* The compiler can also spit out C++ source files (transcode from ispc->c++), so if I want to port my code to a platform that isn't yet supported, I've got this backup plan available.

* The compiler spits out standard debug files to go with the object files, so existing debuggers can be used -- this one is only theoretical for me for now though, because this feature is Linux/Mac only at the moment sad.png

 

So yeah, I think that publishing the compiler as an open-source project would be a positive thing to do smile.png


#4Hodgman

Posted 03 May 2013 - 03:17 AM

// In this example the first 4 squares will be filled in parallel and the final one will not happen until
// they are all complete because it overlaps them all

I find that feature very interesting! Does this basically mean, that when scheduling that parallel block, you can determine every byte that the function-calls in the block could possibly touch? That seems like a tricky thing for a compiler to figure out; how robust is it - can you fool it with pointer math or too much indirection?

How do you wait on these parallel jobs to complete? Does the closing brace act as a "join" point, or do you again automatically detect when a later function reads from their output regions and insert a 'wait' marker at that point?

 

Also, there may be some cases where you want to pass the same output array to every thread, but you know algorithmically that those threads will write to unpredictable but unique regions of the array. e.g. with a parallel radix sort, each thread will read from a non-overlapping range of the input array, but will write to non-overlapping, but also non-contiguous elements in the output array. Is there a way to kick off these kinds of "dangerous" parallel function calls (with undefined behaviour if the user is wrong about their algorithmic safety)?

 

Having said all that, I'm very keen for people to use it and if you think that just putting the source code out there regardless
of bugs would help to make that happen then I'll consider it. Please let me know if you have any thoughts about how I should proceed.

I recently decided to start using the ispc language, alongside C++ in my game, which was a big decision to commit to, and some of the things that swayed me were:

* The source code is published, so if it's abandoned by the authors, it's development can still continue. This is quite different to the author saying that they will publish the source at some point in the future.

* They use LLVM for back-end code generation, which reduces the complexity of the project and gives me a bit more faith in the general ability for the project to be maintained.

* The compiler spits out standard C object files, conforming to C's ABI, so I can integrate it into my project very easily, and do easy interop between ispc/c/c++.

* The compiler can also spit out C++ source files (transcode from ispc->c++), so if I want to port my code to a platform that isn't yet supported, I've got this backup plan available.

* The compiler spits out standard debug files to go with the object files, so existing debuggers can be used -- this one is only theoretical for me for now though, because this feature is Linux/Mac only at the moment sad.png

 

So yeah, I think that publishing the compiler as an open-source project would be a positive thing to do smile.png


#3Hodgman

Posted 03 May 2013 - 03:15 AM

// In this example the first 4 squares will be filled in parallel and the final one will not happen until
// they are all complete because it overlaps them all

I find that feature very interesting! Does this basically mean, that when scheduling that parallel block, you can determine every byte that the function-calls in the block could possibly touch? That seems like a tricky thing for a compiler to figure out; how robust is it - can you fool it with pointer math or too much indirection?

 

Also, there may be some cases where you want to pass the same output array to every thread, but you know algorithmically that those threads will write to unpredictable but unique regions of the array. e.g. with a parallel radix sort, each thread will read from a non-overlapping range of the input array, but will write to non-overlapping, but also non-contiguous elements in the output array. Is there a way to kick off these kinds of "dangerous" parallel function calls (with undefined behaviour if the user is wrong about their algorithmic safety)?

 

Having said all that, I'm very keen for people to use it and if you think that just putting the source code out there regardless
of bugs would help to make that happen then I'll consider it. Please let me know if you have any thoughts about how I should proceed.

I recently decided to start using the ispc language, alongside C++ in my game, which was a big decision to commit to, and some of the things that swayed me were:

* The source code is published, so if it's abandoned by the authors, it's development can still continue. This is quite different to the author saying that they will publish the source at some point in the future.

* They use LLVM for back-end code generation, which reduces the complexity of the project and gives me a bit more faith in the general ability for the project to be maintained.

* The compiler spits out standard C object files, conforming to C's ABI, so I can integrate it into my project very easily, and do easy interop between ispc/c/c++.

* The compiler can also spit out C++ source files (transcode from ispc->c++), so if I want to port my code to a platform that isn't yet supported, I've got this backup plan available.

* The compiler spits out standard debug files to go with the object files, so existing debuggers can be used -- this one is only theoretical for me for now though, because this feature is Linux/Mac only at the moment sad.png

 

So yeah, I think that publishing the compiler as an open-source project would be a positive thing to do smile.png


#2Hodgman

Posted 03 May 2013 - 03:13 AM

// In this example the first 4 squares will be filled in parallel and the final one will not happen until
// they are all complete because it overlaps them all

I find that feature very interesting! Does this basically mean, that when scheduling that parallel block, you can determine every byte that the function-calls in the block could possibly touch? That seems like a tricky thing for a compiler to figure out; how robust is it - can you fool it with pointer math or too much indirection?

 

Also, there may be some cases where you want to pass the same output array to every thread, but you know algorithmically that those threads will write to unpredictable but unique regions of the array. e.g. with a parallel radix sort, each thread will read from a non-overlapping range of the input array, but will write to unpredictable yet unique (non-overlapping, but also not contiguous) elements in the output array. Is there a way to kick of these kinds of "dangerous" parallel function calls?

 

Having said all that, I'm very keen for people to use it and if you think that just putting the source code out there regardless
of bugs would help to make that happen then I'll consider it. Please let me know if you have any thoughts about how I should proceed.

I recently decided to start using the ispc language, alongside C++ in my game, which was a big decision to commit to, and some of the things that swayed me were:

* The source code is published, so if it's abandoned by the authors, it's development can still continue. This is quite different to the author saying that they will publish the source at some point in the future.

* They use LLVM for back-end code generation, which reduces the complexity of the project and gives me a bit more faith in the general ability for the project to be maintained.

* The compiler spits out standard C object files, conforming to C's ABI, so I can integrate it into my project very easily, and do easy interop between ispc/c/c++.

* The compiler can also spit out C++ source files (transcode from ispc->c++), so if I want to port my code to a platform that isn't yet supported, I've got this backup plan available.

* The compiler spits out standard debug files to go with the object files, so existing debuggers can be used -- this one is only theoretical for me for now though, because this feature is Linux/Mac only at the moment sad.png

 

So yeah, I think that publishing the compiler as an open-source project would be a positive thing to do smile.png


#1Hodgman

Posted 03 May 2013 - 03:10 AM

// In this example the first 4 squares will be filled in parallel and the final one will not happen until
// they are all complete because it overlaps them all

I find that feature very interesting! Does this basically mean, that when scheduling that parallel block, you can determine every byte that the function-calls in the block could possibly touch? That seems like a tricky thing for a compiler to figure out; how robust is it - can you fool it with pointer math or too much indirection?

 

Also, there may be some cases where you want to pass the same output array to every thread, but you know algorithmically that those threads will write to unpredictable but unique regions of the array. e.g. with a parallel radix sort, each thread will read from a non-overlapping range of the input array, but will write to unpredictable yet unique (non-overlapping, but also not contiguous) elements in the output array. Is there a way to kick of these kinds of "dangerous" parallel function calls?

Having said all that, I'm very keen for people to use it and if you think that just putting the source code out there regardless
of bugs would help to make that happen then I'll consider it. Please let me know if you have any thoughts about how I should proceed.

I recently decide to start using the ispc language, alongside C++ in my game, which was a big decision to commit to, and some of the things that swayed me were:

* The source code is published, so if it's abandoned by the authors, it's development can continue. This is quite different to the author saying that they will publish the source.

* They use LLVM for back-end code generation, which reduces the complexity of the project and gives me a bit more faith in the general ability to maintain it.

* The compiler spits out standard C object files, conforming to C's ABI, so I can integrate it into my project very easily.

* The compiler can also spit out C++ source files (transcode from ispc->C++), so if I want to port my code to a platform that isn't yet supported, I've got this backup plan available.

* The compiler spits out standard debug files to go with the object files, so existing debuggers can be used -- this one is only theoretical for me for now though, because this feature is Linux/Mac only for now sad.png


PARTNERS