What do you think about this idea of separation of algorithm and schedule? Do you think it is a good one? Do you think it could cause programmer headache trying to essentially write "two versions" of a program? I'd like to hear your thoughts...
dsaksena
I think its a good idea, usually the guy doing the image processing and the guy who is implementing it on a machine are 2 different guys. More so I might have no systems knowledge so I could just concentrate on the vision part (algorithm).
While as a systems guy I know what I have to work with SIMD vector size, number of cores, cache size so I can concentrate on scheduling.
So maybe it could make it easy for 2 different programmers to do their specific job rather than 1 programmer's headache.
Even as 1 programmer's job, it actually is still helpful as I have separated the algorithm out so, I can simply change scheduling parameters machine to machine and achieve optimization without accidentally messing up my algorithm (basically debugging in case of a mess up will be easier)
HLAHat
I agree. There is always a tradeoff though as being able to interleave scheduling and algorithms could potentially lead to even greater optimization, but I think the risks you state could be a greater problem more often. The separation of algorithm and scheduling code can lead to simpler debugging and a cleaner implementation for the respective components.
The separation of duties is also key. If the two programmers can do their job without knowledge of the other domain, then it will be much easier and faster for them to implement their portion.
afzhang
This definitely seems like a good idea. A programmer can now write one version of their code (the algorithm) and it'll be portable via Halide to multiple machines.
BigFish
Agree, it separates the algorithm from detail scheduling so that the same algorithm can be easily adapted to different hardware resources. It is much better than rewrite all the code again on different platform.
uncreative
I think that this separation is really wonderful. It allows the programmer to implement one, or maybe several algorithms, and then compare their performance across a huge number of scheduling choices.
It is easy to imagine writing a simple script which evaluates a large number of scheduling choices in halide. In a traditional language, where scheduling choices are implemented in the code, such a script would be impossible to write without implementing several versions of the code.
rokislt10
I agree. Not only does this make it easier to focus on one thing at a time, it would make it easier for two people to collaborate (or work completely separately) on an image processing project. Even if one person were coding the whole thing, he/she would have the option of working on either the systems part or the algorithm at one time.
What do you think about this idea of separation of algorithm and schedule? Do you think it is a good one? Do you think it could cause programmer headache trying to essentially write "two versions" of a program? I'd like to hear your thoughts...
I think its a good idea, usually the guy doing the image processing and the guy who is implementing it on a machine are 2 different guys. More so I might have no systems knowledge so I could just concentrate on the vision part (algorithm).
While as a systems guy I know what I have to work with SIMD vector size, number of cores, cache size so I can concentrate on scheduling.
So maybe it could make it easy for 2 different programmers to do their specific job rather than 1 programmer's headache.
Even as 1 programmer's job, it actually is still helpful as I have separated the algorithm out so, I can simply change scheduling parameters machine to machine and achieve optimization without accidentally messing up my algorithm (basically debugging in case of a mess up will be easier)
I agree. There is always a tradeoff though as being able to interleave scheduling and algorithms could potentially lead to even greater optimization, but I think the risks you state could be a greater problem more often. The separation of algorithm and scheduling code can lead to simpler debugging and a cleaner implementation for the respective components.
The separation of duties is also key. If the two programmers can do their job without knowledge of the other domain, then it will be much easier and faster for them to implement their portion.
This definitely seems like a good idea. A programmer can now write one version of their code (the algorithm) and it'll be portable via Halide to multiple machines.
Agree, it separates the algorithm from detail scheduling so that the same algorithm can be easily adapted to different hardware resources. It is much better than rewrite all the code again on different platform.
I think that this separation is really wonderful. It allows the programmer to implement one, or maybe several algorithms, and then compare their performance across a huge number of scheduling choices.
It is easy to imagine writing a simple script which evaluates a large number of scheduling choices in halide. In a traditional language, where scheduling choices are implemented in the code, such a script would be impossible to write without implementing several versions of the code.
I agree. Not only does this make it easier to focus on one thing at a time, it would make it easier for two people to collaborate (or work completely separately) on an image processing project. Even if one person were coding the whole thing, he/she would have the option of working on either the systems part or the algorithm at one time.