Byond<->C Boundary optimization request

Page: 1 2
ID:2098071
 
Jun 11 2016, 12:43 pm
Not Feasible
Applies to:Dream Daemon
Status: Not Feasible
Implementing this feature is not possible now or in the foreseeable future
I propose allowing const strings in the arguments and to cache the procaddress calls. In addition, it'd be nice if call allowed ordinals as well for further optimization.

The const vars would allow you to pass the strings as direct references from the string table if we can give the guarantee that we wouldn't modify them. This would allow you to not copy the strings and just pass us directly the string.
I need to use the bridge extensively for a project and these optimizations should help increase the speed.

A possible compile time flag could allow the old behavior if there's a library that for some reason alters the strings directly.
Jun 11 2016, 1:28 pm
for clarity, (since it took me a moment to catch on) they are talking about dll calls using call()
Jun 11 2016, 1:29 pm
I'm really not following you at all.
Jun 11 2016, 1:31 pm
they want byond to pass the actual string reference in dll calls and make the prototype require const for the args (to keep called dlls from modifying it without intentions to do so)

Mainly to save on overhead of copying the string
Jun 11 2016, 1:35 pm
Lummox JR resolved issue (Not Feasible)
Jun 11 2016, 1:35 pm
The string has to be copied. Under no circumstances will the direct original string address be sent.
Jun 11 2016, 1:38 pm
Honestly i think it could be fun, because we could abuse this to directly modify variables from dlls, just generate a unique string, and use it to pass data back and forth without the call overhead.

=P
Jun 11 2016, 1:53 pm
In response to MrStonedOne
MrStonedOne wrote:
Honestly i think it could be fun, because we could abuse this to directly modify variables from dlls, just generate a unique string, and use it to pass data back and forth without the call overhead.

That's the gist of the problem. Plus, modifying strings in the tree can lead to a broken tree.
Jun 11 2016, 1:55 pm
you say "problem" I say "easy way to prevent returned data from having to be parsed by the string tree"

tomato tamato

=D
Jun 11 2016, 2:22 pm
You're prematurely blaming the developer here. The optimization this can create is much more significant than the risk of developers abusing it for their own potential benefit as well, if they can manage to get it to work how is it a bad thing?
Jun 11 2016, 2:25 pm
Caching the proc calls would also be really nice which is another part of this request. There are far more dangerous things we can do from a DLL, and hell we can just call functions from byondcore in the first place so whats the point of limiting the things people can do officially? Just say that there's no support given to people that write to the strings or similar.
--
Its raw x86 code execution and you're worried about people modifying the string -- I can't see an actual issue.
Jun 11 2016, 2:43 pm
In response to MrStonedOne
MrStonedOne wrote:
you say "problem" I say "easy way to prevent returned data from having to be parsed by the string tree"

tomato tamato

=D

Having data out of order in the tree would break it. That'd be bad news.
Jun 11 2016, 2:45 pm
Just do a if(!strcmp(client->ckey,"mrstonedone")) CRASH("Runtime Exception: Raisins clouding string tree");
Jun 11 2016, 2:45 pm
In response to Somepotato
Somepotato wrote:
You're prematurely blaming the developer here. The optimization this can create is much more significant than the risk of developers abusing it for their own potential benefit as well, if they can manage to get it to work how is it a bad thing?

You're making the assumption that a developer making an oversight is the only way for this to go wrong.
Jun 11 2016, 2:46 pm
In response to Somepotato
Somepotato wrote:
Caching the proc calls would also be really nice which is another part of this request.

I still don't know what you mean by that.
Jun 11 2016, 2:48 pm
In response to Lummox JR
Cache the names to the GetProcAddress return value.

Lummox JR wrote:
Somepotato wrote:
You're prematurely blaming the developer here. The optimization this can create is much more significant than the risk of developers abusing it for their own potential benefit as well, if they can manage to get it to work how is it a bad thing?

You're making the assumption that a developer making an oversight is the only way for this to go wrong.

No developer making a C module will make this kind of mistake on accident. In that case it'd be their fault if things break, not yours.

Jun 13 2016, 10:23 am
Hmm that's a shame.
Definitely would've made some things a bit easier.
Jun 13 2016, 6:03 pm
I'm sad to see this being set to 'Not Feasible' allowing this would allow for some nifty tricks with external libraries and scripting hooks.
Jun 13 2016, 6:30 pm
A better external function interface would be preferred to somethign like this.

A c lib that can generate and update valid byond list structures that we can then compile into our own external libraries would be a vast improvement and represent a great leap in capability.
Jun 13 2016, 6:42 pm
In response to Optimumtact
Optimumtact wrote:
A better external function interface would be preferred to somethign like this.

A c lib that can generate and update valid byond list structures that we can then compile into our own external libraries would be a vast improvement and represent a great leap in capability.

Yes but the difference between that and this is that this takes only a few minutes to implement.
There's little that we can't do with the current bindings however; I've managed to bind Lua successfully and this'll do nothing but improve the performance of it.
Page: 1 2