On 27 December 2016 at 18:51, Ian Mallett <i...@geometrian.com> wrote:
> > >> Most interesting that 1. method with buffer write seems to be always >> faster >> than others, by ca. 5%. Not a big win, but still interesting... >> And if I try it with FORTRAN order, it becomes 2 times slower! >> > I'm not sure I fully parse what you're doing here. As long as it's safe, > copying buffers should be slightly faster since it's 1D--maybe the buffer > API is smart enough to step in larger chunks that might potentially > straddle a scanline, and you also have one fewer loop variable. When you > try it with FORTRAN order, to produce a buffer of the same format would > require an allocation and then a copy, so that's probably why it's slower. > > The NumPy internals > <https://docs.scipy.org/doc/numpy/reference/internals.html#multidimensional-array-indexing-order-issues> > has salient things to say on this issue. > Good article, it explains good what I observe. And that is right, pixelcopy seems to do much more checking, I think I saw 4 different error messages when I was trying different inputs. > So I would still look forward to having methods dealing with C order, >> just to avoid writing extra transposing and full compliance >> with default numpy notation. >> >> Any comments or opinions about it? >> It would be good to know first, which of those things >> people use more often and make some use case examples. >> > Personally, I would like C order just because it's "expected" in > graphics*. Under this assumption, I wrote all my code e.g. looping over "y" > first, using the buffer API for GL interop, etc. This is optimal in the C > order every graphics programmer would expect, but in FORTRAN order, it's > *exactly* wrong. I never profiled both options because it's a nearly > fundamental assumption. > Agreed, also one who is already familiar with Numpy, or e.g. OpenCV is already got used to [y,x] notation, so from many sides, it would be logical to use C order for array-surface ingest. > > I mean, it's not terribly important. Python is not a fast language. One > writes stuff in Python because your program running 5x/50x slower is a > non-issue and you want the expressivity. But free perf is free, so it's a > bit annoying. > Yes this is a big dilemma. There is an opinion, one should make everything in C/+, and most industry-level products are done so. But seriously, I can hardly see the *code* behind all those brackets, asterisks, cryptic expressions. So for me it is almost no-go, but as a grafic-man I am just too sensitive to these things :) I see there is a good solution to all this: one needs a nice tool, namely an IDE with refined simple syntax, which produces C-compilable code. I mean if one concentrates around this, it is not that hard to make. Strangely I don't find much exactly related projects, one attempt probably is SDL Basic. Cython is related, but not exactly. This idea floats for years in air, hmm, what could be preventing it, I wonder. I mean I don't even consider myself a professional programmer, but it seems, making a toy-prototype of such IDE is a question of several months of "free evenings" job. And actually to make such a tool, even Python+Pygame would be totally adequate, since it does not need to be so performant as a complex game. Mikhail
