- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Parsing Pharo syntax to C/C++

by David T. Lewis

On Mon, Sep 15, 2014 at 11:28:24AM +0200, Santiago Bragagnolo wrote: > I may be wrong, but I think the closest thing out there is Slang. Is the > pseudo smalltalk used to develop the VM. > A bit off topic, but just for clarification: "Slang" is not a language. It is just a casual name to refer to the subset of Smalltalk that can be easily translated to a language such as C. Some of this Smalltalk may be written in awkward ways in order to make sure it can be translated to a lower level language, but it is real Smalltalk nonetheless. The VM is not written in Slang, it is written in Smalltalk. When people talk about running the VM simulator, they are talking about running the VM in its native Smalltalk implementation, as opposed to running the code that is more commonly translated to C and linked to the platform support code. There is no psuedo Smalltalk involved, it is the real thing. Dave

Sept. 17, 2014

Re: [Pharo-dev] [squeak-dev] Re: The Dilemma: Building a Futuristic GUI for Ephestos

by Sean P. DeNigris

Eliot Miranda-2 wrote > without losing window > state, and one can switch dynamically, and, IIRC, mix both That /is/ cool :) ----- Cheers, Sean -- View this message in context: http://forum.world.st/The-Dilemma-Building-a-Futuristic-GUI-for-Ephestos-tp… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Sept. 17, 2014

Re: [Pharo-dev] [squeak-dev] Re: The Dilemma: Building a Futuristic GUI for Ephestos

by Torsten Bergmann

Hi Eliot, Yes - in the past most Smalltalks did not have native widgets and usually emulated the L&F. I remember VW on a Sun Sparc with Windows or Mac look. While it was cool to run 1:1 on another machine it would have been to much manpower for the vendor to reimplement all the nice widgets to really look like the native system. Especially when the L&F changed very often between Win95/96/XP/Win7/Win8 at Microsoft. Even with good looking widgets/icons one could see from the speed and repainting issues (white rectangles for damage areas) that Smalltalk was not native. Also native widgets had other nice features like virtual modes for TreeViews/ListViews used if you want to display many nodes. Java faced the same problem - even with Swing and JavaFX today the Java UIs and especially the ugly JFileDialog never had this "Native look and easy navigation feeling". And yes there is SWT in Java providing native widgets - but how many applications are based on it? Only a few. On the ST side Smalltalk/MT and Dolphin use native widgets but were not portable. And if you look at others like VW, VAST or Smalltalk/X you will see that engineers are good at creating powerfull systems but often fail when it comes to UI design and usability. Squeak was special and flexible with Morphic (even without multiple windows) - but looked too toyish. So yes - customers of commercial Smalltalk vendors asked for "Native" because if you had built a UI in Smalltalk it was part of a rich client application and often people compared it to other native applications or new widgets found in MS Office. But in the past customer also asked for COM/COM+, CORBA and webservices while today it is often much easier to exchange data or call functionality via HTTP, REST, ... So time and expectations have changed a lot meanwhile. Especially for the UI's. Desktop platforms unite with the web and in the web it is also possible to look more like platforms or style to look like a native app. See [1] and [2] for two simple examples. While the browsers and JS engines become faster this will also change more the way we think about applications: no installation, styleable, clear look. The google chrome experiments are a good page to see how this will soon look like. And we will be independent from devices and screen resolution. In fact more and more applications we use today run on a computers webbrowser, tablet or a smartphone (often the same way). With Morphic (even when it has Fenestri) we can not compete agains HTML/CSS on the UI side. The Canvas element and WebGL will also drive this forward. Even if one does not like web technologies - it currently is the platform where you reach people easily. Smalltalk should/could have a place in this (web centric) world: 1. As a backend to serve the web 2. On the client 3. Combining 1. and 2. For the first we have Seaside, TeaPot, Aida, ... For the seond: as it will not happen that browser vendors agree and threw out JavaScript in favour of ST runtimes, maybe we can build on top like Amber or SqueakJS do. But we should also rethink Smalltalk to find a better place as a scripting language. What I still would like to see: - tiny and fast VM with a command line and REPL - one unified and easy to use FFI with callbacks so one can use the platform, maybe others will write the bindings then - single small base image but fast loadable binary code components (modules, maybe using the LoadLibrary trick), similar to what David had with SmallScript or what BeeSmalltalk is doing with SLL's - but still with the ability to bootstrap up to a full saveable image - ability to serve the web with easy callbacks into Smalltalk for implementing functionality (especially with this we may catch 90% of the usual UI cases). Bye T. [1] Metro theme Bootstrap http://talkslab.github.io/metro-bootstrap/components.html [2] jQuery Desktop http://desktop.sonspring.com/ [3] Chrome Experiments http://www.chromeexperiments.com/

Sept. 16, 2014

Re: [Pharo-dev] [Moose-dev] [ANN] Test Coverage with Hapao

by Alexandre Bergel

Excellent! Alexandre > Le 16-09-2014 Ã 16:15, Tudor Girba <tudor(a)tudorgirba.com> a Ã©crit : > > Great! > > I will go over it more thoroughly in the following weeks and get back to you with feedback. > > Cheers, > Doru > > > >> On Tue, Sep 16, 2014 at 6:03 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: >> Dear all, >> >> We are happy to release Hapao2 for Pharo. Ricard Jacas and Alejandro Infante put quite some work on Spy2 (an Ã¼ber cool profiling framework for Pharo) and Hapao2. >> Hapao2 is about assessing the test coverage of your code and is a major revamp of Hapao1, which was presented a couple of years ago by Vanessa. >> Hapao2 does not only list covered and uncovered methods, as most test coverage tool on Earth will do. Hapao gives a great visualization to easily navigate in your code, assess its complexity, and give you a great visual output telling its coverage. >> >> You need Roassal in your image: >> >> Gofer new smalltalkhubUser: 'ObjectProfile' >> project: 'Roassal2'; >> package: 'ConfigurationOfRoassal2'; >> load. >> (Smalltalk at: #ConfigurationOfRoassal2) load >> >> >> and you need S2py: >> MCHttpRepository >> location: 'http://smalltalkhub.com/mc/ObjectProfile/S2py/main' >> user: '' >> password: '' >> >> >> New entries will appear in the world menu: >> <Screen Shot 2014-09-16 at 11.49.06 AM.png> >> >> You can run the test coverage on : >> - the class classes you have modified, >> - on a particular >> - on a particular class category >> - on the last class categories you have modified >> - on the last packages you have modified >> >> Here is a portion of a large coverage: >> >> <Screen Shot 2014-09-16 at 12.00.11 PM.png> >> >> A technical description of Hapao may be found on http://bergel.eu/download/papers/Berg12c-HapaoSCP.pdf >> >> We are daily using Hapao to help us understand our tests. >> >> Cheers, >> Ricardo, Alejandro & Alexandre >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > > -- > www.tudorgirba.com > > "Every thing has its own flow"

Sept. 16, 2014

Re: [Pharo-dev] [Vm-dev] re: Parsing Pharo syntax to C/C++

by Eliot Miranda

On Tue, Sep 16, 2014 at 5:33 AM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > > 2014-09-16 14:19 GMT+02:00 kilon alios <kilon.alios(a)gmail.com>: > >> Python is a great language why one would use it behind anyone's back ? >> >> Python has several ways to deal with static typing, performance and >> optimization, cython, shedskin , pypy and lately its creators linked a new >> kind of python that allows for static types in his twitter feed. >> >> There are also ways for python to take advantage LLVM one such project is >> by Dropbox people (Where the creators of Python currently works for) called >> "pyston" for high performance python --> >> https://tech.dropbox.com/2014/04/introducing-pyston-an-upcoming-jit-based-p… >> >> >> and the list goes on.... and on..... and on.... >> > > Everything you describe are partial solutions which suits the Python > community well for their needs. If python was suited for RT, embedded work, > it would be an horror to work with. The same goes with Smalltalk. > > You're not supposed to have fun when you do embedded, RT work. You are > supposed to suffer :( This is no place for the creative spirit. > I think you need therapy ;-) Why not be positive and think about how you could make these technologies work? I'm sure Smalltalk and Cog can do soft real-time. People have been using it to do music for as long as its been in existence. If you could get beyond your "it can't be done" mind set and get into a "how might this be done" mindset you might make a real contribution. Right now you're being a real downer. -- best, Eliot

Sept. 16, 2014

Re: [Pharo-dev] [Vm-dev] re: Parsing Pharo syntax to C/C++

by Eliot Miranda

Hi Kilon, On Tue, Sep 16, 2014 at 5:07 AM, kilon alios <kilon.alios(a)gmail.com> wrote: > Is there any other documentation for Slang apart from the link in squeak > wiki ? > Read the VM sources; they're the best example of what it does. But alas documentation is poor here. You might read Lazy Become and Primitives <http://www.mirandabanda.org/cogblog/2014/02/08/primitives-and-the-partial-r…> as an example of what one can do. > Hows Slang deals with manual memory management ? > Poorly. Essentially one uses cCode: [.....] inSmalltalk: [...] to separate the solutions used in each realm. For example, in the Cog JIT arrays of instructions, branch fixups and stack entry descriptors are the key data structures in code generation. In the Simulator these are Smalltalk objects, and the Smalltalk GC reclaims memory. In the C VM these are stack allocated via alloca and reclaimed on return. Further, Spur supports pinned objects on the heap which the system can use to allocate memory in place of malloc (the advantage being that the Simulator can use this memory also). The simulator *could* use malloc if it contained a malloc simulation, but as yet I haven't needed it, and given Spur's support for pinned objects it is not compelling to implement a malloc simulation. > > On Tue, Sep 16, 2014 at 12:48 PM, ClÃ©ment Bera <bera.clement(a)gmail.com> > wrote: > >> >> >> 2014-09-16 1:46 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com>: >> >>> >>> Hi Ronie, >>> >>> On Mon, Sep 15, 2014 at 2:37 PM, Ronie Salgado <roniesalg(a)gmail.com> >>> wrote: >>> >>>> >>>> Hello, >>>> >>>> I am segmenting this mail in several sections. >>>> >>>> --------------------------------------------------------------- >>>> - On Lowcode and Cog >>>> >>>> I have been working in the last week with the Cog VM, implementing the >>>> Lowcode instructions in Cog. >>>> >>> >>> remember to send me code for integration. I'm eagerly waiting to use >>> your code! >>> >>> Lowcode is currently a spec of new bytecode instructions. These >>>> instructions can be used for: >>>> - Implementing a C like language compiler. >>>> - Making FFI calls >>>> >>>> I am implementing these instructions using a feature of the new >>>> bytecode set for SistaV1, which is called "inline primitives". Because of >>>> this, these new instructions can be mixed freely with the standard VM >>>> bytecode set. This also allows the Sista adaptive optimizer to inline FFI >>>> calls. >>>> >>>> These instructions provides features for: >>>> - Int32 and Int64 integer arithmetic without type checking. >>>> - Pointers, with arithmetics. >>>> - Memory access and memory manipulation. >>>> - Single and double precision floating point arithmetics. >>>> - Conversion between primitive types. >>>> - Boxing and unboxing of primitive types. >>>> - Unchecked comparisons. >>>> - Native function call. Direct and indirect calls. >>>> - The atomic operation compare and swap. >>>> - Object pin/unpin (requires Spur). >>>> - VM releasing and grabbing for threaded ffi. >>>> >>>> Current I have implemented the following backends: >>>> - A C interpreter plugin. >>>> - A LLVM based backend. >>>> >>>> Currently I am working in getting this working using the Cog code >>>> generator. So far I am already generating code for >>>> int32/pointer/float32/float64. I am starting to generate C functions calls >>>> and object boxing/unboxing. >>>> >>>> During this work I learned a lot about Cog. Specially that Cog is >>>> missing a better Slang generator, that allows to force better inlining and >>>> more code reviews. There is a lot of code duplication in Cog, that can be >>>> attributed to limitations of Slang. In my opinion, if we could use Slang >>>> not only for building the VM we should end with a better code generator. In >>>> addition we, need more people working in Cog. We need people that performs >>>> code reviews and documentation of Cog. >>>> >>>> After these weeks, I learned that working in Cogit it is not that hard. >>>> Our biggest problem is lack of documentation. Our second problem could be >>>> the lack of documentation about Slang. >>>> >>> >> Lack of documentation ? >> >> About Cog there are these documentation: >> Back to the future <http://ftp.squeak.org/docs/OOPSLA.Squeak.html> >> About VMMaker <http://wiki.squeak.org/squeak/2105> >> Object engine >> <http://www.rowledge.org/resources/tim%27s-Home-page/Squeak/OE-Tour.pdf> >> General information <http://squeakvm.org/index.html> >> Blue book part 4 >> <http://stephane.ducasse.free.fr/FreeBooks/BlueBook/Bluebook.pdf> >> Deep into Pharo part 4 about blocks and exceptions >> <http://www.deepintopharo.com/> >> VMIL paper about Cogit >> <http://design.cs.iastate.edu/vmil/2011/papers/p03-miranda.pdf> >> The Cog blog <http://www.mirandabanda.org/cogblog/> >> About Spur: summary >> <http://clementbera.wordpress.com/2014/02/06/7-points-summary-of-the-spur-me…> and >> object format >> <http://clementbera.wordpress.com/2014/01/16/spurs-new-object-format/> >> This post >> <http://clementbera.wordpress.com/2013/08/09/the-cog-vm-lookup/> >> And many useful class and method comments that taught me a lot. >> >> When I try to work with Pharo frameworks, even recent ones, it is very >> rare that I see as much documentation than it exists for Cog. Some >> frameworks are documented in the Pharo books and a few other as Zinc have >> good documentation, but in general, there are few documentation and *even >> fewer people writing documentation*. The website about Cog has existed >> for over 6 years now. I think Cog is far from the worst documented part of >> Pharo. >> >> >>> Yes, and that's difficult because it's a moving target and I have been >>> lazy, not writing tests, instead using the Cog VM as "the test". >>> >>> It's also difficult because the first tests to write are the hardest to >> write. >> >> I am so happy to have your involvement. You and ClÃ©ment bring such >>> strength and competence. >>> >>> --------------------------------------------------------------- >>>> - Smalltalk -> LLVM ? >>>> >>>> As for having a Smalltalk -> LLVM code generator. The truth is that we >>>> will not gain anything. LLVM is a C compiler, which is designed to optimize >>>> things such as loops with lot of arithmetics. It is designed to optimize >>>> large sections of code. In Smalltalk, most of our code is composed mostly >>>> of message sends. LLVM cannot optimize a message send. >>>> >>>> To optimize a message send, you have to determine which is the method >>>> that is going to respond to the message. Then you have to inline the >>>> method. And then you can start performing the actual optimizations, such as >>>> constant folding, common subexpressions, dead branch elimination, loop >>>> unrolling, and a long etc. >>>> >>>> Because we don't have information in the actual language (e.g. static >>>> types a la C/C++/Java/C#) that tells us what is going to be the actual >>>> method invoked by a message send, we have the following alternatives to >>>> determine it: >>>> - Don't optimize anything. >>>> - Perform a costly static global analysis of the whole program. >>>> - Measure in runtime and hope for the best. >>>> - Extend the language. >>>> >>>> In other words, our best bet is in the work of ClÃ©ment in Sista. The >>>> only problem with this bet are real time applications. >>>> >>> >>> Ah! But! Sista has an advantage that other adaptive optimizers don't. >>> Because it optimizes from bytecode to bytecode it can be used during a >>> training phase and then switched off. >>> >> >>> Real time applications requires an upper bound guarantee in their >>>> response time. In some cases, the lack of this guarantee can be just an >>>> annoyance, as happens in video games. In some mission critical applications >>>> the results can not be good, if this time constraint is not met. An example >>>> of a mission critical system could the flight controls of an airplane, or >>>> the cooling system of a nuclear reactor. >>>> >>>> For these application, it is not possible to rely in an adaptive >>>> optimizer that can be triggered sometimes. In these application you have to >>>> either: >>>> - Extend the language to hand optimize some performance critical >>>> sections of code. >>>> - Use another language to optimize these critical section. >>>> - Use another language for the whole project. >>>> >>> >>> The additional option is to "train" the optimizer by running the >>> application before deploying and capturing the optimised methods. Discuss >>> this with ClÃ©ment and he'll explain how straight-forward it should be. >>> This still leaves the latency in the Cogit when it compiles from bytecode >>> to machine code. But >>> >>> a) I've yet to see anybody raise JIT latency as an issue in Cog >>> b) it would be easy to extend the VM to cause the Cogit to precompile >>> specified methods. We could easily provide a "lock-down" facility that >>> would prevent Cog from discarding specific machine code methods. >>> >>> And of course, you have to perform lot of profiling. >>>> >>> >>> Early and often :-). >>> >>> Because we can have complete control over the optimizer, and because >>> Sista is byetcode-to-bytecode and can hence store its results in the image >>> in the form of optimized methods, I believe that Sista is well-positioned >>> for real-time since it can be used before deployment. In fact we should >>> emphasise this in the papers we write on Sista. >>> >> >> The solution of Eliot makes sense. >> To write a paper about that I need benchs showing result on real time >> applications. >> So there's quite some work to do before. >> >>> >>> Greetings, >>>> Ronie >>>> >>>> 2014-09-15 16:38 GMT-03:00 Craig Latta <craig(a)netjam.org>: >>>> >>>>> >>>>> >>>>> Hear hear! >>>>> >>>>> >>>>> -C >>>>> >>>>> [1] http://tinyurl.com/m66fx8y (original message) >>>>> >>>>> -- >>>>> Craig Latta >>>>> netjam.org >>>>> +31 6 2757 7177 (SMS ok) >>>>> + 1 415 287 3547 (no SMS) >>>>> >>>>> >>>> >>>> >>> >>> >>> -- >>> best, >>> Eliot >>> >> -- best, Eliot

Sept. 16, 2014

Re: [Pharo-dev] [Vm-dev] re: Parsing Pharo syntax to C/C++

by Eliot Miranda

On Tue, Sep 16, 2014 at 4:14 AM, Ben Coman <btc(a)openinworld.com> wrote: > Thierry Goubier wrote: > > Hi Ronie, > > Le 15/09/2014 23:37, Ronie Salgado a Ã©crit : > > Hello, > > I am segmenting this mail in several sections. > > --------------------------------------------------------------- > - On Lowcode and Cog > > I have been working in the last week with the Cog VM, implementing the > Lowcode instructions in Cog. > > Lowcode is currently a spec of new bytecode instructions. These > instructions can be used for: > - Implementing a C like language compiler. > - Making FFI calls > > I am implementing these instructions using a feature of the new bytecode > set for SistaV1, which is called "inline primitives". Because of this, > these new instructions can be mixed freely with the standard VM bytecode > set. This also allows the Sista adaptive optimizer to inline FFI calls. > > These instructions provides features for: > - Int32 and Int64 integer arithmetic without type checking. > > Will you provide SSE-type vector arithmetic or will you rely on the > compiler to generate those? > > - Pointers, with arithmetics. > - Memory access and memory manipulation. > - Single and double precision floating point arithmetics. > - Conversion between primitive types. > - Boxing and unboxing of primitive types. > - Unchecked comparisons. > - Native function call. Direct and indirect calls. > - The atomic operation compare and swap. > - Object pin/unpin (requires Spur). > - VM releasing and grabbing for threaded ffi. > > Lot of very significant stuff :) > > > Current I have implemented the following backends: > - A C interpreter plugin. > - A LLVM based backend. > > Do you mean a LLVM-IR to Lowcode backend compiler ? > > > Currently I am working in getting this working using the Cog code > generator. So far I am already generating code for > int32/pointer/float32/float64. I am starting to generate C functions calls > and object boxing/unboxing. > > During this work I learned a lot about Cog. Specially that Cog is > missing a better Slang generator, that allows to force better inlining and > more code reviews. There is a lot of code duplication in Cog, that can be > attributed to limitations of Slang. In my opinion, if we could use Slang > not only for building the VM we should end with a better code generator. In > addition we, need more people working in Cog. We need people that performs > code reviews and documentation of Cog. > > So there is a path there about improving Slang to C generation. > > > After these weeks, I learned that working in Cogit it is not that hard. > Our biggest problem is lack of documentation. Our second problem could be > the lack of documentation about Slang > > > --------------------------------------------------------------- > - Smalltalk -> LLVM ? > > As for having a Smalltalk -> LLVM code generator. The truth is that we > will not gain anything. LLVM is a C compiler, which is designed to optimize > things such as loops with lot of arithmetics. It is designed to optimize > large sections of code. In Smalltalk, most of our code is composed mostly > of message sends. LLVM cannot optimize a message send. > > To optimize a message send, you have to determine which is the method > that is going to respond to the message. Then you have to inline the > method. And then you can start performing the actual optimizations, such as > constant folding, common subexpressions, dead branch elimination, loop > unrolling, and a long etc. > > Because we don't have information in the actual language (e.g. static > types a la C/C++/Java/C#) that tells us what is going to be the actual > method invoked by a message send, we have the following alternatives to > determine it: > - Don't optimize anything. > - Perform a costly static global analysis of the whole program. > - Measure in runtime and hope for the best. > - Extend the language. > > Do gradual typing of performance sensitive parts of the code. > > > In other words, our best bet is in the work of ClÃ©ment in Sista. The > only problem with this bet are real time applications. > > Real time applications requires an upper bound guarantee in their > response time. In some cases, the lack of this guarantee can be just an > annoyance, as happens in video games. In some mission critical applications > the results can not be good, if this time constraint is not met. An example > of a mission critical system could the flight controls of an airplane, or > the cooling system of a nuclear reactor. > > Don't worry/don't bother with thoses: you will never use Smalltalk or a VM > :) It will never be certified by authorities, and the industry will never > accept it. > > > You are probably right for those two examples, but there are other > not-so-regulated domains where real-time is useful - e.g. industrial > automation and robotics. > +100. And Smalltalk is being used in real-time applications already, e.g. semiconductor fab machines. It used to be in all of Tektronix's oscilloscaopes. > Anyway, they are not even talking of coding anymore these days in there. > They do MDE. > > Consider that the target can be named performance critical applications, > and those are significant but have different approaches to performance: > use highly tuned libraries (Intel mkl); > perform source to source analysis to extract performance; > vectorize code (via gcc intrinsics, SSE inline, OpenCL, ICC); > use inline asm; > use totally non-obvious algorithms (bitonic sort, bit slicing); > use GPUs; > use massively parallel computing resources; > load pre-optimised code generators in your code (compilette: a > minimized Jit which generate asm at a cost of 3 inst for one generated) > > Adaptative optimisation is a very impressive technique, but it goes only > that far. When you consider that some compilation phases may require a 64 > CPU cores machine to shorten the compilation time, then you don't do it on > the fly. > > > For these application, it is not possible to rely in an adaptive > optimizer that can be triggered sometimes. In these application you have to > either: > - Extend the language to hand optimize some performance critical > sections of code. > - Use another language to optimize these critical section. > - Use another language for the whole project. > > And of course, you have to perform lot of profiling. > > Allways! > > Thierry > > > Greetings, > Ronie > > 2014-09-15 16:38 GMT-03:00 Craig Latta <craig(a)netjam.org>: > >> >> >> Hear hear! >> >> >> -C >> >> [1] http://tinyurl.com/m66fx8y (original message) >> >> -- >> Craig Latta >> netjam.org >> +31 6 2757 7177 <%2B31%20%20%206%202757%207177> (SMS ok) >> + 1 415 287 3547 <%2B%201%20415%20%20287%203547> (no SMS) >> > -- best, Eliot

Sept. 16, 2014

Re: [Pharo-dev] [Vm-dev] re: Parsing Pharo syntax to C/C++

by Eliot Miranda

Hi Thierry, On Tue, Sep 16, 2014 at 1:06 AM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > > 2014-09-16 1:46 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > >> >> Ah! But! Sista has an advantage that other adaptive optimizers don't. >> Because it optimizes from bytecode to bytecode it can be used during a >> training phase and then switched off. >> > > Great. > > Would it also be possible from the outside to make sista-like > optimisations? I'm thinking of a few possibilities such as replacing some > dictionary constant building code and a few others (i.e. a kind of [ ] once > and the #(( )) of Dolphin) which could be handled at the user level (by > tracking if it has to be recompiled if someone, say, changes the > implementation of Dictionary). > There is no "outside" in Sista. It is an image-level optimizer, so you'll be able to interact with it at the same level one interacts with the Opal compiler. Of course doing this kind of strength-reduction is possible. Real time applications requires an upper bound guarantee in their response >>> time. In some cases, the lack of this guarantee can be just an annoyance, >>> as happens in video games. In some mission critical applications the >>> results can not be good, if this time constraint is not met. An example of >>> a mission critical system could the flight controls of an airplane, or the >>> cooling system of a nuclear reactor. >>> >>> For these application, it is not possible to rely in an adaptive >>> optimizer that can be triggered sometimes. In these application you have to >>> either: >>> - Extend the language to hand optimize some performance critical >>> sections of code. >>> - Use another language to optimize these critical section. >>> - Use another language for the whole project. >>> >> >> The additional option is to "train" the optimizer by running the >> application before deploying and capturing the optimised methods. Discuss >> this with ClÃ©ment and he'll explain how straight-forward it should be. >> This still leaves the latency in the Cogit when it compiles from bytecode >> to machine code. But >> >> a) I've yet to see anybody raise JIT latency as an issue in Cog >> > > How many instructions you spend on average in Cog per generated > instruction? > I have no idea. All I know is that the code generation side of the Cogit is extremely cheap, dwarfed by the costs of relinking when code is recompiled. But the cost is vanishingly small. The costs that do show up in the Cogit are the cost of discarding, compacting and relinking code when the working set grows (e.g. Compiler recompileAll), and pause times here are ~ 1ms on my 2.2GHz MBP; thats about twice the cost of a scavenge, at about 1/20th the frequency (these times are for Spur). If you open up the system reporter you'll be able to see for yourself. And if you use the VMProfiler you can see exactly here the time goes for your favourite synthetic benchmark. See if you can figure out how to create bytecoded methods cheaper than the JIT can compile them and profile it. If you've got a tool that can count instructions let me know and I may measure. I could could bytecodes per instruction generated in the simulator ;-). > b) it would be easy to extend the VM to cause the Cogit to precompile >> specified methods. We could easily provide a "lock-down" facility that >> would prevent Cog from discarding specific machine code methods. >> > > That one is interesting. It sounds like a great benefit would be to have a > limited API to the Cog JIT for that sort of requirements. > > And of course, you have to perform lot of profiling. >>> >> >> Early and often :-). >> >> Because we can have complete control over the optimizer, and because >> Sista is byetcode-to-bytecode and can hence store its results in the image >> in the form of optimized methods, I believe that Sista is well-positioned >> for real-time since it can be used before deployment. In fact we should >> emphasise this in the papers we write on Sista. >> > > I'm not sure of that "real-time" aspect is a good idea. More real-time > than others dynamic optimisers, maybe. Note that Java Real-Time suggest > turning off JIT and switch to ITC. > But thats because in Java VMs the adaptive optimizer is in the VM where one has limited control over it. Sista is different. > > The word you're looking for there is AoT Compiler :) > In fact a better term would be an interactive compiler ;-) Regards, > > Thierry > -- best, Eliot

Sept. 16, 2014

Re: [Pharo-dev] [squeak-dev] Re: The Dilemma: Building a Futuristic GUI for Ephestos

by Eliot Miranda

On Tue, Sep 16, 2014 at 2:19 PM, Chris Muller <asqueaker(a)gmail.com> wrote: > On Tue, Sep 16, 2014 at 2:18 PM, Esteban A. Maringolo > <emaringolo(a)gmail.com> wrote: > > 2014-09-16 14:37 GMT-03:00 Sebastian Sastre < > sebastian(a)flowingconcept.com>: > > > >> Well, a while ago in the business list Iâve raised the idea that making > >> Pharo able to do native OS windows would help it to gain market space > (as in > >> the opposite of staying at the margins of it). > >> > >> So, Iâd be very positively curious about being able to use Pharo to do > >> multiplatform native apps > > > > The trend is shifting to mobile devices, iOS and Android are eating > > the whole market. So if it is about the potential market size, native > > mobile (tablets/phones/TVs) should come as the first option, before > > desktop. > > +1. Desktop apps are "dead" aren't they? I'm doubtful that native > windows would help Smalltalk's popularity, as evidenced, I guess, by > the fact VA and VW have supported them for a long time; did they take > over the world yet? > > > For development, native windows could prove very useful. > > How so? For me, one of the worst aspects of trying to develop in > VisualAge or VisualWorks *is* the multiple host windows. It makes it > virtually impossible to work in more than one image, and reinforces > the "grand cathedral" thinking about Smalltalk; e.g. you're not > supposed to want or need anything outside your one, true, image. > Dinosaur! > > I constantly work in multiple images, not only for separate projects > but for the ability to quickly and easily fork images for multicore > processing on the same project. Other times simply to try something > temporary and possibly dangerous. The memory isolation is critical > for productivity, the UI isolation for usability, and the multi-core > capability for performance. > > I think we should focus on how to move to more and smaller > intercommunicating images rather than one big image. I understand its > appeal for _deploying_ an off-the-shelf desktop app, but I'm not aware > of any other use-cases where multiple host windows would be preferable > to one host window per image. > That all makes sense from an experienced Smalltalker's POV. But for people exploring the technology the lack of native windows is usually a huge turn-off and often reason to reject the technology. The nice thing about Vassili's work is that it allows one to have *both*, without losing window state, and one can switch dynamically, and, IIRC, mix both, e.g. for development. So it isn't an exclusive choice. Re VisualWorks' support for native windows it was an essential component to VW staying in the market-place. If it hadn't supported native windows it would have died the commercial death long ago. Pre-web, one /had/ to have native windows for industry, and now with mobile native look and feel is even more important. Further, VWs huge lack in its GUI was lack of support for native widgets. We always used to tout MSWord's use of emulated widgets (apparently for performance reasons) as a defence but it didn't convince. The customer was always provided with poor emulations and a limited supply. IMO, native widgets would have made a big difference in hwo well-received VW was for GUI applications, where those using Windows could always turn to VSE. -- best, Eliot

Sept. 16, 2014

Re: [Pharo-dev] [squeak-dev] re: The Dilemma: Building a Futuristic GUI for Ephestos

by Eliot Miranda

Hi Kilon, On Tue, Sep 16, 2014 at 5:38 AM, kilon alios <kilon.alios(a)gmail.com> wrote: > The problem with relying for everything on smalltalk code and not using > existing technology is two fold > > a) You cannot compete with existing solution, they come with more manpower > , have more features, better documention, more bug fixes, more, more ...... > more > > b) One day the authors of the library decide to give up on the library > because they went off to other things and of course it falls to the > shoulders of others that are much less motivated and have other things in > their plate too with higher priority for them. The library continues to > improve but at a glacial pace. > > Its perfectly ok to try your own things and follow your own road. Everyone > loves to experiment and do things his own way and that has many positive. > But the general refusal to embrace existing technologies even problematic > ones make the job of spreading the Smalltalk appeal much harder. Makes it > harder for people to transition from other languages too. > > This smalltalk mentality is wrong. The end. > I don't understand how your comment relates to the below. Can you fill in the gaps? > > On Tue, Sep 16, 2014 at 12:11 AM, Eliot Miranda <eliot.miranda(a)gmail.com> > wrote: > >> Hi Craig, >> >> On Mon, Sep 15, 2014 at 1:40 PM, Craig Latta <craig(a)netjam.org> wrote: >> >>> >>> > I don't think anybody ever even reported trying [Ffenestri]. >>> >>> I did; it worked. And I just said so again a few messages ago. Hm. >>> >> >> OK. It opens windows. But a snippet in a workspace can do that. It >> does not constitute a replacement for the current window system though does >> it? But Vassili's work can be. We had it in production at customer sites. >> We could use it for development. It was complete, in the sense that one >> could open arbitrary system windows as native windows, switch them back to >> "virtual" windows, snapshot etc and everything would keep working. That's >> "working". With great respect to Tim and John, their work in Ffenestri is >> not the same thing, is it? By the same criteria I don't think what Qwaq >> did constituted a real system; it allowed the login WIndow to be displayed >> natively, but it didn't support development tools and it certainly didn't >> support snapshot or dynamic switching. Being critical is not being >> insulting. It's merely being objective. At least I hope I'm being >> objective and not insulting anyone. It is not my intent. >> >> -- >> best, >> Eliot >> > > -- best, Eliot

Sept. 16, 2014