Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Halide, a language for image processing and computational photography

halide-lang.org

Post reply on HN
Print view View original

11–20 of 37 posts

Re: Halide, a language for image processing and computational photography

#11

Post by sharpneli »

I cannot shake the feeling that this is just yet another iteration of the usual concept.

If you look at Google Renderscript, Microsoft C++AMP, NV Cuda, OpenCL and whatnot you'll realize that they all do exactly the same thing, difference being only in syntax level (with few caveats, but those are relatively minor). Some being more cumbersome to use than others.

Halide looks neat to use syntax wise but it doesn't seem to make the actual algorithms any easier to write. You still have to do the same mental work on same level as you have to do with OpenCL.

All of these are to eachother what Fortran, Pascal and C are to eachother. Same basic idea in different package. I'm waiting for the first system that is equivalent of C++. Something that really brings new concepts to the table instead of just a different syntax.

Re: Halide, a language for image processing and computational photography

#13

Post by frozenport »

One wonders if you could build an OpenCV interface using Halide to maintain compatibility but also the potential for optimizing across OpenCV function calls?

I want to write in OpenCV, but I also want the compiler to fix everything across function boundaries :-)

Re: Halide, a language for image processing and computational photography

#14

Post by skrebbel »

sharpneli wrote: post #11

I cannot shake the feeling that this is just yet another iteration of the usual concept. If you look at Google Renderscript, Microsoft C++AMP, NV Cuda, OpenCL and whatnot you'll realize that they all do exactly the same thing, difference being only in syntax level (with few caveats, but those are relatively minor). Some being more cumbersome to use than others. Halide looks neat to use syntax wise but it doesn't seem…

> I'm waiting for the first system that is equivalent of C++. Something that really brings new concepts to the table instead of just a different syntax.

Obligatory HN reaction: I'd wait it out for the first Lisp to appear.

Re: Halide, a language for image processing and computational photography

#15

Post by frozenport »

sharpneli wrote: post #11

I cannot shake the feeling that this is just yet another iteration of the usual concept. If you look at Google Renderscript, Microsoft C++AMP, NV Cuda, OpenCL and whatnot you'll realize that they all do exactly the same thing, difference being only in syntax level (with few caveats, but those are relatively minor). Some being more cumbersome to use than others. Halide looks neat to use syntax wise but it doesn't seem…

Did you watch the video? Did you read the article?

This is about optimizing memory locality and parralelism. Its not about getting access to the underlying hardware such as Microsoft C++AMP, NV Cuda, OpenCL.

Re: Halide, a language for image processing and computational photography

#16

Post by linhat »

sharpneli wrote: post #11

I cannot shake the feeling that this is just yet another iteration of the usual concept. If you look at Google Renderscript, Microsoft C++AMP, NV Cuda, OpenCL and whatnot you'll realize that they all do exactly the same thing, difference being only in syntax level (with few caveats, but those are relatively minor). Some being more cumbersome to use than others. Halide looks neat to use syntax wise but it doesn't seem…

  I'm waiting for the first system that is equivalent of C++.
Not gonna happen anytime soon. C++ is much more than just a programming language, it is an entire "ecosystem". You have toolchains, libraries, drivers, APIs, existing software stacks, all written in C++ and able to interface with C/C++ directly, i.e. no translation layer needed. You're not just gonna replace that with a new language.

Sure, Halide may be seen as just some syntactic sugar (much like quite a few bits and pieces of C++11), but it actually provides you with a different level of abstraction than say OpenCl, MPI or OpenMP where you are very specific about e.g. level of concurrency (which heavily impacts the design of your algorithm) while Halide tries to almost completely separate algorithm and scheduling.

Re: Halide, a language for image processing and computational photography

#17

Post by iamsalman »

sharpneli wrote: post #11

I cannot shake the feeling that this is just yet another iteration of the usual concept. If you look at Google Renderscript, Microsoft C++AMP, NV Cuda, OpenCL and whatnot you'll realize that they all do exactly the same thing, difference being only in syntax level (with few caveats, but those are relatively minor). Some being more cumbersome to use than others. Halide looks neat to use syntax wise but it doesn't seem…

I haven't yet given it a spin but it won't be fair to call it just syntactic sugar. The value it provides, besides a little easier to write syntax is abstracting kernel level code. You don't need to specify block/grid size, move memories around CPU/GPU but I doubt if it can match the performance of hand-written OpenCL/CUDA kernels when it becomes to bleeding-edge Imaging performance.

Re: Halide, a language for image processing and computational photography

#18

Post by sharpneli »

iamsalman wrote: post #17
sharpneli wrote: post #11

I cannot shake the feeling that this is just yet another iteration of the usual concept. If you look at Google Renderscript, Microsoft C++AMP, NV Cuda, OpenCL and whatnot you'll realize that they all do exactly the same thing, difference being only in syntax level (with few caveats, but those are relatively minor). Some being more cumbersome to use than others. Halide looks neat to use syntax wise but it doesn't seem…

I haven't yet given it a spin but it won't be fair to call it just syntactic sugar. The value it provides, besides a little easier to write syntax is abstracting kernel level code. You don't need to specify block/grid size, move memories around CPU/GPU but I doubt if it can match the performance of hand-written OpenCL/CUDA kernels when it becomes to bleeding-edge Imaging performance.

You don't also need to specify the block size in OpenCL either. It's just extremely useful to do that.

Re: Halide, a language for image processing and computational photography

#19

Post by sharpneli »

linhat wrote: post #16
sharpneli wrote: post #11

I cannot shake the feeling that this is just yet another iteration of the usual concept. If you look at Google Renderscript, Microsoft C++AMP, NV Cuda, OpenCL and whatnot you'll realize that they all do exactly the same thing, difference being only in syntax level (with few caveats, but those are relatively minor). Some being more cumbersome to use than others. Halide looks neat to use syntax wise but it doesn't seem…

I'm waiting for the first system that is equivalent of C++. Not gonna happen anytime soon. C++ is much more than just a programming language, it is an entire "ecosystem". You have toolchains, libraries, drivers, APIs, existing software stacks, all written in C++ and able to interface with C/C++ directly, i.e. no translation layer needed. You're not just gonna replace that with a new language. Sure, Halide may be seen…

I maybe wrote it badly. Skrebbel said it a lot better. It's about providing something that's on truly higher level.

It's nice that Halide attempts to separate the algorithm and scheduling, however as of now it's also possible in OpenCL too. The implementations are just so bad at it that it's not really useful.

Re: Halide, a language for image processing and computational photography

#20

Post by sharpneli »

frozenport wrote: post #15
sharpneli wrote: post #11

I cannot shake the feeling that this is just yet another iteration of the usual concept. If you look at Google Renderscript, Microsoft C++AMP, NV Cuda, OpenCL and whatnot you'll realize that they all do exactly the same thing, difference being only in syntax level (with few caveats, but those are relatively minor). Some being more cumbersome to use than others. Halide looks neat to use syntax wise but it doesn't seem…

Did you watch the video? Did you read the article? This is about optimizing memory locality and parralelism. Its not about getting access to the underlying hardware such as Microsoft C++AMP, NV Cuda, OpenCL.

I did watch the video. It is a neat idea. However it is something that is already made explicitly possible by OpenCL.

If you write a kernel which doesn't use local memory nor doesn't use the local_id it produces a kernel that is effectively a Halide pipeline stage. The points can be evaluated in arbitrary order (spec says everything is implementation defined).

If we look at the blur example on the video the OpenCL implementation is also free to effectively merge the stages like in Halide. It's because the spec only defines that whatever the previous kernel invocation has written must be visible for the next kernel. Nothing more and nothing less.

Sure OpenCL allows you to fiddle around with low level details, but it also allows you to write completely platform neutral code that is then the responsibility of the platform to actually optimize.

I do agree that Halide allows you to easily explore the different scheduling options, that's something OpenCL is not capable of. In OpenCL you either do it manually or leave it as totally defined by the implementation.

Post reply on HN