hi all, was trying to load AlienOpenGL into 4.1 alpha and got the warning: This package depends on the following classes: AlienLibrary
Is this deprecated for 4.x or renamed or..?
Thanks, Lawson
I don't think that Alien was ever in trunk. IIRC the guy who wrote AlienOpenGL was a "Pharo guy"... I think that Pharo has Alien in by default (but I don't follow it closely). To get it to run, you'll have to load the prerequisite Alien code first. I haven't done this myself, so I have no particular advice for you.
BTW, why do you want to use AlienOpenGL, instead of "Croquet OpenGL"? Just curious? I wouldn't use it myself for performance reasons. For one thing, Alien is slower than the old FFI (Eliot has ideas about how to JIT the marshalling code, but it's not on his short-term list of projects). More importantly, AlienOpenGL uses Alien very inefficiently, or at least it did the last time I looked at it, I think in December. Every time you call an OpenGL function, it looks up the function address from scratch instead of caching it somewhere. I don't remember the precise results of the benchmarks that I did, but the overhead was terrible; it would be unusable for any moderately complex scene.
OTOH, if you're looking for something fun to hack, AlienOpenGL might be just the thing. It wouldn't be hard to cache the functions so that they're looked up only once; this would have a tremendous impact on performance.
Cheers, Josh
On Mar 22, 2010, at 3:47 PM, Lawson English wrote:
hi all, was trying to load AlienOpenGL into 4.1 alpha and got the warning: This package depends on the following classes: AlienLibrary
Is this deprecated for 4.x or renamed or..?
Thanks, Lawson
Josh Gargus wrote:
I don't think that Alien was ever in trunk. IIRC the guy who wrote AlienOpenGL was a "Pharo guy"... I think that Pharo has Alien in by default (but I don't follow it closely). To get it to run, you'll have to load the prerequisite Alien code first. I haven't done this myself, so I have no particular advice for you.
BTW, why do you want to use AlienOpenGL, instead of "Croquet OpenGL"? Just curious? I wouldn't use it myself for performance reasons. For one thing, Alien is slower than the old FFI (Eliot has ideas about how to JIT the marshalling code, but it's not on his short-term list of projects). More importantly, AlienOpenGL uses Alien very inefficiently, or at least it did the last time I looked at it, I think in December. Every time you call an OpenGL function, it looks up the function address from scratch instead of caching it somewhere. I don't remember the precise results of the benchmarks that I did, but the overhead was terrible; it would be unusable for any moderately complex scene.
Croquet OpenGL is dependent on all sorts of things. Have you managed to get Croquet working in a modernish version of Squeak/Pharo?
Also, I was under the impression that Alien FFI was faster than the standard FFI.
OTOH, if you're looking for something fun to hack, AlienOpenGL might be just the thing. It wouldn't be hard to cache the functions so that they're looked up only once; this would have a tremendous impact on performance.
Cheers, Josh
On Mar 22, 2010, at 3:47 PM, Lawson English wrote:
hi all, was trying to load AlienOpenGL into 4.1 alpha and got the warning: This package depends on the following classes: AlienLibrary
Is this deprecated for 4.x or renamed or..?
Thanks, Lawson
On 3/22/2010 7:27 PM, Lawson English wrote:
Croquet OpenGL is dependent on all sorts of things. Have you managed to get Croquet working in a modernish version of Squeak/Pharo?
I can probably whip one up fairly easily. The actual dependencies are rather minor - all you need to do is drop the positional argument variants (we've thrown these out in our own images too) and load the FFI first.
Also, I was under the impression that Alien FFI was faster than the standard FFI.
Oh, dear. This is hearsay, right? I.e., neither you nor anyone who claims it have ever ever run an actual benchmark, have you?
There is interesting out-of-context quote in the Alien documentation that brings as one of the arguments for Alien something that I said about the FFI, namely that the "FFI is slow ..." but unfortunately it doesn't quote the other half of that statement which is "... when compared to the Squeak plugin interface". That is undoubtedly true in the context of a discussion that compares the FFI and the Squeak plugin interface since the FFI has marshalling overhead that is not incurred by a regular plugin. That said, the FFI isn't slow per se - in particular not when compared with doing marshalling inside Squeak (as Alien does).
Put on top that people seem to use Alien in the most naive (e.g., slow) way looking up the functions on each call, and I'd say the FFI will beat Alien in *any* practical performance tests today (and for the foreseeable future). Doesn't mean Alien can't be improved, but the next time someone claims that "FFI is slow and Alien is fast" ask for the benchmark they ran instead of taking the claim at face value :-)
The main reason for using Alien today is callbacks. There is still no support for callbacks in the FFI so if you need callbacks Alien is your choice. One of the things that I've got on my TODO list with Eliot is to improve interoperability between Alien and the FFI. It should be possible to pass Aliens straight into FFI calls at which point you could have your cake and eat it, too.
Cheers, - Andreas
On 3/22/2010 9:21 PM, Andreas Raab wrote:
Also, I was under the impression that Alien FFI was faster than the standard FFI.
Oh, dear. This is hearsay, right? I.e., neither you nor anyone who claims it have ever ever run an actual benchmark, have you?
I thought it'd be fun to make a little benchmark so here we go. I'm using the most trivial example, namely the call to glGetError() which should be done early and often :-) Using the FFI (from CroquetGL) this looks like here:
ogl := OpenGL newIn: (0@0 corner: 10@10). time := [1 to: 1000000 do:[:i| ogl glGetError]] timeToRun. ogl destroy.
This takes about 435 msecs. Now the same with AlienOpenGL in Pharo:
drawable := OpenGLSurface newIn: (0@0 corner: 10@10). ogl := AlienOpenGLLibrary uniqueInstance. time := [1 to: 1000000 do:[:i| ogl glGetError]] timeToRun. drawable close.
This takes 8372 msecs. Whoopsie. That's a factor of 20x AlienOpenGL is slower for the same C call. But okay, that may not be a fair comparison due to the naive use of Alien. Let's be more clever, look up the method just once and invoke it:
drawable := OpenGLSurface newIn: (0@0 corner: 10@10). ogl := AlienOpenGLLibrary uniqueInstance. alienMethod := ogl alienMethodNamed: 'glGetError'. time := [1 to: 1000000 do:[:i| error := GLEnum new. alienMethod primFFICallResult: error. ]] timeToRun. drawable close.
This still takes 3589 msecs. Whoops, it did it again. Even with the more elaborate use Alien is still 8x slower than the FFI. That's the cost of doing marshalling in Squeak and the effect it has on Alien performance when compared with the FFI.
Cheers, - Andreas
Andreas Raab wrote:
[...] This still takes 3589 msecs. Whoops, it did it again. Even with the more elaborate use Alien is still 8x slower than the FFI. That's the cost of doing marshalling in Squeak and the effect it has on Alien performance when compared with the FFI.
Cheers,
- Andreas
Thanks so much for for all of this, Andreas. BTW what is the overhead of a named primitive vs an unnamed primitive vs an FFI call?
My tests (perhaps not relevant):
[1 to: 1000000 do:[:i| i+2]] timeToRun. 18
[1 to: 1000000 do:[:i| i+2.0]] timeToRun. 106
[1 to: 1000000 do:[:i| 2.0 +2.0]] timeToRun. 121
[1 to: 1000000 do:[:i| (FFITestLibrary ffiTestFloats: i with: 2.0)]] timeToRun. 2742
[1 to: 1000000 do:[:i| (FFITestLibrary ffiTestFloats: 2.0 with: 2.0)]] timeToRun. 2556
where would a
NPTestLibrary>>npTestFloats: 2.0 with: 2.0)
rank?
Would it ever be worth it to create a OpenGL plugin wrapper rather than use the FFI calls?
Lawson
On Mar 24, 2010, at 8:43 PM, Lawson English wrote:
Would it ever be worth it to create a OpenGL plugin wrapper rather than use the FFI calls?
Your application would have to be *very* efficient (much more efficient than, say, Croquet's scene-graph):
[1000000 timesRepeat: [gl glGetError]] timeToRun 627 [1000000 timesRepeat: [Object new; new; new; new]] timeToRun 747 [1000000 timesRepeat: [OrderedCollection new add: 1]] timeToRun 1078
We're talking less than a microsecond per FFI call. Your whole application would have to be *heavily* optimized before this became the #1 bottleneck.
Cheers, Josh
Lawson
On 23 March 2010 09:09, Andreas Raab andreas.raab@gmx.de wrote:
On 3/22/2010 9:21 PM, Andreas Raab wrote:
Also, I was under the impression that Alien FFI was faster than the standard FFI.
Oh, dear. This is hearsay, right? I.e., neither you nor anyone who claims it have ever ever run an actual benchmark, have you?
I thought it'd be fun to make a little benchmark so here we go. I'm using the most trivial example, namely the call to glGetError() which should be done early and often :-) Using the FFI (from CroquetGL) this looks like here:
ogl := OpenGL newIn: (0@0 corner: 10@10). time := [1 to: 1000000 do:[:i| ogl glGetError]] timeToRun. ogl destroy.
This takes about 435 msecs. Now the same with AlienOpenGL in Pharo:
drawable := OpenGLSurface newIn: (0@0 corner: 10@10). ogl := AlienOpenGLLibrary uniqueInstance. time := [1 to: 1000000 do:[:i| ogl glGetError]] timeToRun. drawable close.
This takes 8372 msecs. Whoopsie. That's a factor of 20x AlienOpenGL is slower for the same C call. But okay, that may not be a fair comparison due to the naive use of Alien. Let's be more clever, look up the method just once and invoke it:
drawable := OpenGLSurface newIn: (0@0 corner: 10@10). ogl := AlienOpenGLLibrary uniqueInstance. alienMethod := ogl alienMethodNamed: 'glGetError'. time := [1 to: 1000000 do:[:i| error := GLEnum new. alienMethod primFFICallResult: error. ]] timeToRun. drawable close.
i don't know how to load this code, could you put error := GLEnum new. out of block and run it again?
This still takes 3589 msecs. Whoops, it did it again. Even with the more elaborate use Alien is still 8x slower than the FFI. That's the cost of doing marshalling in Squeak and the effect it has on Alien performance when compared with the FFI.
It is expected to see that marshalling/converting types takes most of the time, while rest should be same, because it straightforward: push arguments, make a call and return result. So, at some cases (not at all), one could prepare arguments and return value holder and then use it in calls, avoiding allocating & converting them each time. For instance, when you passing a string (char*), one may use a CString object (a null-terminated String), and pass it into Alien without conversion, while FFI allocates a null-terminated strings on heap, copying String contents to that buffer and then using them as arguments to a function. So its hard to say, which way is better.
Cheers, - Andreas
On 3/25/2010 9:04 AM, Igor Stasenko wrote:
drawable := OpenGLSurface newIn: (0@0 corner: 10@10). ogl := AlienOpenGLLibrary uniqueInstance. alienMethod := ogl alienMethodNamed: 'glGetError'. time := [1 to: 1000000 do:[:i| error := GLEnum new. alienMethod primFFICallResult: error. ]] timeToRun. drawable close.i don't know how to load this code, could you put error := GLEnum new. out of block and run it again?
No, because you're returning it and you can't share error code instances (it's like saying that something that Point>>z:y: should just return the same point for each call :-) It's fine to cache the call that way since it's internal to the library but not for the return value.
It is expected to see that marshalling/converting types takes most of the time, while rest should be same, because it straightforward: push arguments, make a call and return result. So, at some cases (not at all), one could prepare arguments and return value holder and then use it in calls, avoiding allocating& converting them each time.
But what you call "preparing arguments and return value holder and then use it" is marshalling. Moving it into the caller doesn't actually make it faster. And how much time do you want to spend optimizing your use of callout facilities vs. actually writing the app?
For instance, when you passing a string (char*), one may use a CString object (a null-terminated String), and pass it into Alien without conversion, while FFI allocates a null-terminated strings on heap, copying String contents to that buffer and then using them as arguments to a function.
The FFI can do the same but it's mostly pointless. If you have a Squeak string you can convert it to a C string (ExternalData) and pass it into an FFI call.
So its hard to say, which way is better.
There's no doubt in my mind. Absolutely nobody is going to spend time optimizing their callout interface manually. They use the stuff that's there. Go look at AlienOpenGL. Go look at Newspeak. That's your answer right there. I have still to see a single example of a (non-contrived) usage of Alien that's faster than the equivalent (non-contrived) FFI call.
Cheers, - Andreas
On 25 March 2010 18:35, Andreas Raab andreas.raab@gmx.de wrote:
On 3/25/2010 9:04 AM, Igor Stasenko wrote:
drawable := OpenGLSurface newIn: (0@0 corner: 10@10). ogl := AlienOpenGLLibrary uniqueInstance. alienMethod := ogl alienMethodNamed: 'glGetError'. time := [1 to: 1000000 do:[:i| error := GLEnum new. alienMethod primFFICallResult: error. ]] timeToRun. drawable close.
i don't know how to load this code, could you put error := GLEnum new. out of block and run it again?
No, because you're returning it and you can't share error code instances (it's like saying that something that Point>>z:y: should just return the same point for each call :-) It's fine to cache the call that way since it's internal to the library but not for the return value.
Well, it is up to the caller to decide, whether he wants to create a new instance for every return value, or use a single one. For glGetError, this is fairly acceptable, because you can hide the GLEnum instance inside the class which implements glGetError.
It is expected to see that marshalling/converting types takes most of the time, while rest should be same, because it straightforward: push arguments, make a call and return result. So, at some cases (not at all), one could prepare arguments and return value holder and then use it in calls, avoiding allocating& converting them each time.
But what you call "preparing arguments and return value holder and then use it" is marshalling. Moving it into the caller doesn't actually make it faster. And how much time do you want to spend optimizing your use of callout facilities vs. actually writing the app?
For instance, when you passing a string (char*), one may use a CString object (a null-terminated String), and pass it into Alien without conversion, while FFI allocates a null-terminated strings on heap, copying String contents to that buffer and then using them as arguments to a function.
The FFI can do the same but it's mostly pointless. If you have a Squeak string you can convert it to a C string (ExternalData) and pass it into an FFI call.
So its hard to say, which way is better.
There's no doubt in my mind. Absolutely nobody is going to spend time optimizing their callout interface manually. They use the stuff that's there. Go look at AlienOpenGL. Go look at Newspeak. That's your answer right there. I have still to see a single example of a (non-contrived) usage of Alien that's faster than the equivalent (non-contrived) FFI call.
Point taken. Yes, you have to be a lot more clever to optimize such calls for your use scenarios, which, as you said, makes writing an application a lot more tedious process. But it is the price we pay, when need something to be heavily optimized, isnt?
Cheers, - Andreas
On 3/25/2010 9:48 AM, Igor Stasenko wrote:
There's no doubt in my mind. Absolutely nobody is going to spend time optimizing their callout interface manually. They use the stuff that's there. Go look at AlienOpenGL. Go look at Newspeak. That's your answer right there. I have still to see a single example of a (non-contrived) usage of Alien that's faster than the equivalent (non-contrived) FFI call.
Point taken. Yes, you have to be a lot more clever to optimize such calls for your use scenarios, which, as you said, makes writing an application a lot more tedious process. But it is the price we pay, when need something to be heavily optimized, isnt?
True, but in that case, why not go straight to a plugin:
primitiveGlGetError <export: true> interpreterProxy pop: interpreterProxy methodArgumentCount+1. interpreterProxy pushInteger: self glGetError.
That's going to be faster than anything else.
Cheers, - Andreas
On 25 March 2010 18:54, Andreas Raab andreas.raab@gmx.de wrote:
On 3/25/2010 9:48 AM, Igor Stasenko wrote:
There's no doubt in my mind. Absolutely nobody is going to spend time optimizing their callout interface manually. They use the stuff that's there. Go look at AlienOpenGL. Go look at Newspeak. That's your answer right there. I have still to see a single example of a (non-contrived) usage of Alien that's faster than the equivalent (non-contrived) FFI call.
Point taken. Yes, you have to be a lot more clever to optimize such calls for your use scenarios, which, as you said, makes writing an application a lot more tedious process. But it is the price we pay, when need something to be heavily optimized, isnt?
True, but in that case, why not go straight to a plugin:
primitiveGlGetError <export: true> interpreterProxy pop: interpreterProxy methodArgumentCount+1. interpreterProxy pushInteger: self glGetError.
That's going to be faster than anything else.
Then i really wonder, why people find an Alien so attractive?
Cheers, - Andreas
On 3/25/2010 10:30 AM, Igor Stasenko wrote:
Then i really wonder, why people find an Alien so attractive?
There are two different reasons, one is philosophical, one is practical. The practical issue is callbacks. When you need them you just need them :-)
The philosophical point is about how a system like Squeak should integrate into the external environment. My opinion is that the VM should provide a safe cross-platform abstraction layer. As a consequence, I am in favor of plugins that provide abstractions, have a well-defined interface, and are safe however you use them. The only real sin I've ever committed in this regard was OpenGL because the interface is so big and the handling of extensions tricky otherwise.
Gilad's opinion (and I hope I'm not misrepresenting him here since this an extrapolation from discussions with Eliot) as far as I understand it is that the VM should be basically invisible - just the execution machinery and for the rest you go straight to the OS and do everything there.
That's a perfectly valid position, and Alien makes that point quite explicitly with moving even the marshalling into the image. I.e., what Alien really provides is just an absolutely minimalistic thunk for callout and callback; everything else is up to you. I can appreciate that approach; it's just not my view on how a system like Squeak should function.
I think what excites people who understand this is the philosophical difference. Having access to everything at your fingertips is powerful, no doubt about it.
Plus, most people have no clue what they're talking about when it comes to plugins vs. FFI vs. Alien and just repeat what someone else said. Sad, but true.
Cheers, - Andreas
On Thu, Mar 25, 2010 at 11:05 AM, Andreas Raab andreas.raab@gmx.de wrote:
The philosophical point is about how a system like Squeak should integrate into the external environment. My opinion is that the VM should provide a safe cross-platform abstraction layer. As a consequence, I am in favor of plugins that provide abstractions, have a well-defined interface, and are safe however you use them. The only real sin I've ever committed in this regard was OpenGL because the interface is so big and the handling of extensions tricky otherwise.
Gilad's opinion (and I hope I'm not misrepresenting him here since this an extrapolation from discussions with Eliot) as far as I understand it is that the VM should be basically invisible - just the execution machinery and for the rest you go straight to the OS and do everything there.
And it's not only Gilad's opinion. The issue is not even _how_ to integrate into the external environment, it's _whether_ to integrate into it. You have to speak another language to integrate into another culture. Systems relying on VM primitives with safe abstractions choose to be tourists, and are bound to remain so.
As for performance, the penalty of high-level marshalling is only as high as slowly high-level code runs.
Cheers,
--Vassili
That's a perfectly valid position, and Alien makes that point quite explicitly with moving even the marshalling into the image. I.e., what Alien really provides is just an absolutely minimalistic thunk for callout and callback; everything else is up to you. I can appreciate that approach; it's just not my view on how a system like Squeak should function.
I think what excites people who understand this is the philosophical difference. Having access to everything at your fingertips is powerful, no doubt about it.
Plus, most people have no clue what they're talking about when it comes to plugins vs. FFI vs. Alien and just repeat what someone else said. Sad, but true.
Cheers, - Andreas
On 25.03.2010, at 19:38, Vassili Bykov wrote:
On Thu, Mar 25, 2010 at 11:05 AM, Andreas Raab andreas.raab@gmx.de wrote:
The philosophical point is about how a system like Squeak should integrate into the external environment. My opinion is that the VM should provide a safe cross-platform abstraction layer. As a consequence, I am in favor of plugins that provide abstractions, have a well-defined interface, and are safe however you use them. The only real sin I've ever committed in this regard was OpenGL because the interface is so big and the handling of extensions tricky otherwise.
Gilad's opinion (and I hope I'm not misrepresenting him here since this an extrapolation from discussions with Eliot) as far as I understand it is that the VM should be basically invisible - just the execution machinery and for the rest you go straight to the OS and do everything there.
And it's not only Gilad's opinion. The issue is not even _how_ to integrate into the external environment, it's _whether_ to integrate into it. You have to speak another language to integrate into another culture. Systems relying on VM primitives with safe abstractions choose to be tourists, and are bound to remain so.
--Vassili
Right - that's the way Squeak chose a long time ago. Run bit-identically everywhere, using the smallest possible interface to the host and do the rest on its own.
Plus, most people have no clue what they're talking about when it comes to plugins vs. FFI vs. Alien and just repeat what someone else said. Sad, but true.
Cheers,
- Andreas
Plus, Alien is newer, so must be better.
- Bert -
On 25 March 2010 21:05, Bert Freudenberg bert@freudenbergs.de wrote:
Plus, Alien is newer, so must be better.
:)
- Bert -
Andreas Raab wrote:
On 3/25/2010 10:30 AM, Igor Stasenko wrote:
Then i really wonder, why people find an Alien so attractive?
There are two different reasons, one is philosophical, one is practical. The practical issue is callbacks. When you need them you just need them :-)
The philosophical point is about how a system like Squeak should integrate into the external environment. My opinion is that the VM should provide a safe cross-platform abstraction layer. As a consequence, I am in favor of plugins that provide abstractions, have a well-defined interface, and are safe however you use them. The only real sin I've ever committed in this regard was OpenGL because the interface is so big and the handling of extensions tricky otherwise.
How would a plugin work differently than the FFI's as far as safety goes?
Gilad's opinion (and I hope I'm not misrepresenting him here since this an extrapolation from discussions with Eliot) as far as I understand it is that the VM should be basically invisible - just the execution machinery and for the rest you go straight to the OS and do everything there.
That's a perfectly valid position, and Alien makes that point quite explicitly with moving even the marshalling into the image. I.e., what Alien really provides is just an absolutely minimalistic thunk for callout and callback; everything else is up to you. I can appreciate that approach; it's just not my view on how a system like Squeak should function.
EIther approach might make sense. The ability to do both gives flexibility tot he platform, without detracting from any safety or whatever issues... For a specific task, if you don't need XYZ, don't install it and and whatever its dependent on.
I think what excites people who understand this is the philosophical difference. Having access to everything at your fingertips is powerful, no doubt about it.
Plus, most people have no clue what they're talking about when it comes to plugins vs. FFI vs. Alien and just repeat what someone else said. Sad, but true.
I'm always trying to learn and I thank everyone for helping me. In this context, though, while many projects, platforms, spheres of knowledge, etc, suffer from lack of comprehension on the part of the masses, squeak is probably more vulnerable to this issue than most because while it was originally designed with beginners in mind, the primary users are expert-level and beyond.
I have several main goals concerning squeak right now.
The first is to learn the system well enough to accomplish the rest. The second is to explore various ways squeak and croquet/cobalt can interop with the Second Life virtual world. The third is to experiment with teaching using these technologies.
I'm a big fan of Salman Khan and the khan academy and a new convert to Norm Wildberger's lectures on youtube.
http://www.youtube.com/user/khanacademy http://www.youtube.com/user/njwildberger
Squeak needs that level and sophistication of education applied to *itself*.
Lawson
On 25.03.2010, at 21:59, Lawson English wrote:
How would a plugin work differently than the FFI's as far as safety goes?
Instead of crashing, you get a nice friendly "primitive failed" error ;)
EIther approach might make sense. The ability to do both gives flexibility tot he platform, without detracting from any safety or whatever issues... For a specific task, if you don't need XYZ, don't install it and and whatever its dependent on.
That's exactly why we have FFI but use it as little as possible.
- Bert -
On 25.03.2010, at 21:59, Lawson English wrote:
I'm a big fan of Salman Khan and the khan academy and a new convert to Norm Wildberger's lectures on youtube.
http://www.youtube.com/user/khanacademy http://www.youtube.com/user/njwildberger
I didn't know Khan Academy, thanks!
I bought Wildberger's book a while ago. But seeing his lectures now gives a very nice perspective. Who'd have thunk trigonometry could be friendly? ;)
Squeak needs that level and sophistication of education applied to *itself*.
Lawson
Hear, hear!
- Bert -
Bert Freudenberg wrote:
On 25.03.2010, at 21:59, Lawson English wrote:
I'm a big fan of Salman Khan and the khan academy and a new convert to Norm Wildberger's lectures on youtube.
http://www.youtube.com/user/khanacademy http://www.youtube.com/user/njwildberger
I didn't know Khan Academy, thanks!
1200+ lectures on youtube and counting. Quit his day job to work ont eh project and is getting awards and grants all over (not to mention loads of publicity).
I bought Wildberger's book a while ago. But seeing his lectures now gives a very nice perspective. Who'd have thunk trigonometry could be friendly? ;)
I'm watching his linear algebra series. Illuminates some very obscure corners, for me. High school-oriented math FTW!
Squeak needs that level and sophistication of education applied to *itself*.
Have you ever watched a ZBrush tutorial in ZBrush itself? I think a great use-case for squeak would be to create ZBrush level tutorials with 2D and 3D graphics (including replayed Cobalt) combined with video and sound and distribute them as files, rather than as part of the image.
With a safe web plugin, you could have a squeaktube site (hmmm better name needed?) for streaming educational stuff.
Lawson
On Mon, Mar 22, 2010 at 9:21 PM, Andreas Raab andreas.raab@gmx.de wrote:
On 3/22/2010 7:27 PM, Lawson English wrote:
Croquet OpenGL is dependent on all sorts of things. Have you managed to get Croquet working in a modernish version of Squeak/Pharo?
I can probably whip one up fairly easily. The actual dependencies are rather minor - all you need to do is drop the positional argument variants (we've thrown these out in our own images too) and load the FFI first.
Also, I was under the impression that Alien FFI was faster than the
standard FFI.
Oh, dear. This is hearsay, right? I.e., neither you nor anyone who claims it have ever ever run an actual benchmark, have you?
There is interesting out-of-context quote in the Alien documentation that brings as one of the arguments for Alien something that I said about the FFI, namely that the "FFI is slow ..." but unfortunately it doesn't quote the other half of that statement which is "... when compared to the Squeak plugin interface". That is undoubtedly true in the context of a discussion that compares the FFI and the Squeak plugin interface since the FFI has marshalling overhead that is not incurred by a regular plugin. That said, the FFI isn't slow per se - in particular not when compared with doing marshalling inside Squeak (as Alien does).
Put on top that people seem to use Alien in the most naive (e.g., slow) way looking up the functions on each call, and I'd say the FFI will beat Alien in *any* practical performance tests today (and for the foreseeable future). Doesn't mean Alien can't be improved, but the next time someone claims that "FFI is slow and Alien is fast" ask for the benchmark they ran instead of taking the claim at face value :-)
The main reason for using Alien today is callbacks. There is still no support for callbacks in the FFI so if you need callbacks Alien is your choice. One of the things that I've got on my TODO list with Eliot is to improve interoperability between Alien and the FFI. It should be possible to pass Aliens straight into FFI calls at which point you could have your cake and eat it, too.
Right. I won't stand by the "slow" comment anymore. I've done a much faster version of FFI here that has essentially the same performance as Alien. The important thing is to use alloca to allocate the outgoing stack frame and marshall to that. The old FFI code marshalled to static memory and then copied to the stack frame. This makes the old implementation inherrently slower /and/ non-reentrant. Now this is solved FFI is essentially as fast as Alien.
The advantage FFI has right oer Alien call-outs (as opposed to Alien data representation) is more typing and so a better chance of dealing correctly with RISC calling conventions. So the clear path is to merge the data management side of Alien into FFI and extend FFI with true callbacks, a la Alien. We then have the best of both worlds. That's something I want to get done this year, e.g. as part of the GSoC.
Cheers,
- Andreas
2010/3/23 Eliot Miranda eliot.miranda@gmail.com:
On Mon, Mar 22, 2010 at 9:21 PM, Andreas Raab andreas.raab@gmx.de wrote:
On 3/22/2010 7:27 PM, Lawson English wrote:
Croquet OpenGL is dependent on all sorts of things. Have you managed to get Croquet working in a modernish version of Squeak/Pharo?
I can probably whip one up fairly easily. The actual dependencies are rather minor - all you need to do is drop the positional argument variants (we've thrown these out in our own images too) and load the FFI first.
Also, I was under the impression that Alien FFI was faster than the standard FFI.
Oh, dear. This is hearsay, right? I.e., neither you nor anyone who claims it have ever ever run an actual benchmark, have you?
There is interesting out-of-context quote in the Alien documentation that brings as one of the arguments for Alien something that I said about the FFI, namely that the "FFI is slow ..." but unfortunately it doesn't quote the other half of that statement which is "... when compared to the Squeak plugin interface". That is undoubtedly true in the context of a discussion that compares the FFI and the Squeak plugin interface since the FFI has marshalling overhead that is not incurred by a regular plugin. That said, the FFI isn't slow per se - in particular not when compared with doing marshalling inside Squeak (as Alien does).
Put on top that people seem to use Alien in the most naive (e.g., slow) way looking up the functions on each call, and I'd say the FFI will beat Alien in *any* practical performance tests today (and for the foreseeable future). Doesn't mean Alien can't be improved, but the next time someone claims that "FFI is slow and Alien is fast" ask for the benchmark they ran instead of taking the claim at face value :-)
The main reason for using Alien today is callbacks. There is still no support for callbacks in the FFI so if you need callbacks Alien is your choice. One of the things that I've got on my TODO list with Eliot is to improve interoperability between Alien and the FFI. It should be possible to pass Aliens straight into FFI calls at which point you could have your cake and eat it, too.
Right. I won't stand by the "slow" comment anymore. I've done a much faster version of FFI here that has essentially the same performance as Alien. The important thing is to use alloca to allocate the outgoing stack frame and marshall to that. The old FFI code marshalled to static memory and then copied to the stack frame. This makes the old implementation inherrently slower /and/ non-reentrant. Now this is solved FFI is essentially as fast as Alien.
Naive question: is there any potential stack overflow problem with alloca ?
Nicolas
The advantage FFI has right oer Alien call-outs (as opposed to Alien data representation) is more typing and so a better chance of dealing correctly with RISC calling conventions. So the clear path is to merge the data management side of Alien into FFI and extend FFI with true callbacks, a la Alien. We then have the best of both worlds. That's something I want to get done this year, e.g. as part of the GSoC.
Cheers, - Andreas
On Tue, Mar 23, 2010 at 11:41 AM, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> wrote:
2010/3/23 Eliot Miranda eliot.miranda@gmail.com:
On Mon, Mar 22, 2010 at 9:21 PM, Andreas Raab andreas.raab@gmx.de
wrote:
On 3/22/2010 7:27 PM, Lawson English wrote:
Croquet OpenGL is dependent on all sorts of things. Have you managed to get Croquet working in a modernish version of Squeak/Pharo?
I can probably whip one up fairly easily. The actual dependencies are rather minor - all you need to do is drop the positional argument
variants
(we've thrown these out in our own images too) and load the FFI first.
Also, I was under the impression that Alien FFI was faster than the standard FFI.
Oh, dear. This is hearsay, right? I.e., neither you nor anyone who
claims
it have ever ever run an actual benchmark, have you?
There is interesting out-of-context quote in the Alien documentation
that
brings as one of the arguments for Alien something that I said about the FFI, namely that the "FFI is slow ..." but unfortunately it doesn't
quote
the other half of that statement which is "... when compared to the
Squeak
plugin interface". That is undoubtedly true in the context of a
discussion
that compares the FFI and the Squeak plugin interface since the FFI has marshalling overhead that is not incurred by a regular plugin. That
said,
the FFI isn't slow per se - in particular not when compared with doing marshalling inside Squeak (as Alien does).
Put on top that people seem to use Alien in the most naive (e.g., slow) way looking up the functions on each call, and I'd say the FFI will beat Alien in *any* practical performance tests today (and for the
foreseeable
future). Doesn't mean Alien can't be improved, but the next time someone claims that "FFI is slow and Alien is fast" ask for the benchmark they
ran
instead of taking the claim at face value :-)
The main reason for using Alien today is callbacks. There is still no support for callbacks in the FFI so if you need callbacks Alien is your choice. One of the things that I've got on my TODO list with Eliot is to improve interoperability between Alien and the FFI. It should be
possible to
pass Aliens straight into FFI calls at which point you could have your
cake
and eat it, too.
Right. I won't stand by the "slow" comment anymore. I've done a much faster version of FFI here that has essentially the same performance as Alien. The important thing is to use alloca to allocate the outgoing
stack
frame and marshall to that. The old FFI code marshalled to static memory
and
then copied to the stack frame. This makes the old implementation inherrently slower /and/ non-reentrant. Now this is solved FFI is essentially as fast as Alien.
Naive question: is there any potential stack overflow problem with alloca ?
Not over and above what already exists in an FFI. One can arrange that one alloca's close to what is needed for a given call, not simply some maximum on every call. So when done like this alloca takes only a small percentage more than one would allocate for a normal call, and certainly less than a factor of two for a call with a large call frame.
In my reimplementation of the FFI the first time an FFI method is run the alloca is 16kb plus the size of the struct return, with the call failing if this isn't enough space. The code then calculates how much of the 16k was actually used and caches this in the FFI method's ExternalFunction object so next time it alloca's only what's required. Actual overhead is greater than the alloca because one has to allow for the plugin function's invocation and its local variables. Even if the total overhead for a call were to reach 32k bytes one would have to have a deeply nested series of call-outs and call-backs before one was in danger of overflowing a typical 1Meg/thread stack.
HTH Eliot
Nicolas
The advantage FFI has right oer Alien call-outs (as opposed to Alien data representation) is more typing and so a better chance of dealing
correctly
with RISC calling conventions. So the clear path is to merge the data management side of Alien into FFI and extend FFI with true callbacks, a
la
Alien. We then have the best of both worlds. That's something I want to get done this year, e.g. as part of the GSoC.
Cheers,
- Andreas
On 3/22/2010 7:27 PM, Lawson English wrote:
Croquet OpenGL is dependent on all sorts of things. Have you managed to get Croquet working in a modernish version of Squeak/Pharo?
(you will need an updated 4.1 trunk image - I've promoted Form>>flipVertically to core in the process of making this package)
From http://www.squeaksource.com/CroquetGL
The OpenGL interface from Croquet for consumption in other contexts. Supports OpenGL 1.4 plus extensions.
To install, first load the FFI via:
(Installer repository: 'http://source.squeak.org/FFI') install: 'FFI-Pools'; install: 'FFI-Kernel'; install: 'FFI-Tests'.
then load CroquetGL:
(Installer repository: 'http://www.squeaksource.com/CroquetGL') install: '3DTransform'; install: 'OpenGL-Pools'; install: 'OpenGL-Core'.
When everything has loaded, try the example:
OpenGL example.
Important Windows Note:
In order to use Croquet on Windows, you must make sure your VM is set to support OpenGL instead of D3D by default. To do this, press F2 or go to the system menu, into the "Display and Sound" section and ensure the preference "Use OpenGL (instead of D3D" is ENABLED.
Cheers, - Andreas
On 23.03.2010, at 07:04, Andreas Raab wrote:
On 3/22/2010 7:27 PM, Lawson English wrote:
Croquet OpenGL is dependent on all sorts of things. Have you managed to get Croquet working in a modernish version of Squeak/Pharo?
(you will need an updated 4.1 trunk image - I've promoted Form>>flipVertically to core in the process of making this package)
From http://www.squeaksource.com/CroquetGL
The OpenGL interface from Croquet for consumption in other contexts. Supports OpenGL 1.4 plus extensions.
To install, first load the FFI via:
(Installer repository: 'http://source.squeak.org/FFI') install: 'FFI-Pools'; install: 'FFI-Kernel'; install: 'FFI-Tests'.
then load CroquetGL:
(Installer repository: 'http://www.squeaksource.com/CroquetGL') install: '3DTransform'; install: 'OpenGL-Pools'; install: 'OpenGL-Core'.
When everything has loaded, try the example:
OpenGL example.
Important Windows Note:
In order to use Croquet on Windows, you must make sure your VM is set to support OpenGL instead of D3D by default. To do this, press F2 or go to the system menu, into the "Display and Sound" section and ensure the preference "Use OpenGL (instead of D3D" is ENABLED.
Cheers,
- Andreas
Neat :) Works like a charm on my old MacBook Pro, about 400 fps.
- Bert -
On 3/23/2010 4:46 AM, Bert Freudenberg wrote:
Neat :) Works like a charm on my old MacBook Pro, about 400 fps.
Yeah, I was wondering why it's so much slower in trunk than in our internal images or Croquet. First I thought it's the JIT but then I looked at a profile and found EventSensor>>wait2ms called from several places in EventSensor and indirectly via Sensor anyButtonPressed .
WTF? This isn't in any of the images I've ever used, does someone know why we're doing this? Randomly waiting for 2ms and *no comment* as to what the purpose of that wait might be? I'm in favor of ripping this out; there should be absolutely no need to wait for 2ms in EventSensor.
Cheers, - Andreas
On 23 March 2010 18:10, Andreas Raab andreas.raab@gmx.de wrote:
On 3/23/2010 4:46 AM, Bert Freudenberg wrote:
Neat :) Works like a charm on my old MacBook Pro, about 400 fps.
Yeah, I was wondering why it's so much slower in trunk than in our internal images or Croquet. First I thought it's the JIT but then I looked at a profile and found EventSensor>>wait2ms called from several places in EventSensor and indirectly via Sensor anyButtonPressed .
WTF? This isn't in any of the images I've ever used, does someone know why we're doing this? Randomly waiting for 2ms and *no comment* as to what the purpose of that wait might be? I'm in favor of ripping this out; there should be absolutely no need to wait for 2ms in EventSensor.
All senders of wait2ms seems having same author , and very small time frame: JMM 11/7/2005 14:39
So, i suppose we could ask the author to comment this.
Cheers, - Andreas
When the *high priority* task looking at the mouse location in the Browser see the cursor move between the browser windows it would change the cursor. Then invoke a tight loop to see when the cursor reentered a browser pane. This would drive 100,000 peekPosition starving the regular morphic loop. The result was that at the time the cursor would *stick* between browser panes if your timing was *just* right.
It would appear that all that code was refactored in the last 5 years. Still if you feel that looking at the mouse position 100,000 a second is worthwhile? you could rip it all out and hope there aren't side-effects. Like someone launch a process, then peek for mouse up. Wonder who will get the CPU? The task doing the work? Or the hyper processing spin 100,000 peeks a second waiting for the mouse to go up?
"Change Set: EventSensorDelayOnHyperPolling Date: 7 November 2005 Author: johnmci@smalltalkconsulting.com
Attempt to ensure polling for event data does not drive cpu to 100%. Wait 2ms between looks at mouse position or for keyboard events. Usually these don't happen 100's of times per second anyways"!
On 2010-03-23, at 9:16 AM, Igor Stasenko wrote:
On 23 March 2010 18:10, Andreas Raab andreas.raab@gmx.de wrote:
On 3/23/2010 4:46 AM, Bert Freudenberg wrote:
Neat :) Works like a charm on my old MacBook Pro, about 400 fps.
Yeah, I was wondering why it's so much slower in trunk than in our internal images or Croquet. First I thought it's the JIT but then I looked at a profile and found EventSensor>>wait2ms called from several places in EventSensor and indirectly via Sensor anyButtonPressed .
WTF? This isn't in any of the images I've ever used, does someone know why we're doing this? Randomly waiting for 2ms and *no comment* as to what the purpose of that wait might be? I'm in favor of ripping this out; there should be absolutely no need to wait for 2ms in EventSensor.
All senders of wait2ms seems having same author , and very small time frame: JMM 11/7/2005 14:39
So, i suppose we could ask the author to comment this.
Cheers,
- Andreas
-- Best regards, Igor Stasenko AKA sig.
-- =========================================================================== John M. McIntosh johnmci@smalltalkconsulting.com Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
On 23 March 2010 19:50, John M McIntosh johnmci@smalltalkconsulting.com wrote:
When the *high priority* task looking at the mouse location in the Browser see the cursor move between the browser windows it would change the cursor. Then invoke a tight loop to see when the cursor reentered a browser pane. This would drive 100,000 peekPosition starving the regular morphic loop. The result was that at the time the cursor would *stick* between browser panes if your timing was *just* right.
It would appear that all that code was refactored in the last 5 years. Still if you feel that looking at the mouse position 100,000 a second is worthwhile? you could rip it all out and hope there aren't side-effects. Like someone launch a process, then peek for mouse up. Wonder who will get the CPU? The task doing the work? Or the hyper processing spin 100,000 peeks a second waiting for the mouse to go up?
My 2c. A tight polling loop is, obviously, a mistake, an abuse which should be fixed in places where it is used, instead of patching the implementor. Because it is really ridiculous to patch the implementation to suit the needs of bad design practices. :) Sure, it is easier sometimes, than fixing the issue which causing it :)
"Change Set: EventSensorDelayOnHyperPolling Date: 7 November 2005 Author: johnmci@smalltalkconsulting.com
Attempt to ensure polling for event data does not drive cpu to 100%. Wait 2ms between looks at mouse position or for keyboard events. Usually these don't happen 100's of times per second anyways"!
On 2010-03-23, at 9:16 AM, Igor Stasenko wrote:
On 23 March 2010 18:10, Andreas Raab andreas.raab@gmx.de wrote:
On 3/23/2010 4:46 AM, Bert Freudenberg wrote:
Neat :) Works like a charm on my old MacBook Pro, about 400 fps.
Yeah, I was wondering why it's so much slower in trunk than in our internal images or Croquet. First I thought it's the JIT but then I looked at a profile and found EventSensor>>wait2ms called from several places in EventSensor and indirectly via Sensor anyButtonPressed .
WTF? This isn't in any of the images I've ever used, does someone know why we're doing this? Randomly waiting for 2ms and *no comment* as to what the purpose of that wait might be? I'm in favor of ripping this out; there should be absolutely no need to wait for 2ms in EventSensor.
All senders of wait2ms seems having same author , and very small time frame: JMM 11/7/2005 14:39
So, i suppose we could ask the author to comment this.
Cheers, - Andreas
-- Best regards, Igor Stasenko AKA sig.
--
John M. McIntosh johnmci@smalltalkconsulting.com Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
On 2010-03-23, at 11:21 AM, Igor Stasenko wrote:
Sure, it is easier sometimes, than fixing the issue which causing it :)
Ya, and the "proper" fix was, change the browser code to use an UI event model, versus a UI polling model. But that seems to have taken a few years to happen...
-- =========================================================================== John M. McIntosh johnmci@smalltalkconsulting.com Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
On 3/23/2010 10:50 AM, John M McIntosh wrote:
When the *high priority* task looking at the mouse location in the Browser see the cursor move between the browser windows it would change the cursor. Then invoke a tight loop to see when the cursor reentered a browser pane. This would drive 100,000 peekPosition starving the regular morphic loop. The result was that at the time the cursor would *stick* between browser panes if your timing was *just* right.
Which high priority task are you referring to? I think we might want to fix that, it seems completely pointless to run a loop like that.
It would appear that all that code was refactored in the last 5 years. Still if you feel that looking at the mouse position 100,000 a second is worthwhile?
If I am trying to run a benchmark? Yes, absolutely.
you could rip it all out and hope there aren't side-effects. Like someone launch a process, then peek for mouse up. Wonder who will get the CPU? The task doing the work? Or the hyper processing spin 100,000 peeks a second waiting for the mouse to go up?
Good question. The usage of Sensor in Morphic is completely abusive. Sensor isn't a Morphic entity; only the hand should be used to query such information. I'll check it out.
Cheers, - Andreas
"Change Set: EventSensorDelayOnHyperPolling Date: 7 November 2005 Author: johnmci@smalltalkconsulting.com
Attempt to ensure polling for event data does not drive cpu to 100%. Wait 2ms between looks at mouse position or for keyboard events. Usually these don't happen 100's of times per second anyways"!
On 2010-03-23, at 9:16 AM, Igor Stasenko wrote:
On 23 March 2010 18:10, Andreas Raabandreas.raab@gmx.de wrote:
On 3/23/2010 4:46 AM, Bert Freudenberg wrote:
Neat :) Works like a charm on my old MacBook Pro, about 400 fps.
Yeah, I was wondering why it's so much slower in trunk than in our internal images or Croquet. First I thought it's the JIT but then I looked at a profile and found EventSensor>>wait2ms called from several places in EventSensor and indirectly via Sensor anyButtonPressed .
WTF? This isn't in any of the images I've ever used, does someone know why we're doing this? Randomly waiting for 2ms and *no comment* as to what the purpose of that wait might be? I'm in favor of ripping this out; there should be absolutely no need to wait for 2ms in EventSensor.
All senders of wait2ms seems having same author , and very small time frame: JMM 11/7/2005 14:39
So, i suppose we could ask the author to comment this.
Cheers,
- Andreas
-- Best regards, Igor Stasenko AKA sig.
--
John M. McIntoshjohnmci@smalltalkconsulting.com Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
On 2010-03-23, at 2:30 PM, Andreas Raab wrote:
On 3/23/2010 10:50 AM, John M McIntosh wrote:
When the *high priority* task looking at the mouse location in the Browser see the cursor move between the browser windows it would change the cursor. Then invoke a tight loop to see when the cursor reentered a browser pane. This would drive 100,000 peekPosition starving the regular morphic loop. The result was that at the time the cursor would *stick* between browser panes if your timing was *just* right.
Which high priority task are you referring to? I think we might want to fix that, it seems completely pointless to run a loop like that.
In checking with a 3.10.2 image this morning that logic has been rewritten. I think you'll need to review were wait2ms is used, and work backward looking at the callers.
I'll note wait2ms doesn't exist in Pharo since it was eradicated with the EventSensor replacement.
=========================================================================== John M. McIntosh johnmci@smalltalkconsulting.com Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
On Mon, 2010-03-22 at 23:04 -0700, Andreas Raab wrote:
On 3/22/2010 7:27 PM, Lawson English wrote:
Croquet OpenGL is dependent on all sorts of things. Have you managed to get Croquet working in a modernish version of Squeak/Pharo?
(you will need an updated 4.1 trunk image - I've promoted Form>>flipVertically to core in the process of making this package)
From http://www.squeaksource.com/CroquetGL
The OpenGL interface from Croquet for consumption in other contexts. Supports OpenGL 1.4 plus extensions.
To install, first load the FFI via:
(Installer repository: 'http://source.squeak.org/FFI') install: 'FFI-Pools'; install: 'FFI-Kernel'; install: 'FFI-Tests'.
then load CroquetGL:
(Installer repository: 'http://www.squeaksource.com/CroquetGL') install: '3DTransform'; install: 'OpenGL-Pools'; install: 'OpenGL-Core'.
When everything has loaded, try the example:
OpenGL example.
Important Windows Note:
In order to use Croquet on Windows, you must make sure your VM is set to support OpenGL instead of D3D by default. To do this, press F2 or go to the system menu, into the "Display and Sound" section and ensure the preference "Use OpenGL (instead of D3D" is ENABLED.
Cheers,
- Andreas
I have a couple of questions about this.
First, I thought a lot of the OGL in squeak code required a special vm to understand a C style syntax for function calls. So how can this work? Possibilities: 1) 4.1 requires a new VM, and that VM has the feature enabled 2) existing squeak VM's support it 3) Croquet code uses that syntax, but it's not in the image. ogl calls should be conventional smalltalk style. 4) ....?
Second, does the later message
Yeah, I was wondering why it's so much slower in trunk than in our internal images or Croquet. First I thought it's the JIT but then I looked at a profile and found EventSensor>>wait2ms called from several places in EventSensor and indirectly via Sensor anyButtonPressed .
imply that performance will be painful?
I'm interested in this partly because Croquet is using lots of CPU when I try it. Since I don't need shared spaces, I was hoping something lighter weight would avoid the problem. And at least it has a VM with a known build procedure.
Thanks. Ross Boylan
On 30.03.2010, at 01:47, Ross Boylan wrote:
On Mon, 2010-03-22 at 23:04 -0700, Andreas Raab wrote:
On 3/22/2010 7:27 PM, Lawson English wrote:
Croquet OpenGL is dependent on all sorts of things. Have you managed to get Croquet working in a modernish version of Squeak/Pharo?
(you will need an updated 4.1 trunk image - I've promoted Form>>flipVertically to core in the process of making this package)
From http://www.squeaksource.com/CroquetGL
The OpenGL interface from Croquet for consumption in other contexts. Supports OpenGL 1.4 plus extensions.
To install, first load the FFI via:
(Installer repository: 'http://source.squeak.org/FFI') install: 'FFI-Pools'; install: 'FFI-Kernel'; install: 'FFI-Tests'.
then load CroquetGL:
(Installer repository: 'http://www.squeaksource.com/CroquetGL') install: '3DTransform'; install: 'OpenGL-Pools'; install: 'OpenGL-Core'.
When everything has loaded, try the example:
OpenGL example.
Important Windows Note:
In order to use Croquet on Windows, you must make sure your VM is set to support OpenGL instead of D3D by default. To do this, press F2 or go to the system menu, into the "Display and Sound" section and ensure the preference "Use OpenGL (instead of D3D" is ENABLED.
Cheers,
- Andreas
I have a couple of questions about this.
First, I thought a lot of the OGL in squeak code required a special vm to understand a C style syntax for function calls.
No. The VM does not know anything about syntax.
So how can this work? Possibilities:
- 4.1 requires a new VM, and that VM has the feature enabled
- existing squeak VM's support it
- Croquet code uses that syntax, but it's not in the image. ogl
calls should be conventional smalltalk style. 4) ....?
The compiler (which deals with syntax) is written in Smalltalk. You can have any syntax you like. Croquet experimented with this. But it does not have anything to do with the VM.
Second, does the later message
Yeah, I was wondering why it's so much slower in trunk than in our internal images or Croquet. First I thought it's the JIT but then I looked at a profile and found EventSensor>>wait2ms called from several places in EventSensor and indirectly via Sensor anyButtonPressed .
imply that performance will be painful?
No.
I'm interested in this partly because Croquet is using lots of CPU when I try it. Since I don't need shared spaces, I was hoping something lighter weight would avoid the problem.
This is just a raw way to interface with OpenGL. To be really useful you will have to write a 3G engine on top of it.
And at least it has a VM with a known build procedure.
Huh?
- Bert -
On Tue, 2010-03-30 at 01:54 +0200, Bert Freudenberg wrote:
And at least it has a VM with a known build procedure.
Huh?
Croquet and Cobalt ship with binary VM, and the procedure used to generate the VM is undocumented and almost unknown. By procedure I don't mean "run VMMaker", but what specific sources and tools were used to make the VM.
Fairly recent discussion on the cobalt list indicated the build procedure was in flux.
Thinking the problems I encountered might reflect some library mismatch, it seemed useful to be able to do the build myself.
Thanks Bert and Andreas for clearing up my misunderstandings about the opengl for squeak package.
Ross
On 30.03.2010, at 04:34, Ross Boylan wrote:
On Tue, 2010-03-30 at 01:54 +0200, Bert Freudenberg wrote:
And at least it has a VM with a known build procedure.
Huh?
Croquet and Cobalt ship with binary VM, and the procedure used to generate the VM is undocumented and almost unknown. By procedure I don't mean "run VMMaker", but what specific sources and tools were used to make the VM.
Fairly recent discussion on the cobalt list indicated the build procedure was in flux.
Thinking the problems I encountered might reflect some library mismatch, it seemed useful to be able to do the build myself.
It's a regular Squeak VM, nothing special. Try it.
There is a tendency to rename the Squeak VM when used for other projects, to make it "easier" for users. OTOH, that practice is creating more confusion for developers. OTTH, one would assume developers to know more than users, so the renamers and duplicaters insist they are right.
At least Linux developers have some sense and do not bundle the VM with the app. A single VM serves all. But then, Linux has built-in dependency management, a luxury that Mac OS and Windows do not have ...
- Bert -
On 2010-03-30, at 2:49 AM, Bert Freudenberg wrote:
There is a tendency to rename the Squeak VM when used for other projects, to make it "easier" for users. OTOH, that practice is creating more confusion for developers. OTTH, one would assume developers to know more than users, so the renamers and duplicaters insist they are right.
Well the more painful one is when they use the most current macintosh carbon VM, then swap in plugins from the Linux VM that are three or four years old. -- =========================================================================== John M. McIntosh johnmci@smalltalkconsulting.com Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
On 3/29/2010 4:47 PM, Ross Boylan wrote:
I have a couple of questions about this.
First, I thought a lot of the OGL in squeak code required a special vm to understand a C style syntax for function calls.
Both parts are incorrect. First, the OpenGL support doesn't require a special VM. It requires the Balloon 3D plugin to create a rendering surface but that's about it.
Second, 'syntax' is something not understood by the VM in general. The VM executes bytecodes and primitives. Syntax is handled by the Parser in Squeak. In Croquet, we had indeed special support for non-keyword method(foo, bar) calls but there is no intrinsic need for that. We're simply mapping all of these into a consistent set of keyword messages by prefixing them with the #with: keyword. So the mapping looks like here:
In C In Squeak glGetError() => glGetError glBegin(mode) => glBegin: mode glVertex2f(x, y) => glVertex2f: x with: y glVertex3f(x, y, z) => glVertex3f: x with: y with: z
up until stuff like
glBitmap(w, h, x, y, xm, ym, bm) => glBitmap: w with: h with: x with: y with: xm with: ym with: bm
Croquet always supported the keyword syntax, the non-keyword syntax was an addition that turned out to be much less useful than we had originally thought. When I posted the MC package I simply removed all the non-keyword methods.
Second, does the later message
Yeah, I was wondering why it's so much slower in trunk than in our internal images or Croquet. First I thought it's the JIT but then I looked at a profile and found EventSensor>>wait2ms called from several places in EventSensor and indirectly via Sensor anyButtonPressed .
imply that performance will be painful?
Not at all. Performance is quite good, we still use the same interface in our products and the actual code is straight out of Cobalt. So on a basic level the interface has production performance (what you do with it in your application layer is a different problem of course :-)
The above comment related to the benchmark which was limited by using Sensor anyButtonPressed in a tight loop - something you'd never do in an actual product but which is handy for a quick benchmark.
Cheers, - Andreas
Darn, tried that with the latest update of Seaside 3.0a. I had to use Monticello directly, rather than Installer. 'OpenGL example." returned the error MessageNotUnderstood: SystemDictionary>>platform
On 3/22/10 11:04 PM, Andreas Raab wrote:
On 3/22/2010 7:27 PM, Lawson English wrote:
Croquet OpenGL is dependent on all sorts of things. Have you managed to get Croquet working in a modernish version of Squeak/Pharo?
(you will need an updated 4.1 trunk image - I've promoted Form>>flipVertically to core in the process of making this package)
From http://www.squeaksource.com/CroquetGL
The OpenGL interface from Croquet for consumption in other contexts. Supports OpenGL 1.4 plus extensions.
To install, first load the FFI via:
(Installer repository: 'http://source.squeak.org/FFI') install: 'FFI-Pools'; install: 'FFI-Kernel'; install: 'FFI-Tests'.
then load CroquetGL:
(Installer repository: 'http://www.squeaksource.com/CroquetGL') install: '3DTransform'; install: 'OpenGL-Pools'; install: 'OpenGL-Core'.
When everything has loaded, try the example:
OpenGL example.Important Windows Note:
In order to use Croquet on Windows, you must make sure your VM is set to support OpenGL instead of D3D by default. To do this, press F2 or go to the system menu, into the "Display and Sound" section and ensure the preference "Use OpenGL (instead of D3D" is ENABLED.
Cheers,
- Andreas
On 5/27/10 7:54 PM, Lawson English wrote:
Darn, tried that with the latest update of Seaside 3.0a. I had to use Monticello directly, rather than Installer. 'OpenGL example." returned the error MessageNotUnderstood: SystemDictionary>>platform
Tried again with pristine Seaside 3.0a. Same message.
On 5/27/2010 7:54 PM, Lawson English wrote:
Darn, tried that with the latest update of Seaside 3.0a. I had to use Monticello directly, rather than Installer. 'OpenGL example." returned the error MessageNotUnderstood: SystemDictionary>>platform
What image are you using? There are no senders of #platform in OpenGL anywhere. There is #platformName (as in "Smalltalk platformName") but in 4.1 and later this works.
Cheers, - Andreas
On 3/22/10 11:04 PM, Andreas Raab wrote:
On 3/22/2010 7:27 PM, Lawson English wrote:
Croquet OpenGL is dependent on all sorts of things. Have you managed to get Croquet working in a modernish version of Squeak/Pharo?
(you will need an updated 4.1 trunk image - I've promoted Form>>flipVertically to core in the process of making this package)
From http://www.squeaksource.com/CroquetGL
The OpenGL interface from Croquet for consumption in other contexts. Supports OpenGL 1.4 plus extensions.
To install, first load the FFI via:
(Installer repository: 'http://source.squeak.org/FFI') install: 'FFI-Pools'; install: 'FFI-Kernel'; install: 'FFI-Tests'.
then load CroquetGL:
(Installer repository: 'http://www.squeaksource.com/CroquetGL') install: '3DTransform'; install: 'OpenGL-Pools'; install: 'OpenGL-Core'.
When everything has loaded, try the example:
OpenGL example.
Important Windows Note:
In order to use Croquet on Windows, you must make sure your VM is set to support OpenGL instead of D3D by default. To do this, press F2 or go to the system menu, into the "Display and Sound" section and ensure the preference "Use OpenGL (instead of D3D" is ENABLED.
Cheers,
- Andreas
On 5/27/10 8:09 PM, Andreas Raab wrote:
On 5/27/2010 7:54 PM, Lawson English wrote:
Darn, tried that with the latest update of Seaside 3.0a. I had to use Monticello directly, rather than Installer. 'OpenGL example." returned the error MessageNotUnderstood: SystemDictionary>>platform
What image are you using? There are no senders of #platform in OpenGL anywhere. There is #platformName (as in "Smalltalk platformName") but in 4.1 and later this works.
Cheers,
- Andreas
My bad, the error is indeed SystemDictionary>>platformName
Just tried it again with an updated Seaside 3.0a
PharoCore1.0rc3 Latest update: #10515
On 5/27/2010 8:18 PM, Lawson English wrote:
On 5/27/10 8:09 PM, Andreas Raab wrote:
On 5/27/2010 7:54 PM, Lawson English wrote:
Darn, tried that with the latest update of Seaside 3.0a. I had to use Monticello directly, rather than Installer. 'OpenGL example." returned the error MessageNotUnderstood: SystemDictionary>>platform
What image are you using? There are no senders of #platform in OpenGL anywhere. There is #platformName (as in "Smalltalk platformName") but in 4.1 and later this works.
Cheers,
- Andreas
My bad, the error is indeed SystemDictionary>>platformName
Just tried it again with an updated Seaside 3.0a
PharoCore1.0rc3
This is your problem. CroquetGL has not been tested on Pharo. I suspect Pharo 1.0 has still the dreadful "SmalltalkImage current platformName".
Cheers, - Andreas
On 5/27/10 8:27 PM, Andreas Raab wrote:
On 5/27/2010 8:18 PM, Lawson English wrote:
On 5/27/10 8:09 PM, Andreas Raab wrote:
On 5/27/2010 7:54 PM, Lawson English wrote:
Darn, tried that with the latest update of Seaside 3.0a. I had to use Monticello directly, rather than Installer. 'OpenGL example." returned the error MessageNotUnderstood: SystemDictionary>>platform
What image are you using? There are no senders of #platform in OpenGL anywhere. There is #platformName (as in "Smalltalk platformName") but in 4.1 and later this works.
Cheers,
- Andreas
My bad, the error is indeed SystemDictionary>>platformName
Just tried it again with an updated Seaside 3.0a
PharoCore1.0rc3
This is your problem. CroquetGL has not been tested on Pharo. I suspect Pharo 1.0 has still the dreadful "SmalltalkImage current platformName".
No problems. I'll mention it on the Pharo list though they may suggest using the OpenGL Alien version instead.
Lawson
squeak-dev@lists.squeakfoundation.org
-
Andreas Raab -
Bert Freudenberg -
Eliot Miranda -
Igor Stasenko -
John M McIntosh -
Josh Gargus -
Lawson English -
Nicolas Cellier -
Ross Boylan -
Vassili Bykov