- Pharo-dev - lists.pharo.org

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

by Thierry Goubier

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. 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 > <mailto:craig@netjam.org>>: > > > > Hear hear! > > > -C > > [1] http://tinyurl.com/m66fx8y (original message) > > -- > Craig Latta > netjam.org <http://netjam.org> > +31 6 2757 7177 <tel:%2B31%20%20%206%202757%207177> (SMS ok) > + 1 415 287 3547 <tel:%2B%201%20415%20%20287%203547> (no SMS) > >

Sept. 16, 2014

Re: [Pharo-dev] Strange behavior in Pharo 3.0

by Jordi Delgado

Yes, that would be ok. But the problem is not the Inspector failing, the problem is that Pharo crashes, and that should not happen. Bests, Jordi > SequenceableCollection is abstract. > > Collection methods select: #isSubclassResponsibility. > > => {Collection>>#add:. Collection>>#do:. Collection>>#remove:ifAbsent:} > > The inspector probably fails because it cannot enumerate the collection. > > But I haven't actually tried your code. > > On 15 Sep 2014, at 23:12, jdelgado(a)lsi.upc.edu wrote: > > > Hi, > > > > A student of mine has accidentaly found something interesting that may be already reported, but I do not have time to check. > > > > The thing is simple: > > > > 1) Create a class with accessors for f. > > > > SequenceableCollection subclass: #Foo > > instanceVariableNames: 'f' > > classVariableNames: '' > > category: 'Varios' > > > > 2) Foo class >> new: d > > ^self new f: (Array new: d*d) > > > > 3) Go to Workspace and inspect the following code > > > > | m | > > m := Foo new: 2 > > > > And Pharo crashes. Always crashes. I am using "Pharo 3.0 3" on OS X 10.6.8. I am pretty sure it is not a Smalltalk error since it works ok in Squeak and VisualWorks. > > > > So, is this a known issue? > > > > Bests, > > > > Jordi > > > > > >

Sept. 16, 2014

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

by Eliot Miranda

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. > 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". 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. 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

Sept. 15, 2014

Re: [Pharo-dev] How often should a uninitializedvariable warning be shown?

by Esteban A. Maringolo

2014-09-15 17:29 GMT-03:00 Tudor Girba <tudor(a)tudorgirba.com>: > You mean like this: > http://www.humane-assessment.com/blog/rethinking-compilation-notifications-… > ? I was thinking in how Dolphin does it: http://i.imgur.com/jiyY3IO.png However the Moose solution would avoid the current issues as you clearly describe them in the blog post. :) Esteban A. Maringolo

Sept. 15, 2014

Re: [Pharo-dev] [pharo-project/pharo-core] aa28e7: 40217

by Sean P. DeNigris

GitHub wrote > 13981 Nautilus should allow to compare two methods > https://pharo.fogbugz.com/f/cases/13981 Cool! Thanks, T :) ----- Cheers, Sean -- View this message in context: http://forum.world.st/pharo-project-pharo-core-aa28e7-40217-tp4777278p47782… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Sept. 15, 2014

Re: [Pharo-dev] TWM - Shortcuts - Fixed.

by Sean P. DeNigris

philippeback wrote > Shortcuts (Cmd|Alt)R, 1 > 2 3 4... > to move the windows around. > On Thu, Sep 11, 2014 at 3:13 PM, Tim Mackinnon < > tim@ > > wrote: >> > Sean, Laurent, is this working for you? Ha ha, I didn't even know about those shortcuts ;) Thanks, Phil! ----- Cheers, Sean -- View this message in context: http://forum.world.st/TWM-Shortcuts-Fixed-tp4777305p4778199.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Sept. 15, 2014

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

by Ronie Salgado

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. - 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. --------------------------------------------------------------- - 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. 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. And of course, you have to perform lot of profiling. 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) > >

Sept. 15, 2014

Re: [Pharo-dev] Strange behavior in Pharo 3.0

by Sven Van Caekenberghe

SequenceableCollection is abstract. Collection methods select: #isSubclassResponsibility. => {Collection>>#add:. Collection>>#do:. Collection>>#remove:ifAbsent:} The inspector probably fails because it cannot enumerate the collection. But I haven't actually tried your code. On 15 Sep 2014, at 23:12, jdelgado(a)lsi.upc.edu wrote: > Hi, > > A student of mine has accidentaly found something interesting that may be already reported, but I do not have time to check. > > The thing is simple: > > 1) Create a class with accessors for f. > > SequenceableCollection subclass: #Foo > instanceVariableNames: 'f' > classVariableNames: '' > category: 'Varios' > > 2) Foo class >> new: d > ^self new f: (Array new: d*d) > > 3) Go to Workspace and inspect the following code > > | m | > m := Foo new: 2 > > And Pharo crashes. Always crashes. I am using "Pharo 3.0 3" on OS X 10.6.8. I am pretty sure it is not a Smalltalk error since it works ok in Squeak and VisualWorks. > > So, is this a known issue? > > Bests, > > Jordi > >

Sept. 15, 2014

Strange behavior in Pharo 3.0

by jdelgado＠lsi.upc.edu

Hi, A student of mine has accidentaly found something interesting that may be already reported, but I do not have time to check. The thing is simple: 1) Create a class with accessors for f. SequenceableCollection subclass: #Foo Â Â Â instanceVariableNames: 'f' Â Â Â classVariableNames: '' Â Â Â category: 'Varios' 2) Foo class >> new: d Â Â Â ^self new f: (Array new: d*d) 3) Go to Workspace and inspect the following code Â Â Â Â Â Â | m | Â Â Â Â Â Â Â m := Foo new: 2 And Pharo crashes. Always crashes. I am using "Pharo 3.0 3" on OS X 10.6.8. I am pretty sure it is not a Smalltalk error since it works ok in Squeak and VisualWorks. So, is this a known issue? Bests, Jordi

Sept. 15, 2014

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

by Eliot Miranda

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

Sept. 15, 2014