Hi guys, I'm doing some "advance callbacks" for Mars, and I'm having several problems with table renderers (they are called A LOT of times and needs to be efficient). The ObjectiveCBridge is not as efficient as that calls needs to be executed, and well... I was planing to spend some time on this, trying to see how can I improve the callback velocity. And then a question came to my mind:
do I spend time improving current ObjectiveCBridge implementation... or I better use Alien and migrate everything to it?
some context:
1) it was always planned to "sonner or latter" migrate the ObjectiveCBridge stuff to alien (there is another . 2) Alien is not working -yet- for iPhone. It is planned (bah... it is "thought") to run Alien in iPhoneVM too. 3) Alien callback implementation is a lot cleaner than the current ObjectiveCBridge implementation (which relies on both sides semaphores, when alien callbacks relies on "image ownership")
So... it will delay a little a release of Mars? sure it will... but in the long way it will be better.
I would like to hear your opinions,
cheers, Esteban
On 23 December 2010 20:35, Esteban Lorenzano estebanlm@gmail.com wrote:
Hi guys, I'm doing some "advance callbacks" for Mars, and I'm having several problems with table renderers (they are called A LOT of times and needs to be efficient). The ObjectiveCBridge is not as efficient as that calls needs to be executed, and well... I was planing to spend some time on this, trying to see how can I improve the callback velocity. And then a question came to my mind:
do I spend time improving current ObjectiveCBridge implementation... or I better use Alien and migrate everything to it?
some context:
- it was always planned to "sonner or latter" migrate the ObjectiveCBridge stuff to alien (there is another .
- Alien is not working -yet- for iPhone. It is planned (bah... it is "thought") to run Alien in iPhoneVM too.
- Alien callback implementation is a lot cleaner than the current ObjectiveCBridge implementation (which relies on both sides semaphores, when alien callbacks relies on "image ownership")
.. So... it will delay a little a release of Mars? sure it will... but in the long way it will be better.
i wanted to offer a NativeBoost, but it is not ready for use under MacOS yet :)
About iPhoneVM - definitely, you will need to use something else than NB.
And Eliot also having somethings to offer :)
I would like to hear your opinions,
cheers, Esteban
Hi,
Is it possible to statically save code from NB native methods to platform shared library? And if It's true NB can just create shared library on fly and use it.
2010/12/23 Igor Stasenko siguctua@gmail.com
On 23 December 2010 20:35, Esteban Lorenzano estebanlm@gmail.com wrote:
Hi guys, I'm doing some "advance callbacks" for Mars, and I'm having several
problems with table renderers (they are called A LOT of times and needs to be efficient). The ObjectiveCBridge is not as efficient as that calls needs to be executed, and well... I was planing to spend some time on this, trying to see how can I improve the callback velocity. And then a question came to my mind:
do I spend time improving current ObjectiveCBridge implementation... or I
better use Alien and migrate everything to it?
some context:
- it was always planned to "sonner or latter" migrate the
ObjectiveCBridge stuff to alien (there is another .
- Alien is not working -yet- for iPhone. It is planned (bah... it is
"thought") to run Alien in iPhoneVM too.
- Alien callback implementation is a lot cleaner than the current
ObjectiveCBridge implementation (which relies on both sides semaphores, when alien callbacks relies on "image ownership")
.. So... it will delay a little a release of Mars? sure it will... but in
the long way it will be better.
i wanted to offer a NativeBoost, but it is not ready for use under MacOS yet :)
About iPhoneVM - definitely, you will need to use something else than NB.
And Eliot also having somethings to offer :)
I would like to hear your opinions,
cheers, Esteban
-- Best regards, Igor Stasenko AKA sig.
On 23 December 2010 21:24, Denis Kudriashov dionisiydk@gmail.com wrote:
Hi,
Is it possible to statically save code from NB native methods to platform shared library? And if It's true NB can just create shared library on fly and use it.
it is possible (if someone provide a code), but i wonder why do you need such extra loops? It will give you nothing. You could generate a native code and put it into executable memory region, instead of object memory, which could be then used to pass as callback address to some external function. Actually, if you look how NB callback test implemented - it does exactly what i describing.
You can always use NB (or just AsmJit) for generating code and putting it into static library or file.. but once it become static it is no longer interesting, because its static (yeah.. tautology ;)
I just think about a way to use NB on platform that permit execution of dynamicaly generated code
2010/12/23 Igor Stasenko siguctua@gmail.com
On 23 December 2010 21:24, Denis Kudriashov dionisiydk@gmail.com wrote:
Hi,
Is it possible to statically save code from NB native methods to platform
shared library?
And if It's true NB can just create shared library on fly and use it.
it is possible (if someone provide a code), but i wonder why do you need such extra loops? It will give you nothing. You could generate a native code and put it into executable memory region, instead of object memory, which could be then used to pass as callback address to some external function. Actually, if you look how NB callback test implemented - it does exactly what i describing.
You can always use NB (or just AsmJit) for generating code and putting it into static library or file.. but once it become static it is no longer interesting, because its static (yeah.. tautology ;)
-- Best regards, Igor Stasenko AKA sig.
On 12/23/2010 12:47 PM, Igor Stasenko wrote:
it is possible (if someone provide a code), but i wonder why do you need such extra loops? It will give you nothing.
Unless the platform does not allow making memory regions executable, as on, say, iOS. In which case the ability to generate code into a shared lib becomes suddenly very valuable.
Cheers, - Andreas
You could generate a native code and put it into executable memory region, instead of object memory, which could be then used to pass as callback address to some external function. Actually, if you look how NB callback test implemented - it does exactly what i describing.
You can always use NB (or just AsmJit) for generating code and putting it into static library or file.. but once it become static it is no longer interesting, because its static (yeah.. tautology ;)
On 23 December 2010 22:04, Andreas Raab andreas.raab@gmx.de wrote:
On 12/23/2010 12:47 PM, Igor Stasenko wrote:
it is possible (if someone provide a code), but i wonder why do you need such extra loops? It will give you nothing.
Unless the platform does not allow making memory regions executable, as on, say, iOS. In which case the ability to generate code into a shared lib becomes suddenly very valuable.
Unless there is a restrictions imposed which do not allow to use dynamically generated code, which suddenly makes all efforts worthless. :)
Cheers, - Andreas
You could generate a native code and put it into executable memory region, instead of object memory, which could be then used to pass as callback address to some external function. Actually, if you look how NB callback test implemented - it does exactly what i describing.
You can always use NB (or just AsmJit) for generating code and putting it into static library or file.. but once it become static it is no longer interesting, because its static (yeah.. tautology ;)
Well I"m not sure what is being suggested here, but on iOS a shared library is marked as read and executable, NOT writable. so you can't do self modifying code... Unless you are saying you'd like to on macintel generate arm code and stick it into a shared library for later loading and execution on iOS?
On 2010-12-23, at 1:04 PM, Andreas Raab wrote:
On 12/23/2010 12:47 PM, Igor Stasenko wrote:
it is possible (if someone provide a code), but i wonder why do you need such extra loops? It will give you nothing.
Unless the platform does not allow making memory regions executable, as on, say, iOS. In which case the ability to generate code into a shared lib becomes suddenly very valuable.
Cheers,
- Andreas
You could generate a native code and put it into executable memory region, instead of object memory, which could be then used to pass as callback address to some external function. Actually, if you look how NB callback test implemented - it does exactly what i describing.
You can always use NB (or just AsmJit) for generating code and putting it into static library or file.. but once it become static it is no longer interesting, because its static (yeah.. tautology ;)
-- =========================================================================== John M. McIntosh johnmci@smalltalkconsulting.com Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
On 12/23/2010 2:49 PM, John M McIntosh wrote:
Well I"m not sure what is being suggested here, but on iOS a shared library is marked as read and executable, NOT writable. so you can't do self modifying code... Unless you are saying you'd like to on macintel generate arm code and stick it into a shared library for later loading and execution on iOS?
Yup. Of course. It's pretty obvious that shared libs would've to be read-only on iOS. And I would also expect that there's no call to set the executable bit on a file (otherwise you could create a new shared lib).
Cheers, - Andreas
On 2010-12-23, at 1:04 PM, Andreas Raab wrote:
On 12/23/2010 12:47 PM, Igor Stasenko wrote:
it is possible (if someone provide a code), but i wonder why do you need such extra loops? It will give you nothing.
Unless the platform does not allow making memory regions executable, as on, say, iOS. In which case the ability to generate code into a shared lib becomes suddenly very valuable.
Cheers,
- Andreas
You could generate a native code and put it into executable memory region, instead of object memory, which could be then used to pass as callback address to some external function. Actually, if you look how NB callback test implemented - it does exactly what i describing.
You can always use NB (or just AsmJit) for generating code and putting it into static library or file.. but once it become static it is no longer interesting, because its static (yeah.. tautology ;)
--
John M. McIntoshjohnmci@smalltalkconsulting.com Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
At WWDC 2009 I had a long chat with the manager of the iOS security team at the time I was exploring options for JIT VMs.
mmap & mprotect are BSD unix/etc non-compliant as there is no way for *you* to set the execute bit on a page. We did discuss perhaps in an enterprise environment you could have certificates and signing to give you different rights, like say to set page tags, but that has never been offered.
Obviously you *can* set it, but only if you jail break or root the iOS. But I do recall seeing an article pass my desk the other day saying that Apple was slowing winning the war there because the time between IOS revisions and jail breaking was increasing and at some point it tips over the fence where it takes too long to break. This is not to say it's impossible, rather it becomes not worth pursuing for *casual enjoyment*...
On 2010-12-23, at 3:00 PM, Andreas Raab wrote:
On 12/23/2010 2:49 PM, John M McIntosh wrote:
Well I"m not sure what is being suggested here, but on iOS a shared library is marked as read and executable, NOT writable. so you can't do self modifying code... Unless you are saying you'd like to on macintel generate arm code and stick it into a shared library for later loading and execution on iOS?
Yup. Of course. It's pretty obvious that shared libs would've to be read-only on iOS. And I would also expect that there's no call to set the executable bit on a file (otherwise you could create a new shared lib).
Cheers,
- Andreas
-- =========================================================================== John M. McIntosh johnmci@smalltalkconsulting.com Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
On 24 December 2010 00:12, John M McIntosh johnmci@smalltalkconsulting.com wrote:
At WWDC 2009 I had a long chat with the manager of the iOS security team at the time I was exploring options for JIT VMs.
mmap & mprotect are BSD unix/etc non-compliant as there is no way for *you* to set the execute bit on a page. We did discuss perhaps in an enterprise environment you could have certificates and signing to give you different rights, like say to set page tags, but that has never been offered.
Obviously you *can* set it, but only if you jail break or root the iOS. But I do recall seeing an article pass my desk the other day saying that Apple was slowing winning the war there because the time between IOS revisions and jail breaking was increasing and at some point it tips over the fence where it takes too long to break. This is not to say it's impossible, rather it becomes not worth pursuing for *casual enjoyment*...
So, why simply don't ask user, if he wants to use JITs or not? Why limiting the choice?
Maybe JIT for casual enjoyment is too much.. but if you go 10-15 years back and show iphone to people, they would say: - what a waste.. why it using color display? why so expensive, why it has wifi? it is running an operating system? for what tasks? to call my mom i need OS on phone?.. and so on so on.. because people at that time were wanting just make a calls using cell phones :)
On 2010-12-23, at 3:00 PM, Andreas Raab wrote:
On 12/23/2010 2:49 PM, John M McIntosh wrote:
Well I"m not sure what is being suggested here, but on iOS a shared library is marked as read and executable, NOT writable. so you can't do self modifying code... Unless you are saying you'd like to on macintel generate arm code and stick it into a shared library for later loading and execution on iOS?
Yup. Of course. It's pretty obvious that shared libs would've to be read-only on iOS. And I would also expect that there's no call to set the executable bit on a file (otherwise you could create a new shared lib).
Cheers, - Andreas
--
John M. McIntosh johnmci@smalltalkconsulting.com Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
On Dec 23, 2010, at 4:31 PM, Igor Stasenko wrote:
So, why simply don't ask user, if he wants to use JITs or not? Why limiting the choice?
Maybe JIT for casual enjoyment is too much.. but if you go 10-15 years back and show iphone to people, they would say:
- what a waste.. why it using color display? why so expensive, why
it has wifi? it is running an operating system? for what tasks? to call my mom i need OS on phone?.. and so on so on.. because people at that time were wanting just make a calls using cell phones :)
I understand the point that you're making, but I had to laugh at this. It would be a pretty odd person who had the reaction above. I think a more typical reaction would be: holy crap, where can I get one of those? :-)
Cheers, Josh
On 24 December 2010 01:41, Josh Gargus josh@schwa.ca wrote:
On Dec 23, 2010, at 4:31 PM, Igor Stasenko wrote:
So, why simply don't ask user, if he wants to use JITs or not? Why limiting the choice?
Maybe JIT for casual enjoyment is too much.. but if you go 10-15 years back and show iphone to people, they would say:
- what a waste.. why it using color display? why so expensive, why
it has wifi? it is running an operating system? for what tasks? to call my mom i need OS on phone?.. and so on so on.. because people at that time were wanting just make a calls using cell phones :)
I understand the point that you're making, but I had to laugh at this. It would be a pretty odd person who had the reaction above. I think a more typical reaction would be: holy crap, where can I get one of those? :-)
no. i don't think so. it is useless without appropriate infrastructure. 4G phone useless because 10 years back there was no 4G. wifi is useless, because of the same reasons... i may continue.
Take a modern computer 100 years back.. and who will want it? You even won't find a right socket for plugging it into electric network (if you will be lucky and be near one :)
Cheers, Josh
2010/12/24 John M McIntosh johnmci@smalltalkconsulting.com
Well I"m not sure what is being suggested here, but on iOS a shared library is marked as read and executable, NOT writable. so you can't do self modifying code... Unless you are saying you'd like to on macintel generate arm code and stick it into a shared library for later loading and execution on iOS?
I think its good way for running smalltalk program with NB stuff on such platform. I think its meen that NB approach "nothing C code" can applyed everywhere.
Esteban -
My recommendation would be to try to port the minimal necessary subset of your application to Alien and see if that actually addresses your needs. This should be fairly straightforward - extracting the pointer addresses out of FFI handles and sticking them into an Alien isn't difficult.
In fact, I would probably go as far as saying that you might want to try to make a test case for the specifics of your situation (i.e., the minimal necessary subset to test the table renderer callback interface). Then you can run benchmarks on it. I'm pretty certain that there's probably some low-hanging FFI fruit as well that might be more easily visible within such a benchmark.
Cheers, - Andreas
On 12/23/2010 11:35 AM, Esteban Lorenzano wrote:
Hi guys, I'm doing some "advance callbacks" for Mars, and I'm having several problems with table renderers (they are called A LOT of times and needs to be efficient). The ObjectiveCBridge is not as efficient as that calls needs to be executed, and well... I was planing to spend some time on this, trying to see how can I improve the callback velocity. And then a question came to my mind:
do I spend time improving current ObjectiveCBridge implementation... or I better use Alien and migrate everything to it?
some context:
- it was always planned to "sonner or latter" migrate the ObjectiveCBridge stuff to alien (there is another .
- Alien is not working -yet- for iPhone. It is planned (bah... it is "thought") to run Alien in iPhoneVM too.
- Alien callback implementation is a lot cleaner than the current ObjectiveCBridge implementation (which relies on both sides semaphores, when alien callbacks relies on "image ownership")
So... it will delay a little a release of Mars? sure it will... but in the long way it will be better.
I would like to hear your opinions,
cheers, Esteban
vm-dev@lists.squeakfoundation.org
-
Andreas Raab -
Denis Kudriashov -
Esteban Lorenzano -
Igor Stasenko -
John M McIntosh -
Josh Gargus