3 ms·

Results are impressive with "snake image segmentation" alone but OK with other algos. http://people.csail.mit.edu/jrk/halide12/ http://people.csail.mit.edu/jrk/

by yogrish 14y ago

Results are impressive with "snake image segmentation" alone but OK with other algos. http://people.csail.mit.edu/jrk/halide12/ http://people.csail.mit.edu/jrk/halide12/ I didn't get how algorithms expressed in this language are faster, if it is just a 'Representation'. Is it because of its efficiency in parallelization? If so, any hand tuned assembly should be on par with it. any other thoughts? Btw, the title "Writing graphics software..." is misleading as 'Halide' addresses only Image processing on CPU/GPU but nothing to do with 3D/2D graphics software.

lusr 14y ago
I have some utility for image processing algorithms but I am no expert in the field, nor do I have any desire to become one - I just have some ideas I want to implement. The idea that I can write my algorithms in this language and target them at the CPU initially (to keep costs down while focusing purely on photo processing), then have it running on Amazon's EC2 GPU infrastructure later with no changes when I want to (and can afford to) expand into video processing is pretty awesome. And all of that while having the code apparently run faster than hand tuning (which I have no interest in doing) would allow. Implementing a parallalizable hand-tuned algorithm does seem like it should be faster, but even if that were true I don't have the time or expertise for attempting that.
bazzargh 14y ago
If you read the paper, you'll see that the detail is a little different from the headline claim. In section 6.3 they go through comparing C++ at various levels of optimization to equivalent Halide code, and eventually reach C++ code that is faster than the Halide code. However, to do that, even the tuned C++ ballooned from 122 lines of code to 370+ lines, while the Halide implementation was 35 lines, and had allowed them to discover optimizations quickly, by separating the concerns of the algorithm and scheduling. The C++ code is also now very specific to the architecture it's tuned for. So the win here is in terms of maintenance and effort, and the ease of porting to different architectures. Hence, I expect, why they also show comparisons with Matlab.

by yogrish 14y ago

lusr 14y ago

I have some utility for image processing algorithms but I am no expert in the field, nor do I have any desire to become one - I just have some ideas I want to implement. The idea that I can write my algorithms in this language and target them at the CPU initially (to keep costs down while focusing purely on photo processing), then have it running on Amazon's EC2 GPU infrastructure later with no changes when I want to (and can afford to) expand into video processing is pretty awesome. And all of that while having the code apparently run faster than hand tuning (which I have no interest in doing) would allow. Implementing a parallalizable hand-tuned algorithm does seem like it should be faster, but even if that were true I don't have the time or expertise for attempting that.

bazzargh 14y ago

If you read the paper, you'll see that the detail is a little different from the headline claim. In section 6.3 they go through comparing C++ at various levels of optimization to equivalent Halide code, and eventually reach C++ code that is faster than the Halide code. However, to do that, even the tuned C++ ballooned from 122 lines of code to 370+ lines, while the Halide implementation was 35 lines, and had allowed them to discover optimizations quickly, by separating the concerns of the algorithm and scheduling. The C++ code is also now very specific to the architecture it's tuned for. So the win here is in terms of maintenance and effort, and the ease of porting to different architectures. Hence, I expect, why they also show comparisons with Matlab.