That will add a vast overhead (loading, calling, passing parameters, receiving data back) and complexity to devs. Not really useful for simple unsafe tricks squeezing bits and milliseconds inside (inline) Xojo code.
But that’s the thing. Xojo is not about allowing “simple unsafe tricks”. We go to great lengths to make it so you can’t shoot yourself in the foot, so if you really think you need to squeeze every little bit of speed from a complex mathematical formula, you should write a plugin to do it.
Sometimes we just need some matrix thing mixing bits and sending it out to some chip inline as fast as possible, a “simple” functionality that would be a shame to write a plugin with someone else’s external C compiler, just for such thing.
I do accept, and I feel, that your major real concern, is that introducing such thing in the language will have a cost. A cost of time and complexity, that you guys don’t want to face anytime soon.
The intern on that gig had a sweet job! Boss: (walking in) “what you doing now?” Intern: (quickly hides XKCD window) “Still Compiling!”
So is GLSL, you can write it inline (in a string), then create a CIKernel from it and execute it on the GPU, or use multi-threaded CPU processing.
You’d have to create a memoryblock that represents a picture and use the ‘pixel’ values as your source (some can be passed directly to the CIKernel), then render it out to a memoryblock and extract the values from a pixel. You’ll be limited to just Uint8, Uint16, half float or single.
Apple makes this is easy (ha!) with Core Image, while I know GLSL is portable, I’ve never tried it on other platforms.
GLSL is a non-precompiled shader language with a very specific and limited domain. Not a lower level, general purpose, unsafe, almost unlimited language, used to insert near to the metal code, inline, mixed with the higher level, safer, more limited, language.
I realize that it’s not an exact match, just that it is something you can do today, providing the circumstance are suitable. What I don’t understand is how the GPU can be faster, with non-precompiled code than a compiled application running across multiple cores.
For example, in my tests the other day, rendering a 12 mpx (128-Bit) image took 12 seconds on the GPU (when breaking it down into multiple mini renders), yet when done on an 8-core processor (same machine and the same mini-renders), it took 44 seconds with the application utilizing almost 800% CPU. It’s such a huge difference.
[quote=416334:@Bob Keeney]So we’re getting the “passive - aggressive” compiler mode then? 
FTR this is the best comment I have ever read on this forum, so perfect.
[/quote]
I develop 11 apps with xojo in my sparetime. I built 2 of them in agressive mode just to see (usually I build in default).
In the first app, I tested the rotate of a picture 90°. I use a method I found here in the forum, I have two loops which invert coordinate of each pixel. I didn’t see any difference with normal mode.
In the second app which synchronize 2 folders, I loop recursively in 2 folders (Source and Target) and I compare name and modification date of each file. I didn’t see any difference either. (I didn’t test the copy time as I didn’t copy any file, this time is limited by disk speed).
The only difference I noticed is the build time. I do not need more speed, I’m happy with default optimization. I did a test just to see and I’m surprise there is no difference. Maybe it does optimize other kind of process?
My Bcrypt test code, in aggressive move, takes about 280 ms. In moderate, it takes about 330 ms.
In default, it takes 3-4 seconds, so yes, for some code it can make a huge difference.
[quote=417027:@Kem Tekinay]My Bcrypt test code, in aggressive move, takes about 280 ms. In moderate, it takes about 330 ms.
In default, it takes 3-4 seconds, so yes, for some code it can make a huge difference.[/quote]
My main application has an important use of numeric analysis (matrix analysis) and with aggressive mode is about eight times faster than with normal mode. Waiting 1 minute for the result is something bearable, but waiting 8 minutes is impossible. I agree that aggressive mode can make a huge difference.
I vote for the opposite option 
A super fast compile mode that doesnt do any of that stuff so that when im doing iterative debugging I dont have to wait so long between hitting run and having anything happen
These are not mutually exclusive.
In Windows? In Linux? In Android? Regardless checking if the underlying hardware have a GPU? To pre-process vectors of numbers and strings, order, and filter then WHILE sending data to a non-graphical IoT device WHILE reading changing bits of status from the device?
As I said, GLSL, when present, works for a very specific and limited domain. I think that as you work tirelessly with Macs and graphics, your mind is working much in focus with the subject. And I say all this with a HUGE respect for your work, I hope no one read my words in a bad tone. 