coffeedujour commented at 2023-04-28T01:33:37Z

Actual specific use cases ?

Jabadahut50 commented at 2023-04-28T08:22:33Z

Faster compression and decompression algorithms, faster physics calculations when your use case can't use or is better off not using sl's havok physics, faster bitwise flag checking and parsing, etc.

You could use it for all sorts of things where you need to use bulk math or logic.

JIRAUSER341305 commented at 2023-04-29T00:28:01Z

Bit late for April Fools, isn't it…?

Seriously, though.  The cost of passing the data in as a list (heap allocated array of heap allocated items), and lists are immutable, so passing a fresh list back out again with the results, is going to blow away any savings you'll get by using this function over just doing it the slow way, quite possibly by an order of magnitude…

It "could" work, maybe, if we had 8 global variables to load the data into (kind of like "registers", and it'd have to be a bank for each value type, so, 16 to support both floats and integers), and then the function takes just a single integer (maybe a second for the fan-out form, but I think I'd just use an unused register for that) containing the operand and other supporting state (like selecting which bank of "registers" to use, etc.).  And even then I have doubts.

Pretty sure you're not going to be doing any useful compression (with the about 20:1 expansion ratio of the data, and the lack of binary support in LSL — unless we got perhaps hex in a string as a third data type), or physics (the slow crawl of LSL compared to an actual compiled and optimised language not withstanding, we simply don't have access to that kind of raw instantaneous data to be of much use for physics — rough mathematical approximations are far more LSLs domain, and actually in reach).

That all said, a bulk math function modelled on SIMD and along the lines of llListStatistics, could indeed be handy.  I've considered similar in the past, but decided it was unlikely to be worth it.  Even in the list form, if it allowed any number of values in, and returned the appropriate number of results, probably two lists in and one list out (the second list holding just a single item in the fan-out form)…  It'd at least beat the pants off looping over a list…  (Be even more useful if we had destructuring.)  But in terms of speed benefits, you'd likely get better results hacking together a piece of Python to print out the LSL code to do the calculation you want, and then copy-paste that into your script.

So after all this, being as generous as I possibly can (because as I said, I've considered the idea myself in the past), I too still being it back to Coffee's response: Actual specific use cases ?

Jabadahut50 commented at 2023-04-29T15:24:18Z, updated at 2023-04-29T18:32:16Z

@Bleuhazenfurfle

I wasn't aware of lists immutability given they can be modified and appended to at the lsl level. I suppose I should have done a bit more research on exactly how LSL works under the hood before making a recommendation.

I could see the bank of "registers" thing working rather than trying to pull from a list given the immutability of Lists under the hood.

Quistess Alpha over in the forums brought up the idea of llStridedListStatistics that would allow any number of integers and floats in and letting the dev's implement SIMD under the hood for it rather than an explicit SIMD function. The initial implementation written above was naively based upon how other languages implement it but looking back now that was a dumb decision on my part as that just doesn't make sense with LSL given the constratints of the language. Destructuring would indeed be a very nice addition.

Personally I'm working on an ECS like system using LSL that would greatly benefit from mass math and logic speed ups (Yeah I know LSL isn't necessarily designed in a way where an ECS System would actually be fast even with faster math but I'm doing it mostly for the sheer interest of seeing if I can do it at all)

I'll rework the idea to take your and Quistess's reccomendations into account.

Shrike Linden commented at 2023-05-10T18:05:31Z

Hello, and thank you for your feature request.

Incoming suggestions are reviewed in the order they are received by a team of Lindens with diverse areas of expertise. We consider a number of factors: Is this change possible? Will it increase lag? Will it break existing content? Is it likely that the number of residents using this feature will justify the time to develop it? This wiki page further describes the reasoning we use: http://wiki.secondlife.com/wiki/Feature_Requests

This particular suggestion, unfortunately, cannot be tackled at this time. However, we regularly review previously deferred suggestions when circumstances change or resources become available.

We are grateful for the time you took to submit this feature request. We hope that you are not discouraged from submitting others in the future. Many excellent ideas to improve Second Life come from you, our residents. We can’t do it alone.

Thank you for your continued commitment to Second Life.