barad@brand.usc.edu (Herb Barad) (06/25/87)
I am currently using PS (on a Sun 3) to develop a prototype of a parallel architecture. There is a severe limitation that everyone should be aware of that could limit the usefulness of Smalltalk in large projects. The size of the object table can grow. However, the total size of the executable image cannot exceed 16 Bytes. This doesn't matter that you have a 68020 and can address MUCH further than that. The 16 Mbyte limit is hardcoded into their design. There are plans to remove this design flaw from PS, but don't expect that for about a year. If you think 16 Megs is a lot, just try working on a big project and see how quickly you approach the ceiling. Herb Barad [USC - Signal and Image Processing Institute] USENET: ...!sdcrdcf!oberon!brand!barad or ...!mcvax!seismo!sdcsvax!sdcrdcf!oberon!brand!barad ARPANET: barad@brand.usc.edu
allenw@tekchips.TEK.COM (Brock) (06/26/87)
In article <3005@oberon.USC.EDU>, barad@brand.usc.edu (Herb Barad) writes: > > I am currently using PS (on a Sun 3) to develop a prototype of a > parallel architecture. There is a severe limitation that everyone > should be aware of that could limit the usefulness of Smalltalk in > large projects. With Smalltalk, like all languages, care must be taken to distingish between between the characteristic of a particular implementation and the fundamental limitations of the language. Some commercially available Smalltalk implementations have much more severe limitations than those attributed to PS (its HARD to support a 16meg object space on a PC) while others do not have this particular limitation. The suitability of Smalltalk for any particular application will be determined by the capabilities of both the language itself and the available implementations. Please do not over generalize your experience with one particular implementaton. Allen Wirfs-Brock Software Productivity Technologies Tektronix Inc. allenw@spt.tek.com
franka@mmintl.UUCP (Frank Adams) (06/27/87)
In article <3005@oberon.USC.EDU> barad@brand.usc.edu (Herb Barad) writes: |I am currently using PS (on a Sun 3) to develop a prototype of a |parallel architecture. There is a severe limitation that everyone |should be aware of ... the total size of the executable image cannot |exceed 16 Bytes. That's a severe limitation, all right! -- Frank Adams ihnp4!philabs!pwa-b!mmintl!franka Ashton-Tate 52 Oakland Ave North E. Hartford, CT 06108
barad@brand.usc.edu (Herb Barad) (06/28/87)
In article <1384@tekchips.TEK.COM> allenw@tekchips.TEK.COM (Brock) writes: >With Smalltalk, like all languages, care must be taken to distingish >between between the characteristic of a particular implementation >and the fundamental limitations of the language. Some commercially >available Smalltalk implementations have much more severe limitations >than those attributed to PS (its HARD to support a 16meg object >space on a PC) while others do not have this particular limitation. Sorry, you are absolutely right. I did not mean to imply the limitation was in the language itself (it certainly isn't), I meant the particular implementation. Also, this type of restriction does apply to many implementations, but I hope not to all. I know that Tektronics supports a version. I assume from your response that it doesn't suffer from this limitation. Would you please enlighten me (and the other readers) as to Tektronics' implementation? Herb Barad [USC - Signal and Image Processing Institute] USENET: ...!sdcrdcf!oberon!brand!barad or ...!mcvax!seismo!sdcsvax!sdcrdcf!oberon!brand!barad ARPANET: barad@brand.usc.edu
obrien@aero2.UUCP (06/29/87)
In article <3065@oberon.USC.EDU> barad@othello.usc.edu.UUCP (Herb Barad) writes: >In article <1384@tekchips.TEK.COM> allenw@tekchips.TEK.COM (Brock) writes: >>With Smalltalk, like all languages, care must be taken to distingish >>between between the characteristic of a particular implementation >>and the fundamental limitations of the language. Some commercially >>available Smalltalk implementations have much more severe limitations >>than those attributed to PS (its HARD to support a 16meg object >>space on a PC) while others do not have this particular limitation. > >Sorry, you are absolutely right. I did not mean to imply the >limitation was in the language itself (it certainly isn't), I meant >the particular implementation. Also, this type of restriction does >apply to many implementations, but I hope not to all. Speaking to the specific problem, I've gotten a few things straightened out with ParcPlace Systems which may help. If you have a license to use PS on your Sun, then (according to them) you are licensed to use any VM and any VI on that machine, as far as they're concerned. In particular you can run BS II on that machine, and with its generation scavenging and lack of an OT, its memory system is sufficiently different not to suffer from this lack of space problem that PS has, apparently, inherited from the Sun-2. Unfortunately it is a) a research vehicle and hence buggy, and b) runs something like 5-6 times slower than PS. I recall reading somewhere that at least one of Tektronix' implementations also uses generation scavenging and hence does not suffer from space limitations (these two are only somewhat related, by the way). A Tektronix salesman once sounded me out as to whether I thought they should consider porting their implementation to Suns and selling it there (this was before ParcPlace Systems came into existence) and I told him emphatically that he should. Tektronix has done some admirable work on the image since starting up their product. Among these I certainly include their notion of attaching a Dictionary to every Workspace which holds permanent copies of variables defined as temporaries in DoIts which are typed and evaluated in the Workspace. Makes post facto debugging possible, which basically can't be done now unless you define globals in Smalltalk (the SystemDictionary). They have lots of nice little wins like that spread around in their system. -- -------- Mike O'Brien obrien@aerospace.aero.org {sdcrdcf,trwrb}aero!obrien
barad@othello.usc.edu (Herb Barad) (07/04/87)
I would like to clarify a point that I started with an article I posted a little while ago. I was not intending to discourage anyone from using PS. In fact, I feel that PS is a excellent product and is extremely well supported. The point I was making in my article had to do with a letter I received from an individual asking about the usefulness of Smalltalk (PS specifically) in "industrial strength" applications and I just wanted to point out a limitation that I have reached. Again, I feel that PS is a great tool for prototyping and it has been indespensible in my PhD research. I have also been told by the people at ParcPlace that this limit will be removed in an upcoming version. The limit won't just be increased, it will be removed and you will only be limited by your own h/w (and maybe operating system). I would heartily recommend PS. If you have any specific questions reguarding it, you can contact Nannette Harter at ParcPlace Systems: pplace!harter@sun.com I appologize for any misunderstandings... Herb Barad [USC - Signal and Image Processing Institute] email: barad@brand.usc.edu or ...!sdcrdcf!oberon!brand!barad