Re: [Pharo-project] Ocean (was Re: Less plugins, more Smalltalk code! (was: Re: Pharo 1.1.1 OneClickCogVm))
On Oct 4, 2010, at 10:23 PM, Levente Uzonyi wrote:
On Mon, 4 Oct 2010, Sven Van Caekenberghe wrote:
Noury,
One of the other aspects that I find important is elementary efficiency.
A lot of stream related code in Smalltalk is not efficient, the actual data is copied around like crazy, turning it from a stream to a collection and then back into a stream multiple times. For Zinc HTTP Components I made a lot of effort to make it possible to read data from a socket stream in true streaming fashion (instead of just returning a byte array). Now, the idea was then that for example JPEGReadWriter>>#nextImage would work transparaently on that raw stream. Sadly, the code in JPEGReadWriter and friends just reads everything into an array before it starts to work !
Doing a #nextPutAll: <some byte array> should really try never to copy the array. Similary, a #next: <count> into: <some byte array> should similary write directly into the given array. What I see in the current SocketStream is <censored/> ;-)
This is why we implemented our own SocketStream in PostgresV3.
what is the license? Stef
But OK, maybe this is easier said than done. The step from Smalltalk to system call should also not copy if that is possible, but then FFI and GC come into play.
I wonder if there's a language, that provides socket access via FFI.
Levente
Anyway, good luck, I am willing to try using Ocean as soon as it becomes available.
Sven
On 04 Oct 2010, at 10:59, Noury Bouraqadi wrote:
On 3 oct. 2010, at 16:28, Schwab,Wilhelm K wrote:
For Ocean to succeed, you either have to work really hard to make non-blocking calls (I'm thinking of SSL sockets), or you need the ability to call functions on OS threads. The calls need to block their calling Process and let the other Processes run as though nothing is happening.
You're right. Another option is having a multi-threaded VM. Eliot seem to work on it. So far we're working on cleaning up the design of basic functionalities before going on. Then, we'll try to find a workaround for non-blocking calls. All ideas are welcome :-)
BTW, some people (you included) proposed to help for the Ocean project. Luc and I want to thank you and we are happy that others are willing to help. We thought about the best way to integrate others help. Our conclusion is that we should first do alone (luc and me) the reference design, before integrating other developers. So, we all can work on solid foudations.
Noury
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Tue, 5 Oct 2010, Stéphane Ducasse wrote:
On Oct 4, 2010, at 10:23 PM, Levente Uzonyi wrote:
On Mon, 4 Oct 2010, Sven Van Caekenberghe wrote:
Noury,
One of the other aspects that I find important is elementary efficiency.
A lot of stream related code in Smalltalk is not efficient, the actual data is copied around like crazy, turning it from a stream to a collection and then back into a stream multiple times. For Zinc HTTP Components I made a lot of effort to make it possible to read data from a socket stream in true streaming fashion (instead of just returning a byte array). Now, the idea was then that for example JPEGReadWriter>>#nextImage would work transparaently on that raw stream. Sadly, the code in JPEGReadWriter and friends just reads everything into an array before it starts to work !
Doing a #nextPutAll: <some byte array> should really try never to copy the array. Similary, a #next: <count> into: <some byte array> should similary write directly into the given array. What I see in the current SocketStream is <censored/> ;-)
This is why we implemented our own SocketStream in PostgresV3.
what is the license?
It's MIT, but it's not a general purpose SocketStream. Levente
Stef
But OK, maybe this is easier said than done. The step from Smalltalk to system call should also not copy if that is possible, but then FFI and GC come into play.
I wonder if there's a language, that provides socket access via FFI.
Levente
Anyway, good luck, I am willing to try using Ocean as soon as it becomes available.
Sven
On 04 Oct 2010, at 10:59, Noury Bouraqadi wrote:
On 3 oct. 2010, at 16:28, Schwab,Wilhelm K wrote:
For Ocean to succeed, you either have to work really hard to make non-blocking calls (I'm thinking of SSL sockets), or you need the ability to call functions on OS threads. The calls need to block their calling Process and let the other Processes run as though nothing is happening.
You're right. Another option is having a multi-threaded VM. Eliot seem to work on it. So far we're working on cleaning up the design of basic functionalities before going on. Then, we'll try to find a workaround for non-blocking calls. All ideas are welcome :-)
BTW, some people (you included) proposed to help for the Ocean project. Luc and I want to thank you and we are happy that others are willing to help. We thought about the best way to integrate others help. Our conclusion is that we should first do alone (luc and me) the reference design, before integrating other developers. So, we all can work on solid foudations.
Noury
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (2)
-
Levente Uzonyi -
Stéphane Ducasse