Global Goal

[9il]

Possible variants:

• Library for D. Disadvantage: D community is really small. Advantage: can be implemented in any programming style including GC + OOP. A project to play with D and have a fun.
• Library written in D. Disadvantage: nothrow @nogc layer should be presented. OOP API should be optional or removed. Advantage: number of users and contributors are limited only by langauge bindings like Python, Julia, Ruby, Rust, and Go (yes, we can build libraries for Rust and Go 😄 I think it is better way to move forward with D ). A professional project that can be live during many-many years.

Library for D in 99% cases is useless as general purpose library. Library written in D is a library for D, which can be used in other languages like a common C library.

[ljubobratovicrelja]

This is really complex topic, so let me start at the beginning.

I recognized mir.ndslice as a serious opportunity for a scientific ecosystem to be established in D, as Python users have with numpy.ndarray. Originally, goal was simply to utilize it with many other cool stuff in D, and to build computer vision library on top of them. So, in your terms, I'd say I was leaning toward the first option.

I see your point with the second option. I feel it is much too early to start discussing the final goal or direction we're following - (e.g. to which languages we'll be binding this library to). I think its OK for now to focus on having to be able to interface with C. So, all algorithms should be nothrow @nogc in base API, and optionally having high level API that can handle exceptions and the GC. This is not the case at the moment, but I think it should be.

Also, one important fact: please keep in mind there are few really powerful projects that we cannot even compete with (at least not at the moment). IMHO if we are going to attract users (and contributors), it will certainly not be with richness and quality of algorithms (at least not for next few years). If person seeks for a library to solve certain problem, he/she will most likely go for well known libraries like OpenCV. I think having beautiful, easy to understand (write and read) API, leveraged with performance is most important for this library. I think D is capable of that, and that is why I chose it! And that's why I ran from other options:

• python/numpy/opencv: really awesome, but you eventually hit the limit and have to resort to C, so often not so good for production use, but for research
• matlab: good, but expensive, and also only for research
• octave: slow and IMHO far from usable even for research
• C/C++ OpenCV: really sucks for reseach, can be good for production code but for any more serious practice you'd implement you're own stuff. And mostly when you do, you're likely to be using OpenCV's base API so that you don't have to implement all the stuff by yourself - and OpenCV's base API sucks (IMHO, of course). Sure it's awesome with lot of algorithms and GPU implementations, but all in all, I'd really not like to depend on it in my production code
• other C/C++ libraries: those I've seen and worked with suffer from same problems as OpenCV because of the language itself.

My idea was to try to take good from each, and try not to inherit bad. :) - Easy to write as with matlab and python, but once compiled fast as C/C++. Hope I'm making sense here...

Advantage: number of users and contributors are limited only by langauge bindings like Python, Julia, Ruby, Rust, and Go

So, if we focus on ease of use in D, how does this idea translate to other languages? I know Python and Julia have powerful replacement for ndslice, which can be used to mimic the original API, I don't have experience with Ruby, Rust and Go. How do you propose we bind this library that heavily relies on ndslice to other languages? (please don't get me wrong - I don't doubt it can be done, I just have no idea how)

Sorry for the long post. This topic requires a good discussion, so fire away! :)

[9il]

Current DCV state is like python/numpy/opencv. It may be faster, but still useless for production. I don't think we need to port existing API to C. Instead, we need to allow users to be able to bind their algorithms based on DCV to other languages. It is possible with OpenCV. To be at least good as OpenCV we need to have algorithms that do not use DRuntime. It should be clear for users what algorithms require DRuntime and what algorithm do not require DRuntime.

[ljubobratovicrelja]

Current DCV state is like python/numpy/opencv. It may be faster, but still useless for production

I think its a lot worse than than - I'm pretty sure it's not faster! :)

To be at least good as OpenCV we need to have algorithms that do not use DRuntime. It should be clear for users what algorithms require DRuntime and what algorithm do not require DRuntime.

This sounds good, but I'm afraid you'll have to explain this bit further. How does this affect our development in future? How do we not use druntime? (sorry, I'm, obviously still new to this)

[bubnenkoff]

@9il could you look at https://habrahabr.ru/post/311568/ and if you have account answer for comments, or write answer here and I will add them to article.

[9il]

@bubnenkoff Thank you for the translation. But it is far from the original text.

[9il]

@bubnenkoff Thank you for the translation. But it is far from the original text.

so, i can not comment all questions. Will comment few ones, after the first comment moderation

[9il]

@ljubobratovicrelja I am sorry for the unrelated discussion

[9il]

This sounds good, but I'm afraid you'll have to explain this bit further. How does this affect our development in future? How do we not use druntime? (sorry, I'm, obviously still new to this)

Algorithms should be nothrow @nogc. Delegates, associative arrays, classes, new, core.sync, core.thread, std.concurrency, and std.parallelism should not be used. We will need our own nothrow @nogc threads and mutexes or use dcompute (i don't know what is simpler)

[ljubobratovicrelja]

@ljubobratovicrelja I am sorry for the unrelated discussion

No worries ;) always glad to see word of Mir spreading!

Algorithms should be nothrow @nogc. Delegates, associative arrays, classes, new, core.sync, core.thread, std.concurrency, and std.parallelism should not be used. We will need our own nothrow @nogc threads and mutexes or use dcompute (i don't know what is simpler)

Well, this doesn't sound so bad except the threading part. Is it possible (wise) to totally ditch traditional CPU threading (posix and windows threads) in favor of OpenCL? What are downfalls of this choice - I suppose user must have OpenCL runtime installed? How would that affect the upper-level algorithm development? Pinging @thewilsonator, suppose he's good man to answer to this kind of question. :)

Also, do you know is there maybe already such threading library on dub base? - with nothrow and nogc. Or would we maybe like to start writing one from scratch?

[9il]

Also, do you know is there maybe already such threading library on dub base? - with nothrow and nogc.

No, I have implemented only cpuid.

Or would we maybe like to start writing one from scratch?

Yes, we can use core.thread code and look into existing C libraries.

[ljubobratovicrelja]

Yes, we can use core.thread code and look into existing C libraries.

Awesome, sounds good! How do we act with DCV until we have working version of such library? But anyways, I'd like to keep the focus on development of new algorithms in next period, so parallelization (and micro-optimization) will not be that important. By the time we have collection of new algorithms I suppose we'll have working version of such library to use and parallelize written algorithms in DCV. Sounds good? Or do you propose different strategy?

[9il]

Sounds good?

Yes. current task pool can be used for now. But loops bodies should be nothrow @nogc

[ljubobratovicrelja]

OK, great!

[9il]

Another important point is that algorithm's API should feel solid. Currently each major algorithm has its own API style, which is bad for big library

[ljubobratovicrelja]

Currently each major algorithm has its own API style, which is bad for big library

Agree! This is something I really wanted to address to with everyone involved with DCV development at some point. I was referring partially to this problem in second post in #64. Thank you for noting this!

[thewilsonator]

Well, this doesn't sound so bad except the threading part. Is it possible (wise) to totally ditch traditional CPU threading (posix and windows threads) in favor of OpenCL? What are downfalls of this choice

In order to use OpenCL in the first place I need to get my compiler changes into ldc, and the review is taking longer than I had hoped, and not help by the imminent release of 1.1.0. Then I need to get libmir/dcompute into a working shape, and then integrate it with mir.

So it will take some time before it is ready, but so will a multi-threaded mir. So assuming that we can get seamless and painless, and as transparent as possible integration. I don't think there any downfalls.

I suppose user must have OpenCL runtime installed?

Correct.

How would that affect the upper-level algorithm development?

I don't think it would, at least not dramatically, because the style will be largely the same and some code will be reusable across the host and device. and the upper-level algorithms should be mostly composition of lower level ones anyway.

Perhaps @John-Colvin would have more insight on this.