[squeak-dev] Squeak vision
Locked
12345
12345
Fast bytecode loader (was Re: [squeak-dev] Re: Squeak vision)
 
|
On 14.07.2009, at 03:01, [hidden email] wrote:
> Maybe it is just me, but "a fast bytecode package loader, without > the need > to compile Smalltalk code" combined with "such feature could make life > easier to third party Etoys developer and eventually attract more of > them > to Etoys" sounds like an endorsement of closed-source commercial > EToys. No, that's is a severe misunderstanding you construct here. > If > commercial success is not the attraction, what is? Faster initial load > time? Reduced file transfer size? Perhaps I assumed too much. Yes, both of these. The scenario we care most about is the one million kids using XO laptops. These machines are under-powered compared to recent PCs, and have rather little main memory. It's infeasible to have one image with all the extensions to Etoys, because the whole image is loaded into RAM. It would be very nice if these add-ons could be delivered as separate packages and loaded on demand. That's what the current Dr Geo II package is doing. But it is slow, because all the code is compiled to byte code when loading the package. The Squeak byte code compiler has not exactly been optimized for speed, because in usual development you only compile a method at a time. In any case, the *result* of loading a package that includes both source code and byte code would be exactly the same as compiling the source code, but way faster. This could also be used to speed up package loading in general. In fact, this would make the concept of "libraries" feasible in Squeak - packages loaded on demand. Think about pre-compiled lisp modules, or the .pyc files generated from .py Python files for speed. Note I'm not advocating this for Squeak but it would make it technically feasible. It's just not exactly trivial to do in a robust way. At the very least, all global references in the compiled methods will have to be updated. This includes classes which have to be referenced, Symbols need to get interned and unified. The source could be appended to the changes file and source pointers incremented, or the source could remain in separate files but we'd need a new source code scheme for that. I think this all would be immensely useful in the long run, but truth is we have been getting by without for so long that there just does not seem to be anybody both motivated and skilled enough to do it. - Bert - |
RE: Fast bytecode loader (was Re: [squeak-dev] Re: Squeak vision)
|
|
Hi Bert,
> From: [hidden email] > To: [hidden email] > Subject: Fast bytecode loader (was Re: [squeak-dev] Re: Squeak vision) > Date: Thu, 16 Jul 2009 13:40:12 +0200 > > On 14.07.2009, at 03:01, [hidden email] wrote: > > > Maybe it is just me, but "a fast bytecode package loader, without > > the need > > to compile Smalltalk code" combined with "such feature could make life > > easier to third party Etoys developer and eventually attract more of > > them > > to Etoys" sounds like an endorsement of closed-source commercial > > EToys. > > No, that's is a severe misunderstanding you construct here. > > > If > > commercial success is not the attraction, what is? Faster initial load > > time? Reduced file transfer size? Perhaps I assumed too much. > > > Yes, both of these. The scenario we care most about is the one million > kids using XO laptops. These machines are under-powered compared to > recent PCs, and have rather little main memory. It's infeasible to > have one image with all the extensions to Etoys, because the whole > image is loaded into RAM. It would be very nice if these add-ons could > be delivered as separate packages and loaded on demand. > > That's what the current Dr Geo II package is doing. But it is slow, > because all the code is compiled to byte code when loading the > package. The Squeak byte code compiler has not exactly been optimized > for speed, because in usual development you only compile a method at a > time. In any case, the *result* of loading a package that includes > both source code and byte code would be exactly the same as compiling > the source code, but way faster. > > This could also be used to speed up package loading in general. In > fact, this would make the concept of "libraries" feasible in Squeak - > packages loaded on demand. Think about pre-compiled lisp modules, or > the .pyc files generated from .py Python files for speed. Note I'm not > advocating this for Squeak but it would make it technically feasible. > > It's just not exactly trivial to do in a robust way. At the very > least, all global references in the compiled methods will have to be > updated. This includes classes which have to be referenced, Symbols > need to get interned and unified. The source could be appended to the > changes file and source pointers incremented, or the source could > remain in separate files but we'd need a new source code scheme for > that. > > I think this all would be immensely useful in the long run, but truth > is we have been getting by without for so long that there just does > not seem to be anybody both motivated and skilled enough to do it. I was under the impression that Spoon does this. i.e. loading Classes/Methods without compilation. Cheers, Andy > > - Bert - > > > Beyond Hotmail - see what else you can do with Windows Live. Find out more. |
Re: Fast bytecode loader (was Re: [squeak-dev] Re: Squeak vision)
|
|
In reply to this post by Bert Freudenberg
On Thu, Jul 16, 2009 at 4:40 AM, Bert Freudenberg <[hidden email]> wrote: On 14.07.2009, at 03:01, [hidden email] wrote: This has been done for Smalltalk before. The Digitalk SLL mechanism loaded code using a mechanism essentially isomorphic to image segments. The VisualWorks parcel mechanism is more like a reference stream but optimised for speed of loading (and because its not tied to the VM's object format is much more flexible and future-proof, and turned out to be very fast).
IIRC, the Digitalk SLL system didn't support source (the source needed to be already present). The VW parcel system doesn't need to append source to the changes file. Instead a parcel is a pair of files, a binary file and a source file. The SourcesFiles is replaced by a proper SourceFileManager that can register multiple source files, handing out an index to a source file, so that on load a CompiledMethod's source index is updated with the index the SourceFileManager assigns to the registered source file.
I think this all would be immensely useful in the long run, but truth is we have been getting by without for so long that there just does not seem to be anybody both motivated and skilled enough to do it. |
|
|
Am 16.07.2009 um 18:38 schrieb Eliot Miranda:
> This has been done for Smalltalk before. The Digitalk SLL mechanism > loaded code using a mechanism essentially isomorphic to image > segments. The VisualWorks parcel mechanism is more like a reference > stream but optimised for speed of loading (and because its not tied > to the VM's object format is much more flexible and future-proof, > and turned out to be very fast). Just an addition: I think that the version management system Envy (only used in VA Smalltalk nowadays) also loads bytecode. So I would even say that bytecode loading is the default way in commercial Smalltalks. Cheers, Bernhard |
|
|
In reply to this post by Bert Freudenberg
Em 16-07-2009 08:40, Bert Freudenberg escreveu:
> On 14.07.2009, at 03:01, [hidden email] wrote: > >> Maybe it is just me, but "a fast bytecode package loader, without the >> need >> to compile Smalltalk code" combined with "such feature could make life >> easier to third party Etoys developer and eventually attract more of >> them >> to Etoys" sounds like an endorsement of closed-source commercial EToys. > > No, that's is a severe misunderstanding you construct here. > >> If >> commercial success is not the attraction, what is? Faster initial load >> time? Reduced file transfer size? Perhaps I assumed too much. > > > Yes, both of these. The scenario we care most about is the one million > kids using XO laptops. These machines are under-powered compared to > recent PCs, and have rather little main memory. It's infeasible to > have one image with all the extensions to Etoys, because the whole > image is loaded into RAM. It would be very nice if these add-ons could > be delivered as separate packages and loaded on demand. But to have millions of kids using XO laptops it is necessary to supply a product that has commercial appeal. Moreover in 3rd world countries where the political discourse behind money employed in buying and distributing these PCs is based on the fact that children will be enabled to gain technical skills that will allow them to leave the "prison of poverty". In this line of real life context, other participants like IBM/Unisys/Dell/HP/Sun/Microsoft/Borland/etc argue that they have better stuff than the "under powered" OLPC (for instance) and that nothing interesting will result from teaching smalltalk and it would be better to "train children" to use "more significant technologies" (sic) like Java/.NET/MVC/MVB/Delphi/etc... Many countries, like Brazil, have laws that make computer donations to public schools almost (if not absolutely) impossible. For the interested ones, just take a look at Federal Law 8666 (http://www.planalto.gov.br/ccivil/Leis/L8666cons.htm). Thus, unless a big boss patronizes embedding squeak inside the product they'll be selling to government through public bid... children will learn something else. I am aware that other 3rd world countries have the same legal problems. And even in countries that doesn't have specific laws (moreover the ones with big population) the donation of XO laptops may be non viable due to costs involved, so a sales scheme is to be devised. On the other hand, why would a government invest in something that has no commercial appeal? Governments are elected (usually by people) so they care for immediate results of their policies. Consider the reality of 3rd world countries where day to day survival is a really concrete concern of population. Government actions are aimed to discourses like: "now your children is entitled to run for better jobs". No commercial relevance, no better jobs, no action by governments. > > That's what the current Dr Geo II package is doing. But it is slow, > because all the code is compiled to byte code when loading the > package. The Squeak byte code compiler has not exactly been optimized > for speed, because in usual development you only compile a method at a > time. In any case, the *result* of loading a package that includes > both source code and byte code would be exactly the same as compiling > the source code, but way faster. > > This could also be used to speed up package loading in general. In > fact, this would make the concept of "libraries" feasible in Squeak - > packages loaded on demand. Think about pre-compiled lisp modules, or > the .pyc files generated from .py Python files for speed. Note I'm not > advocating this for Squeak but it would make it technically feasible. > > It's just not exactly trivial to do in a robust way. At the very > least, all global references in the compiled methods will have to be > updated. This includes classes which have to be referenced, Symbols > need to get interned and unified. The source could be appended to the > changes file and source pointers incremented, or the source could > remain in separate files but we'd need a new source code scheme for that. > > I think this all would be immensely useful in the long run, but truth > is we have been getting by without for so long that there just does > not seem to be anybody both motivated and skilled enough to do it. > > - Bert - > > > > |
Re: Fast bytecode loader (was Re: [squeak-dev] Re: Squeak vision)
|
|
In reply to this post by bpi
On Thu, Jul 16, 2009 at 10:51 AM, Bernhard Pieber <[hidden email]> wrote: Am 16.07.2009 um 18:38 schrieb Eliot Miranda: Oops! Bad of me to forget that one! Thanks Bernhard, and apologies to all at Carleton, OTI and IBM who I've offended :)
|
Re: Fast bytecode loader (was Re: [squeak-dev] Re: Squeak vision)
|
|
In reply to this post by CdAB63
Hi Casimiro,
perhaps this isn't the place for such a political discussion but forgive me for butting in. I'm basing my comments in part on the recent article in CACM One Laptop Per Child: Vision vs. Reality [1].
On Thu, Jul 16, 2009 at 10:57 AM, Casimiro de Almeida Barreto <[hidden email]> wrote: Em 16-07-2009 08:40, Bert Freudenberg escreveu: There is also more at stake than gaining technical skills, as evidenced by the Waveplace curriculum. There is also access to literature and art, a context for communication, community and play, and a context for self-expression. Technical skills only provide a route out of povertyif those skills are in demand, and demand for software engineers is limited. There are, and must be other ways to escape the prison of poverty. If we look at the failed models of international aid and development in the last century that are finally being seen as failures in this century a fundamental principle has to be the enablement of communities to enrich themselves culturally as well as economically, not something western corporate efforts have been behind at all.
As described in [1] there is clearly a struggle between those who would like to see OLPC available at as low-cost as possible, the originators of the OLPC project, and commercial interests who want to provide alternatives to OLPC. The motives of the originators are clear, but one also has to examine the motives of those commercial interests.
In this line of real life context, other participants like IBM/Unisys/Dell/HP/Sun/Microsoft/Borland/etc argue that they have better stuff than the "under powered" OLPC (for instance) and that nothing interesting will result from teaching smalltalk and it would be better to "train children" to use "more significant technologies" (sic) like Java/.NET/MVC/MVB/Delphi/etc... These commercial interests, all either Wintel-centric or Wintel itself, see OLPC as a threat and have moved swiftly first to co-opt it and then, when their attempts had stalled, to undermine it. Why? It seems to me that they want to lock in potential consumers and view OLPC as providing a route out of the Wintel dominance of the desktop market. If I'm right then why help the Wintel nexus to extend its reach? Does it really provide anything of vaue? I'd argue strongly that it offers limited value, and at best shoddy quality (cf Apple).
I find it interesting, but too time-consuming, to determine if this is a short-sighted approach or a sound business approach, albeit predatory. After all if OLPC provides millions of new potential computer users then surely the Wintel nexus can provide professional products for them to use. Perhaps it is afraid that OLPC provides a richer experience than available on its platforms and that consequently it fears people who have grown up with OLPC will dismiss its offerings in later life. I certainly hope so.
Many countries, like Brazil, have laws that make computer donations to public schools almost (if not absolutely) impossible. For the interested ones, just take a look at Federal Law 8666 (http://www.planalto.gov.br/ccivil/Leis/L8666cons.htm). Thus, unless a big boss patronizes embedding squeak inside the product they'll be selling to government through public bid... children will learn something else. So is this to be taken as reason to kowtow to Wintel or as a signal to try and change the law? I am aware that other 3rd world countries have the same legal problems. And even in countries that doesn't have specific laws (moreover the ones with big population) the donation of XO laptops may be non viable due to costs involved, so a sales scheme is to be devised. "Commercial appeal" is in part the product of marketing and in part the product of commercial relevance, and relevance is different if you're an established business looking to limit innovation and find cheap labour with an existing well-specified set of vocational skills, or you're a new business looking to innovate and looking for people with new skills and new ideas. This conflict is played out in many arenas. I well remember the arguments in my computer science department in the UK in the 80's and 90' as people debated whether to teach using C++, because "thats what industry wants" or to continue using a range of languages embodying key concepts such as Pascal, assembler, ML, Miranda, Prolog and Smalltalk, because once a student grasps a concept they can apply it in many different contexts.
I think that this is at the crux of this discussion. Supporting OLPC against commercial interests is at root supporting the emancipation of peoples and supporting established commercial involvement is supporting the status quo. There is presumably a middle ground where new commercial interests who are not defending established markets [and not trying to wring the last drops of milk from a rotting fetid software base, ed] an contribute in a win-win way. But I don't see that supporting commercial involvement in OLPC is de-facto a good thing.
|
|
|
In reply to this post by Eliot Miranda-2
Am 16.07.2009 um 20:15 schrieb Eliot Miranda:
> Oops! Bad of me to forget that one! Thanks Bernhard, and apologies > to all at Carleton, OTI and IBM who I've offended :) Just for the records, I did not feel offended in even the slightest way. I was just a little bit proud that I could add some small bit of info to the thread. ;-) Cheers, Bernhard |
[squeak-dev] children (was: Fast bytecode loader)
|
|
In reply to this post by CdAB63
Casimiro de Almeida Barreto wrote:
> But to have millions of kids using XO laptops it is necessary to supply > a product that has commercial appeal. Moreover in 3rd world countries > where the political discourse behind money employed in buying and > distributing these PCs is based on the fact that children will be > enabled to gain technical skills that will allow them to leave the > "prison of poverty". Those interested in seeing some of these millions of children using Etoys on their XO machines should come to Porto Alegre (Brazil) next week: http://squeakfest.org/ Note that one of the technical requirements in last December's tender to buy 150 thousand laptops by Brazil's Education Ministry was that the machine should run Squeak. So we can afford to be optimistic... -- Jecel |
|
|
In reply to this post by CdAB63
Em 17-07-2009 00:00, Jecel Assumpcao Jr escreveu:
Some numbers:Casimiro de Almeida Barreto wrote: Secretaria Municipal de Educação - São Paulo City - 1.029.645 students - 861 EMEIS & 512 EMEFS Secretaria de Estado da Educação - São Paulo State COGSP - Great SP - 2.721.901 students CEI - Country side - 2.716.973 students Number of teachers: around 250.000 The numbers are not cumulative: meaning, the 1.029.645 are not included in COGSP/CEI numbers and does not reflect numbers of other schools managed by municipal governments. So, even thinking only about São Paulo city the problem is not small. Current priorities: 11,8% of children in the range 7-11 yo aren't in school. As can be read in yesterday newspapers (Folha de São Paulo). To have chance of getting mainstream, squeak must show appeal other than philosophical discourses about freedom & breaking monopolies. In short: no perspective of training students in something readily usable in market... no deal. About the bid of "Um Laptop por Aluno" of the Ministry of Education (the 150.000 laptops): the business is "sub judice" and probably a new bid will be necessary. CdAB |
Re: Fast bytecode loader (was Re: [squeak-dev] Re: Squeak vision)
|
|
In reply to this post by CdAB63
At Thu, 16 Jul 2009 14:57:58 -0300,
Casimiro de Almeida Barreto wrote: > > Many countries, like Brazil, have laws that make computer donations to > public schools almost (if not absolutely) impossible. For the interested > ones, just take a look at Federal Law 8666 > (http://www.planalto.gov.br/ccivil/Leis/L8666cons.htm). Thus, unless a > big boss patronizes embedding squeak inside the product they'll be > selling to government through public bid... children will learn > something else. License-wise, there is nothing that would stop anybody to package Etoys and sell it. It would be actually good for the community, especially if somebody can start a company in Brazil or somewhere... -- Yoshiki |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |