181–190 of 244 posts
Earlier quoted context omitted.
WebAssembly and languages compiled to JS make it immaterial.
I'm not sure how. WebAssembly is more limited than JavaScript (e.g. no access to DOM), and also more limited than native code (e.g. much more limited threading story).
Earlier quoted context omitted.
It's remarkable how much better software feels when the software was developed on a slow machine. Unfortunately devs invest in the fastest equiplent, so they don't experience how their code runs on the average end user who doesn't upgrade every couple years. In can be useful to test your code in a VM that is deliberately slowed down, so can get a feel for user experience on a slower machine. Then you'll know what par…
> Unfortunately devs invest in the fastest equiplent, so they don't experience how their code runs on the average end user who doesn't upgrade every couple years. As someone who doesn't spend much on computer upgrades, I notice this everywhere . Especially when it comes to web development, where everything is optimized for chrome on mac. Don't have a laptop made in the last year? Enjoy a janky-scrolling slow-loading…
Earlier quoted context omitted.
Well the obvious answer would be, eliminate the loop, which is what any compiler optimizer will do ;) But let's assume that the operation is not quite so trivial like here, then this structure would be a prime example where each loop operation is independent from each other, so you can sum a vector in parallel (=SIMD) and then sum the vector once in the end. Also, since we're obviously not using any compiler optimiza…
When you say "eliminate the loop", do you mean loop unrolling? They are compiling with -O2, I'm not sure if that does loop unrolling. If it does, how much unrolling does it do, exactly? I can't imagine it would construct a block of code with a billion add instructions.
Anything that is easily expressed as a set of simple recurrences that can be solved, it'll solve.
Earlier quoted context omitted.
>An eye-opening experience is running an IDE like Visual Studio 6 or a really old version of Photoshop on a modern machine. It starts instantly, compile times are a fraction of what we're used to. The interface is totally responsive. If you gave that to a Product Manager candidate (as part of an interview) and pretended it's your current product (assume they didn't know it already), asked them to play around with it…
A lot of places I've worked had government incentives to do this too. Adding features is "R&D" and attracts less payroll tax than optimizing bugs does. Other companies structure themselves this way, a feature is something you can charge to another department, an optimization isn't.
Yes, modern computers are fast. How fast? The speed of light is about 300,000 km/s. That translates to roughly 1 ns per foot (yeah, I mix up my units... I'm Canadian...) THUS, a computer with a clock speed of 2 GHz will be able to execute, on a single core/thread, about 4 (four !) single-clock instructions between the moment photons leave your screen, and the moment they arrive into your eye 2 feet (roughly) later. _…
Yes, modern computers are fast. How fast? The speed of light is about 300,000 km/s. That translates to roughly 1 ns per foot (yeah, I mix up my units... I'm Canadian...) THUS, a computer with a clock speed of 2 GHz will be able to execute, on a single core/thread, about 4 (four !) single-clock instructions between the moment photons leave your screen, and the moment they arrive into your eye 2 feet (roughly) later. _…
The obvious conclusion is that by doubling your distance to the screen, you double your computers speed! ;-) (in truth, I really like this image, though. On a similar note, I think I recently saw a number for the length of wiring in a modern cpu (ryzen review perhaps) - and it was a rather staggering number from the fractal layout of modern chips - 200 meters perhaps? In a square little more than 2 cm to a side, if t…
http://m.cacm.acm.org/magazines/2017/1/211094-exponential-la...
Earlier quoted context omitted.
Let's be clear, I dislike slow apps, I think current behemoth web pages size is a monstrosity and every time I start an electron app (minus the excellent vscode), I scream in my head. Yet. Most electron app I tried have a ratio result/effort far better than any other solutions for the dev.
This cannot be understated. It really can't. The programmer in me will always be drawn to small, lightweight code that gets the job done while using minimal resources. But that programmer is an algorithmic designer, which doesn't often need to deal with the realities of UI, graphics card drivers, or cross-platform compatability. Electron is popular precisely because it enables developers of nearly any skill level to…
What makes you think desktop programmers have to deal with graphics drivers? How is electron any better than desktop toolsets worse at dealing with the realities of UI work?
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…
And we'd be better off. We'd be better off without Atom and VS Code.
Earlier quoted context omitted.
Why do we care so much about the dev? There are way more people who use a typical program than there are people who develop it, and these people often use the program more frequently than the developers make changes to it. For example, if a feature is used every day for a year by 10,000 people, speeding it up by 200ms is worth over a month of developer time (200ms for 10,000 people over a year is 203 hours of time wa…
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?
It makes it harder for your competitors to offer a better product.
Earlier quoted context omitted.
Random-order dithering can be done in WebGL, but they are of poor quality. I am talking about error-diffusion dithering, where you are reading and writing pixels, and then re-reading those modified pixels that change the rest of the pixels. In WebGL, you can read the pixels of the image, but you cannot modify and read. You are returning the actual pixel you have modified, which is what glReadPixels() returns. You cou…
Yes, ordered dither is easier in a shader than error diffusion, that's true, but error diffusion is definitely possible on a GPU. If you need it. Do you really need it? Why not still use the GPU to accelerate whatever parts you can? Even if you dither on the CPU, doing your color filters on the GPU instead of in JS could make the difference between interactive and not. I don't know what you're doing exactly, but when…
Dithering requires quantization. If you mean things like brightness and contrast, yes, webgl is better for that. But quantization with error diffusion dithering is still based upon previous modified pixels, so you cannot just send a bunch of pixel info to webgl, you have to do each pixel seperately. Meaning, pushing through 2.5Million seperate inputs sequentially, and having to use glReadPixels() 2.5Million times.
>BTW, random order is lower quality, and error diffusion is better, only for for very low res color palettes.
Not in any of the images I have used. Ordered dithering looks fake, because it appears like a texture to the image. Dithering with error diffusion kernels, like Floyd-Steinberg create a less obvious texturization that still preserves the underlying image.
>https://www.shadertoy.com/view/4dt3W7
From what I'm reading, for every pixel, it is processing a 250 iteration loop that gets the pixels in the row and builds errors based upon those. However, it is not modifying any pixels as it goes, this is a parallel operation independent of each other. Good error diffusion with a kernel requires previous pixels to be modified, and errors to be built upon them, which is why it is a sequential operation. I don't see any destination-dependant pixel manipulation.
>Multiple round-trips from CPU to GPU and back will be slower, so you want to limit the number of trips, but it's easy to do.
If its possible to get data back from Uniform Buffer Objects in WebGL2, it may be possible to send up to 1000 or so uniform pixel values, but that is the general cap. Some GPU's have less. Unless I am missing some magic buffer you can use to write out many pixels too, and in that case I would be very interested in testing that, but shaders are designed to output a single pixel per instance.
>https://community.arm.com/graphics/b/blog/posts/when-paralle...
From what I'm reading, this is using OpenCL, and parrallelizing in rows, but these rows have height. A single thread processes one row and sequentially goes through the pixels like normal error diffusion. Just that this breaks different parts of the image up. I may have to try this out in JS and see if perhaps it can thread better that way. ty.