Unfortunately it looks like they did it wrong, by providing explicit GPU types and functions, instead of converting unmodified Octave code to run directly with GPU acceleration implicitly:
It would be awesome if Octave got implicit GPU acceleration in the browser with something like OpenCL. Unfortunately it looks like OpenCL was never ported to WebGL, so WebCL isn't implemented yet:
It's always astonishing to me how the obvious path is rarely taken by industry, because writing open solutions is self-evidently less profitable than writing proprietary ones. Look up the history of the blue LED and countless other innovations to see how that works and why.
I'm hopeful that AI will relieve programmer burden enough that we can explore these obvious roads not traveled. Because we're off on a very long tangent from what mainline computer science evolution might have looked like without tech's wealth inequality.
Unfortunately I see two major (rarely discussed) pitfalls looming with AI:
1) Every tech innovation brings a higher workload for the same pay. The amount of knowledge required to be a full stack developer in 2025 in higher than in 2015, which was higher than in 2005, which was higher than in 1995, and so on. Yet starting pay has not increased with inflation.
2) With AI bringing pair programming everywhere, we may see a decline in overall code quality if humans don't have to deal with it directly. Extended pair programming can lead to over-engineered codebases that can only be read by teams of humans instead of individuals. So whereas one untrained hobbyist could build a website in 1995 using principles like data-driven design, declarative programming and idempotence, today it requires a team to untangle the eventualities of imperative nondetermistic async code that from a user perspective is equivalent to simply hiding the progress bar in the browser.
That's why I'm such a proponent of alternative methods. Abstractions that are quite verbose to represent in, say, Python, can be expressed as one-liners in Octave. The only way to get more concise would be to move towards more of a functional assembly language...
Always found the attraction is buried all those issue bursting enjoyment by the author. Should the diagram be up front and possibly the next release features … then the making of or the issue of making of …
For anyone else who hadn’t heard of JupyterLite — it’s like Jupyter Notebook/Lab, but it runs completely in your browser. No servers, no backend — everything executes client-side.
6 comments
[ 157 ms ] story [ 1295 ms ] threadOctave could be embedded as a C library for some time:
https://stackoverflow.com/questions/9246444/how-to-embed-the...
https://docs.octave.org/latest/Standalone-Programs.html
There is an OpenCL package to provide GPU acceleration:
https://gnu-octave.github.io/packages/ocl/
Unfortunately it looks like they did it wrong, by providing explicit GPU types and functions, instead of converting unmodified Octave code to run directly with GPU acceleration implicitly:
https://octave.sourceforge.io/ocl/function/oclArray.html
It would be awesome if Octave got implicit GPU acceleration in the browser with something like OpenCL. Unfortunately it looks like OpenCL was never ported to WebGL, so WebCL isn't implemented yet:
https://en.wikipedia.org/wiki/WebCL
https://www.khronos.org/webcl/
WebCL is apparently being replaced by WebGPU:
https://stackoverflow.com/questions/11532281/how-to-use-webc...
https://gpuweb.github.io/gpuweb/
https://developer.chrome.com/docs/capabilities/web-apis/gpu-...
- unsolicited opinion -
It's always astonishing to me how the obvious path is rarely taken by industry, because writing open solutions is self-evidently less profitable than writing proprietary ones. Look up the history of the blue LED and countless other innovations to see how that works and why.
I'm hopeful that AI will relieve programmer burden enough that we can explore these obvious roads not traveled. Because we're off on a very long tangent from what mainline computer science evolution might have looked like without tech's wealth inequality.
Unfortunately I see two major (rarely discussed) pitfalls looming with AI:
1) Every tech innovation brings a higher workload for the same pay. The amount of knowledge required to be a full stack developer in 2025 in higher than in 2015, which was higher than in 2005, which was higher than in 1995, and so on. Yet starting pay has not increased with inflation.
2) With AI bringing pair programming everywhere, we may see a decline in overall code quality if humans don't have to deal with it directly. Extended pair programming can lead to over-engineered codebases that can only be read by teams of humans instead of individuals. So whereas one untrained hobbyist could build a website in 1995 using principles like data-driven design, declarative programming and idempotence, today it requires a team to untangle the eventualities of imperative nondetermistic async code that from a user perspective is equivalent to simply hiding the progress bar in the browser.
That's why I'm such a proponent of alternative methods. Abstractions that are quite verbose to represent in, say, Python, can be expressed as one-liners in Octave. The only way to get more concise would be to move towards more of a functional assembly language...
It is a great example of GNU's contribution to the advancement of human kind.
It is highly recommended for numerical mathematics and can be extended with GNU-Fortran or GNU-C. It comes bundled with many extensions.
It is mostly a DSL for numerics.
Scilab is another recommended similar package but comes with less extensions.
* c++ * python * R * lua * javascript
Try them here:
* https://jupyter.org/try-jupyter/lab/ * https://jupyterlite-xeus.readthedocs.io/en/stable/lite/lab/i...
Or create your own deployments by using this template repo: * https://github.com/jupyterlite/xeus-lite-demo