231–240 of 244 posts
Earlier quoted context omitted.
GCC with -O3 might try to unroll this loop into a single constant. O(0) is pretty fast.
ITYM "O(1)". "O(0)" is pretty much meaningless.
Alternatively, this could be titled "do you know how much your computer could do in a second but isn't because of bad design choices, overengineered bloated systems, and dogmatic adherence to the 'premature optimisation' myth?" Computers are fast, but not if all that speed is wasted. A recent related article: https://news.ycombinator.com/item?id=13940014
It's wasted only if it's not traded for something else. But it is. A lot of system would simply not exist if we would have waited for people doing it properly because there is a limited pool of very skilled experts and the demand for IT far exceed our ability to supply. Plus writing good code takes a lot of time and resources, but our society changes now so fast that it very well maybe rewritten next year. Hence, we…
Alternatively, this could be titled "do you know how much your computer could do in a second but isn't because of bad design choices, overengineered bloated systems, and dogmatic adherence to the 'premature optimisation' myth?" Computers are fast, but not if all that speed is wasted. A recent related article: https://news.ycombinator.com/item?id=13940014
And made me wonder: for small applications, like the traditional one computer that controls my sales, nothing online... which language would I use? Seems that there are many options for big systems, buj WebServer + Java + (...) seems to be too complex (and slow) for small needs.
Earlier quoted context omitted.
> frag_color returns one pixel Whoa, hang on. Hey I only mean this to be helpful not insulting, but it sounds to me like you may have some misconceptions about the way WebGL works. I know how easily that can be taken the wrong way, especially in text, so again I apologize in advance and I don't mean that to be rude at all. It would be best to back up and understand WebGL. If you're doing image processing in WebGL, th…
>If you're doing image processing in WebGL, then to write many pixels to a framebuffer all at once, you draw a single polygon that covers the entire viewport. Your shader is applied in parallel to all pixels drawn. That is how ShaderToy works, it renders a single quad to the viewport and applies whatever shader you give it, the GPU runs that shader on all pixels rendered. >Whoa, hang on. Hey I only mean this to be he…
You're right; this demo is 1 pass per filter type. None of them require multipass, but the entire demo is multipass. There could be a filter that needed more than 1 pass, but in this case there isn't.
1 pass means: render all pixels in the viewport, and run the shader on all pixels rendered. You've got that part. The trick is you get to access a texture, and the texture is the result of the previous pass. Furthermore, inside the shader, you can address and access any pixels from the previous pass, and you can access multiple pixels from the previous pass to render one destination pixel.
I think the millions of reads you're looking for are the texture() calls happening inside the shader. The [render / render-to-texture / copy pixels / copy texture image] calls process all pixels in the viewport in a single call. The shader applies to all pixels, but a shader only gets to touch any given destination pixel once per render. But the shader can read as many source pixels as it wants.
Because the shaders aren't limited on their reads, but they are limited on their writes, you have to re-organize your algorithm accordingly. You keep reiterating that error diffusion is spreading out from top to bottom, and I keep re-iterating that it has to work differently in WebGL, we've been talking past each other a little bit here.
You're right; you can't spread things out (scatter) using WebGL during a single pass, you can't do the classic Floyd Steinberg implementation the same way you do on the CPU. So it's important to understand that there is another way to do it, and it doesn't look like what you're used to. It doesn't spread things out by pushing error around inside the loop. It spreads things out by letting each destination pixel pull the error from it's neighbors before computing it's own error, rather than pushing it's own error to it's neighbors after computing. This is known as a gather, as opposed to scatter. It is mathematically the same thing, but the order of operations is turned around.
Here's a diffusion demo, it's reaction diffusion, not error diffusion, but ultimately exactly the same diffusion process. Each pass diffuses the previous pass by 1 step.
Earlier quoted context omitted.
> ES6 goodies, like 'let', are actually bad practice... BTW, this is a really good example of why people like to avoid premature optimization. Performance oriented code frequently has to break all the rules, it often goes against all "best practices" for code that isn't performance critical. If you do it too early, you will wreck your codebase's ability to deal with 1- non performance critical code and 2- other perfo…
>using map() has historically been about 10x slower than using a for loop. Wow, really? Any idea why? Seems odd when map() imposes fewer guarantees and can be implemented, in the worst case, with a for() loop...
This also depends on what you're comparing. Map always allocates a new array. In my Chrome 57 right now, map() is 4x slower than new array + a for loop of push().
But it's 100x faster to re-use an existing array... (a for loop of array element assignment)
Earlier quoted context omitted.
Who is funding the developer? Why should they spend $5k (plus the opportunity cost of not using that dev's time on more fruitful pursuits) on 2 weeks of micro-optimization so that their 10,000 users will each experience a speedup so small they'll never even notice (and certainly never pay extra for)? How do you justify that expense?
I'm making a more abstract argument that doesn't have anything to do with money. The time people spend using a piece of software shouldn't be worth less than the time developers spend writing it.
Earlier quoted context omitted.
To be fair, that article is discussing a small bug, not over engineering or dogma. The size of the deal people made over it was more wasteful than the CPU time this (now fixed) bug cost. And FWIW, of all the problems that matter to me and my teams, I find premature optimization to be far, far more wasteful of money and human energy than wasted CPU cycles. There are definitely times to worry about performance, and I f…
By definition an optimization being premature means it's not necessary in the present. For these situations its like taking a loan for technical debt. In the future you may need 10x the resources to fix but in many environments that's acceptable due to company growth, or like you mentioned, spending money on compute rather then Dev time. That said, I've been amazed what the top engineers in the field can design and i…
No, it is premature when it is not necessary for the deployment (at some future point in time).
When I was developing for mobile phones (long before the iPhone), the decision of what to optimize when required some educated guesses where the phone market would be in 6 months, when the application is market-ready. (And: In the end, we did optimize a lot of code that did need no optimization 6 months later, but those optimizations made development work much, much more bearable.)
Earlier quoted context omitted.
>If you're doing image processing in WebGL, then to write many pixels to a framebuffer all at once, you draw a single polygon that covers the entire viewport. Your shader is applied in parallel to all pixels drawn. That is how ShaderToy works, it renders a single quad to the viewport and applies whatever shader you give it, the GPU runs that shader on all pixels rendered. >Whoa, hang on. Hey I only mean this to be he…
Okay, this is good, you're almost there. BTW, I'm doing a bad job of explaining, and I'm sorry. I realize I'm complicating a few things and conflating a few things, so the best advice I can give is to actually go through that tutorial on image processing and write the code and understand the whole pipeline. You're right; this demo is 1 pass per filter type. None of them require multipass, but the entire demo is multi…
That makes significantly more sense now. I thought you were saying I could do normal floyd-steinberg sequentially somehow.
I am unsure on the mathematical implimentation, but I will keep looking at this. I would think there would be a paper on this method somewhere.
I really appreciate the time you've taken to respond. Not many webgl people out there that can actually point out how it all works and whats possible, and I definitely learned something.