Re: [Pharo-dev] [Vm-dev] re: Parsing Pharo syntax to C/C++
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@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)
Hi Ronie, On Mon, Sep 15, 2014 at 2:37 PM, Ronie Salgado <roniesalg@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@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
2014-09-16 1:46 GMT+02:00 Eliot Miranda <eliot.miranda@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).
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?
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. The word you're looking for there is AoT Compiler :) Regards, Thierry
Hi Thierry, On Tue, Sep 16, 2014 at 1:06 AM, Thierry Goubier <thierry.goubier@gmail.com> wrote:
2014-09-16 1:46 GMT+02:00 Eliot Miranda <eliot.miranda@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
Hi Eliot, Le 17/09/2014 00:12, Eliot Miranda a écrit :
Hi Thierry,
On Tue, Sep 16, 2014 at 1:06 AM, Thierry Goubier <thierry.goubier@gmail.com <mailto:thierry.goubier@gmail.com>> wrote:
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.
Ok. I'll have a look and maybe profile a bit; SmaCC has plenty of those optimisations that I had to remove in the Pharo port, and I should have a look on the cost of doing all thoses Character value: XXX and ^ Dictionary new... I also had nice optimisations in VW for my trace tool (like replacing a class lookup by a Literal which was then replaced by the singleton instance in the method bytecode) which do not have any effect in Squeak/Pharo anymore.
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.
I have colleagues in the same department working on localized, template based JiT of computational kernels and they do 3 inst of JiT for one instruction (and prove that they go faster on some matrix math code, including the JiT overhead, than anything statically optimised off-line). At the same time, a one ms pause at 2.2GHz is a hell of a long time if your target is a MicroBlaze at 50 Mhz or an embedded powerpc at 25 MHz.
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 ;-).
I used some of the intel cycle CPU counters in the past to benchmark code. I'll ask around for accessing Intel's cycle count registers. I'm sure the Bochs x86 simulator has those.
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 problem is that even a simple JiT is considered too much Jitter :) The Ocaml guys told once they had to do a special, interpreted VM for a real-time use case. The problem is not going fast, the problem is being predictable. They turn off CPU caches in some cases. Thierry
Hi Thierry, On Wed, Sep 17, 2014 at 9:57 AM, Thierry Goubier <thierry.goubier@gmail.com> wrote:
Hi Eliot,
Le 17/09/2014 00:12, Eliot Miranda a écrit :
Hi Thierry,
On Tue, Sep 16, 2014 at 1:06 AM, Thierry Goubier <thierry.goubier@gmail.com <mailto:thierry.goubier@gmail.com>> wrote:
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.
Ok. I'll have a look and maybe profile a bit; SmaCC has plenty of those optimisations that I had to remove in the Pharo port, and I should have a look on the cost of doing all thoses Character value: XXX and ^ Dictionary new...
I also had nice optimisations in VW for my trace tool (like replacing a class lookup by a Literal which was then replaced by the singleton instance in the method bytecode) which do not have any effect in Squeak/Pharo anymore.
Yes, and various dialects have a literal constructor for "compile-time expressions" (I did one for VW) that provide a manual (and hence fragile) way of doing this. As you pointed out this approach breaks when one changes the code previously compiled. Having Sista regenerate for you automatically is of course preferrable. But what do you mean "do not have any effect in Squeak/Pharo anymore"? 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.
I have colleagues in the same department working on localized, template based JiT of computational kernels and they do 3 inst of JiT for one instruction (and prove that they go faster on some matrix math code, including the JiT overhead, than anything statically optimised off-line).
Sure. My JIT optimizes and cannot be reduced to a template approach. But it is still extremely fast. As I said, scanning code to relink/compact/GC is what takes the time, not compilation itself. And the pause times here are bounded (see below). At the same time, a one ms pause at 2.2GHz is a hell of a long time if your
target is a MicroBlaze at 50 Mhz or an embedded powerpc at 25 MHz.
Sure, there are bound to be contexts in which Cog can't meet the required deadlines. But that doesn't imply it can never do real time, does it? And processor speeds are climbing. Look at Raspberry Pi, 700MHz. Not too shabby. 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 ;-).
I used some of the intel cycle CPU counters in the past to benchmark code. I'll ask around for accessing Intel's cycle count registers. I'm sure the Bochs x86 simulator has those.
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 problem is that even a simple JiT is considered too much Jitter :)
But some in some contexts. But that doesn't define the entire real time world. The Ocaml guys told once they had to do a special, interpreted VM for a
real-time use case. The problem is not going fast, the problem is being predictable. They turn off CPU caches in some cases.
Sure. But if one can show that the JIT's pause times are bounded and well spaced then there is no fundamental problem. People have been implementing real-time GCs and using GC in real time systems for over 20 years now. This is no different. But you seem absolute in denying that there is any possibility of using a JIT in real time. I think that claim is clearly false. -- best, Eliot
Hi Eliot Le 17/09/2014 19:18, Eliot Miranda a écrit :
Hi Thierry,
Yes, and various dialects have a literal constructor for "compile-time expressions" (I did one for VW) that provide a manual (and hence fragile) way of doing this. As you pointed out this approach breaks when one changes the code previously compiled. Having Sista regenerate for you automatically is of course preferrable. But what do you mean "do not have any effect in Squeak/Pharo anymore"?
It works but has no effect on performance. Well, this is an optimisation; you gain in certain circonstances, you loose in others and you turn it off.
I have colleagues in the same department working on localized, template based JiT of computational kernels and they do 3 inst of JiT for one instruction (and prove that they go faster on some matrix math code, including the JiT overhead, than anything statically optimised off-line).
Sure. My JIT optimizes and cannot be reduced to a template approach. But it is still extremely fast. As I said, scanning code to relink/compact/GC is what takes the time, not compilation itself. And the pause times here are bounded (see below).
At the same time, a one ms pause at 2.2GHz is a hell of a long time if your target is a MicroBlaze at 50 Mhz or an embedded powerpc at 25 MHz.
Sure, there are bound to be contexts in which Cog can't meet the required deadlines. But that doesn't imply it can never do real time, does it? And processor speeds are climbing. Look at Raspberry Pi, 700MHz. Not too shabby.
This is the performance of an old desktop :) And a not so old at that. ARM started as a desktop processor, after all. But, look: Python works very well on the Pi ;) Fast enough, and if not, you call a C lib.
The problem is that even a simple JiT is considered too much Jitter :)
But some in some contexts. But that doesn't define the entire real time world.
Yes.
The Ocaml guys told once they had to do a special, interpreted VM for a real-time use case. The problem is not going fast, the problem is being predictable. They turn off CPU caches in some cases.
Sure. But if one can show that the JIT's pause times are bounded and well spaced then there is no fundamental problem. People have been implementing real-time GCs and using GC in real time systems for over 20 years now. This is no different. But you seem absolute in denying that there is any possibility of using a JIT in real time. I think that claim is clearly false.
If we consider that you would have to do a WCET analysis / stack boundedness analysis to prove that the JIT pauses are deterministic, bounded and are schedulable for the target times (i.e. suitable for a significant part of what real time is about), then that claim will hold true for a while. If we change and adjust the definition of real-time and the required processing power needed, then we can consider Cog JIT sufficiently real-time as long as it is reasonably deterministic. This is my opinion on that: for what I have done in the embedded world and on FPGA so far, any gain on the determinism, performance and portability of Cog is highly significant(*); but I would really like that the language running on top of Cog, and Cog, be able to clearly let a programmer specify bounds / determinism requirements / parallelism so as to ensure that it may communicate well with real-time programs. And then it would be a really nice fit, and a huge boost to both Cog and the Embedded/RT community. (*) And those benefits would also make it really cool to use everywhere. (**) A nice target would be to be able to run Cog on a SoC with a general purpose CPU core and a FPGA. (***) and then I could reuse what I know about synthesizing logic circuits on a FPGA from smalltalk code :) Regards, Thierry
Hi Thierry, On Wed, Sep 17, 2014 at 11:46 AM, Thierry Goubier <thierry.goubier@gmail.com
wrote:
Hi Eliot
Le 17/09/2014 19:18, Eliot Miranda a écrit :
Hi Thierry,
Yes, and various dialects have a literal constructor for "compile-time expressions" (I did one for VW) that provide a manual (and hence fragile) way of doing this. As you pointed out this approach breaks when one changes the code previously compiled. Having Sista regenerate for you automatically is of course preferrable. But what do you mean "do not have any effect in Squeak/Pharo anymore"?
It works but has no effect on performance. Well, this is an optimisation; you gain in certain circonstances, you loose in others and you turn it off.
I have colleagues in the same department working on localized, template based JiT of computational kernels and they do 3 inst of JiT for one instruction (and prove that they go faster on some matrix math code, including the JiT overhead, than anything statically optimised off-line).
Sure. My JIT optimizes and cannot be reduced to a template approach. But it is still extremely fast. As I said, scanning code to relink/compact/GC is what takes the time, not compilation itself. And the pause times here are bounded (see below).
At the same time, a one ms pause at 2.2GHz is a hell of a long time if your target is a MicroBlaze at 50 Mhz or an embedded powerpc at 25 MHz.
Sure, there are bound to be contexts in which Cog can't meet the required deadlines. But that doesn't imply it can never do real time, does it? And processor speeds are climbing. Look at Raspberry Pi, 700MHz. Not too shabby.
This is the performance of an old desktop :) And a not so old at that. ARM started as a desktop processor, after all.
But, look: Python works very well on the Pi ;) Fast enough, and if not, you call a C lib.
and that's precisely what we want to avoid. IMO that;s one reason why the Python (and e.g. PHP) community has been so slow to implement good VMs. It has deferred to C code for performance-critical code _where it could_ (e.g. regular expressions) at the expense of rigid dependence on that external library. Now that companies such as Dropbox and Facebook are needing Python and PHP to exhibit good performance they are finally implementing faster VMs long after other languages. This has meant that Python libraries have not evolved as fast or as conveniently as could have happened if there was no dependency on C. Of course the situation with Squeak was/is the same, with a proliferation of plugins that would not be necessary if the VM were fast. (of course some plugins exist for good security reasons). The problem is that even a simple JiT is considered too much Jitter :)
But some in some contexts. But that doesn't define the entire real time world.
Yes.
The Ocaml guys told once they had to do a special, interpreted VM for a real-time use case. The problem is not going fast, the problem is being predictable. They turn off CPU caches in some cases.
Sure. But if one can show that the JIT's pause times are bounded and well spaced then there is no fundamental problem. People have been implementing real-time GCs and using GC in real time systems for over 20 years now. This is no different. But you seem absolute in denying that there is any possibility of using a JIT in real time. I think that claim is clearly false.
If we consider that you would have to do a WCET analysis / stack boundedness analysis to prove that the JIT pauses are deterministic, bounded and are schedulable for the target times (i.e. suitable for a significant part of what real time is about), then that claim will hold true for a while.
Right. If we change and adjust the definition of real-time and the required
processing power needed, then we can consider Cog JIT sufficiently real-time as long as it is reasonably deterministic.
This is my opinion on that: for what I have done in the embedded world and on FPGA so far, any gain on the determinism, performance and portability of Cog is highly significant(*); but I would really like that the language running on top of Cog, and Cog, be able to clearly let a programmer specify bounds / determinism requirements / parallelism so as to ensure that it may communicate well with real-time programs. And then it would be a really nice fit, and a huge boost to both Cog and the Embedded/RT community.
(*) And those benefits would also make it really cool to use everywhere.
(**) A nice target would be to be able to run Cog on a SoC with a general purpose CPU core and a FPGA.
(***) and then I could reuse what I know about synthesizing logic circuits on a FPGA from smalltalk code :)
I look forward to working with you on this! We may be a few years behind this curve in first getting Sista and the FFI and 64-bits done, but soon enough we will be ready to tackle challenges like this! Regards,
Thierry
-- best, Eliot
" and that's precisely what we want to avoid. IMO that;s one reason why the Python (and e.g. PHP) community has been so slow to implement good VMs. It has deferred to C code for performance-critical code _where it could_ (e.g. regular expressions) at the expense of rigid dependence on that external library. Now that companies such as Dropbox and Facebook are needing Python and PHP to exhibit good performance they are finally implementing faster VMs long after other languages. " nope , you are close but you got it the other way around. As a smalltalker you see it from purist way of view. For you Python is that language that got caught up on too reliance on C/C++ libraries. What you see as side effect is actually the central goal of python. The central goal of python was and still is to a great extend today to serve as scripting language for C and C++ code. This what made python so successful that a C/C++ coder could use on top of its app embedded inside its app. This why so many people use it even today. You also again wrong to assume that its a late thing that new VMs are developed for Python , PyPy which is very well known inside the python community has been around more than 12 years. Its a very performant JIT VM 2-10 faster than cpython. Why cpython has not ported to it ? because of not so good support for C/C++ , zero support for cpython libraries and of course because as they say it would complicate the development of cpython quite a lot . Its that situation that only a couple of people can decypher the magic of the VM and the rest of developer only hope for the best. And PyPy is not the only JIT VM for python , there is also Jython that runs of JVM and ironpython that runs on .NET and Mono. What those 3 have in common ?that are used by a tiny crowd compared to people using cpython. The truth is pure python libraries are a rarity . Why you think the most popular , by far, implementation of python is called cpython ? I will give you a hint, 50% of its source code is written in C. No thats not just the VM its libraries and cpython comes with a lot of libraries included. Frankly I dont believe that any VM ever however fast will ever beat smooth integration of C/C++ code unless you have a huge company to back you up with an insane amount of libraries. Java had Sun , .NET has still Microsoft. For people that speed is a serious matter even if a VM is a mere 30% slower than optimised C code, they will take the C code any day.
On Thu, Sep 18, 2014 at 2:25 PM, kilon alios <kilon.alios@gmail.com> wrote:
" and that's precisely what we want to avoid. IMO that;s one reason why the Python (and e.g. PHP) community has been so slow to implement good VMs. It has deferred to C code for performance-critical code _where it could_ (e.g. regular expressions) at the expense of rigid dependence on that external library. Now that companies such as Dropbox and Facebook are needing Python and PHP to exhibit good performance they are finally implementing faster VMs long after other languages. "
nope , you are close but you got it the other way around. As a smalltalker you see it from purist way of view. For you Python is that language that got caught up on too reliance on C/C++ libraries.
Nope. As a C/C++ advocate you are in denial about how unproductive your tools are and about the fact that it takes industrial scale organization to achieve even the most trivial of achievements.
What you see as side effect is actually the central goal of python. The central goal of python was and still is to a great extend today to serve as scripting language for C and C++ code. This what made python so successful that a C/C++ coder could use on top of its app embedded inside its app. This why so many people use it even today.
Nope. What you claim as a central goal of Python is merely a supine acceptance of massive failure to innovate. Bourne shell has been doing this for years and years. It's not a new thing. And GVR seems to have conceived it as a better shell. Well, that's not innovative; useful, yes, innovative no. But seriously, look at something innovative written in Python such as BitTorrent et al. How much of that is system calls, C or Python? t is basically Python an socket calls. C doesn't play a significant part in the architecture. The important thing is a dynamic OOPL being able to express a novel architecture. I'd wager that torrent clients are amongst the most popular Python apps. You also again wrong to assume that its a late thing that new VMs are
developed for Python , PyPy which is very well known inside the python community has been around more than 12 years. Its a very performant JIT VM 2-10 faster than cpython. Why cpython has not ported to it ? because of not so good support for C/C++ , zero support for cpython libraries and of course because as they say it would complicate the development of cpython quite a lot . Its that situation that only a couple of people can decypher the magic of the VM and the rest of developer only hope for the best.
By recently I mean within the last 10 years or so. The HotSpot Smalltalk VM is already 19 years old, and Self 3 over 20. PS, the first truly fast VM for a dynamic object oriented language is 32 years old. Python could have started an implementation effort at a faster VM much sooner and it would have shaped Python, IMO positively. There are reasons Java has been much more popular until recently, performance being a very important one. (There's reasons it's no longer popular, IMO the most important being it being statically typed). Further if you read what the Dropbox guys (and many others) are saying about Pyston vs PyPy is that tracing JITs fail to deliver good performance except in synthetic benchmarks where they shine, and hence Pyston is a method-at-a-time JIT. So PyPy is a so-so VM, hardly in the same league as HotSpot or V8 (and Pyston will have a ways to go before i can compete on that level), just as Cog is a so-so VM and needs Sista to reach or exceed static language performance for non-symbolic codes. And the lack of good support for C/C++ in PyPy is not a technical limitation. It is an organizational one. There's nothing intrinsic in a fast VM that makes it more difficult to interface to C. An execution engine is an execution engine, and it is the object representation that determines how easy it is to interface to other languages. And PyPy is not the only JIT VM for python , there is also Jython that runs
of JVM and ironpython that runs on .NET and Mono. What those 3 have in common ?that are used by a tiny crowd compared to people using cpython.
That could be because foreign VMs don't provide the support that users of a VM designed for a language expect, could it not? IMO this is a really important issue, especially for Smalltalk where we expect instance migration, contexts, etc, all of which one has to say goodbye to when hosted on a foreign VM. And this is a major reason for putting effort into one's own infrastructure. The truth is pure python libraries are a rarity . Why you think the most
popular , by far, implementation of python is called cpython ? I will give you a hint, 50% of its source code is written in C. No thats not just the VM its libraries and cpython comes with a lot of libraries included.
And that pure python libraries are a rarity is of course a result of the fact that Python has run to C whenever it needed performance. Hence when one comes to measure the speedup of a fast python against cpython it is difficult to see speedups because lots of benchmarks (e.g. many of the computer language shootout benchmarks) are spending much of their time running C code. Hint, if an app spends 50% of its time in C then it can never be more than twice as fast on a faster execution engine. Frankly I dont believe that any VM ever however fast will ever beat smooth
integration of C/C++ code unless you have a huge company to back you up with an insane amount of libraries. Java had Sun , .NET has still Microsoft.
Seriously, what do you mean "beat"? The world is infinitely varied. COBOL is still important and yet you seem to portray the entire programming field as reducing to some kind of horse race. What's the content here? Also what's the intent behind pissing contests? Seems rather teenage. Whereas being positive, doing good engineering and innovating can invent the future. Seem much more fun than doling out endless negativity.
For people that speed is a serious matter even if a VM is a mere 30% slower than optimised C code, they will take the C code any day.
You contradicted yourself in claiming that Pythoners dont yse faster VMs. Java has good C integration and provides much better performance than PyPy so if you were correct Pythoners would be using Jython + C but you claim they're not. (Personally I'm dubious about blanket claims about what people do and don't do; my experience since I've been involved with commercial Smalltalk deployment is that the world is incredibly varied and different people with different requirements do different things, often for good reason). Speed is pretty meaningless unless you qualify it. In applications where performance can really matter theres always assembler (e.g. video decoders) or DSPs or... and often optimized C just doesn't hack it. But so what? There is another context where using Scheme to automatically generate Java VMs is critical to performance. And one can cite example after example where high performance does /not/ equal C/C++ plus an insane number of libraries. Computing is a broad church. There are plenty of contexts where time to market is the dominant factor and that can force one to reject performant and difficult to configure solutions (such as Jython, or Smalltalk + C), but equally there are contexts where time to market is the dominant factor and that can "force" one to use pure dynamic OOPLs because the world changes too fast to do anything else (e.g. finance). Anyway, keep those "nope"s coming. I love them. Time to patent your new way of proving a negative I think. -- best, Eliot
"Nope. As a C/C++ advocate you are in denial about how unproductive your tools are and about the fact that it takes industrial scale organization to achieve even the most trivial of achievements." C/C++ , I don't code in those languages. Currently I use pharo, before that I was coding in python and still do, before that I was a Delphi developer. I hate C++ with a vengeance.I am now learning C for my first time. I dont see the industry having any problem achieving what it wants with C/C++ because if it did then the software industry would be overrun by smalltalk , which we all know how superior better it is . Actually you will be lucky if a coder was even aware what smalltalk is. I did not know what smalltalk is like a few years ago. I never even saw it mentioned in coding forums or in chat channels until one day someone mentioned squeak to me in #emacs. "By recently I mean within the last 10 years or so. The HotSpot Smalltalk VM is already 19 years old, and Self 3 over 20. PS, the first truly fast VM for a dynamic object oriented language is 32 years old. Python could have started an implementation effort at a faster VM much sooner and it would have shaped Python, IMO positively. There are reasons Java has been much more popular until recently, performance being a very important one. (There's reasons it's no longer popular, IMO the most important being it being statically typed). Further if you read what the Dropbox guys (and many others) are saying about Pyston vs PyPy is that tracing JITs fail to deliver good performance except in synthetic benchmarks where they shine, and hence Pyston is a method-at-a-time JIT. So PyPy is a so-so VM, hardly in the same league as HotSpot or V8 (and Pyston will have a ways to go before i can compete on that level), just as Cog is a so-so VM and needs Sista to reach or exceed static language performance for non-symbolic codes. And the lack of good support for C/C++ in PyPy is not a technical limitation. It is an organizational one. There's nothing intrinsic in a fast VM that makes it more difficult to interface to C. An execution engine is an execution engine, and it is the object representation that determines how easy it is to interface to other languages." Bottom line is clear, do optimised VMs are likely to really interest people, from the looks of it does not seem so. I don't care whether PyPy has technical limitations what matters is that I cannot use my favorite cpython libraries with it. " And that pure python libraries are a rarity is of course a result of the fact that Python has run to C whenever it needed performance. Hence when one comes to measure the speedup of a fast python against cpython it is difficult to see speedups because lots of benchmarks (e.g. many of the computer language shootout benchmarks) are spending much of their time running C code. Hint, if an app spends 50% of its time in C then it can never be more than twice as fast on a faster execution engine." no python needs to run C libraries because it wants to run C libraries , because they are so many out there and many of them are so damn good at what they are doing. Actually nowadays it becomes increasingly difficult not to find python wrappers for a C/C++ library. It comes down to C/C++ coders needing a simpler language that can easily port their code a lot more than a python coder would need C for speed. "You contradicted yourself in claiming that Pythoners dont yse faster VMs. Java has good C integration and provides much better performance than PyPy so if you were correct Pythoners would be using Jython + C but you claim they're not. (Personally I'm dubious about blanket claims about what people do and don't do; my experience since I've been involved with commercial Smalltalk deployment is that the world is incredibly varied and different people with different requirements do different things, often for good reason)." First of all Java has had crappy C integration like for ages , people were complaining about it for a long long time. Second I dont see how I contradict myself , I claimed that python people don't care so much about how fast a VM is when they can fall back to C and you bring up Java speed. What am I missing her ? Why not use Jython ? simple same reason why people dont use PyPy lack of support for cpython libraries, which by the way are based partly if not largely in C and if Java had so cool support of C then jython would have supported cpython libraries out of the box , which it does not. We can run this in circles but in the end I find it highly suspicious how some smalltalkers find smalltalk so awesome in every level yet they fail to justify why its so unpopular. And just for the record , so people dont think I talk out of random, this is Guido , the creator of python , says about PyPy and why is not integrated to cpython and the main goal of cpython --> http://youtu.be/EBRMq2Ioxsc?t=12m29s And yes python does not care about innovation at all, and this is one of the reason of its immense success as a language. Actually if you take into consideration that python is not tied to platform like javascript , or is not backed up by a huge company like C++ , Java , C# I dont think its an exaggeration at all that to say that it has been by far the most successful language at least in terms of people actually using it. Personally I find python as well completely unoriginal , not that well implemented, very slow and unimaginative. Still its the language, my number one choice, I would recommend to any one in terms of practicality alone. I don't want to debate this to death, I stated my opinion and the my view on things, you can call me advocate , fanboy or plain blind. Thats your right. I think however its good to hear the other side of story , the other opinion to make the discussion a bit more spherical. Saying that I love smalltalk and especially pharo and I hope it keeps being practical enough for me to keep using it.
2014-09-16 1:46 GMT+02:00 Eliot Miranda <eliot.miranda@gmail.com>:
Hi Ronie,
On Mon, Sep 15, 2014 at 2:37 PM, Ronie Salgado <roniesalg@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-mem...> 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@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
Is there any other documentation for Slang apart from the link in squeak wiki ? Hows Slang deals with manual memory management ? On Tue, Sep 16, 2014 at 12:48 PM, Clément Bera <bera.clement@gmail.com> wrote:
2014-09-16 1:46 GMT+02:00 Eliot Miranda <eliot.miranda@gmail.com>:
Hi Ronie,
On Mon, Sep 15, 2014 at 2:37 PM, Ronie Salgado <roniesalg@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-mem...> 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@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
Hi Kilon, On Tue, Sep 16, 2014 at 5:07 AM, kilon alios <kilon.alios@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-re...> 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@gmail.com> wrote:
2014-09-16 1:46 GMT+02:00 Eliot Miranda <eliot.miranda@gmail.com>:
Hi Ronie,
On Mon, Sep 15, 2014 at 2:37 PM, Ronie Salgado <roniesalg@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-mem...> 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@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
What would be valuable is a reading list / path to VM enlightenment. Bluebook is useful Then a tour of the Object Engine by Tim Then plugin articles + Slang The bytecode set Primitive... Context to stack mapping Blocks Non local returns Display/Sensor/event look/timer implementation (like in the porting document). and only then one would move to more advanced topics. I saw that Clement had a set of VM related books on his desk at INRIA, maybe posting the list would be great! All the best, Phil On Tue, Sep 16, 2014 at 11:48 AM, Clément Bera <bera.clement@gmail.com> wrote:
2014-09-16 1:46 GMT+02:00 Eliot Miranda <eliot.miranda@gmail.com>:
Hi Ronie,
On Mon, Sep 15, 2014 at 2:37 PM, Ronie Salgado <roniesalg@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-mem...> 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@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
2014-09-16 14:55 GMT+02:00 phil@highoctane.be <phil@highoctane.be>:
What would be valuable is a reading list / path to VM enlightenment.
Bluebook is useful Then a tour of the Object Engine by Tim Then plugin articles + Slang The bytecode set Primitive... Context to stack mapping Blocks Non local returns Display/Sensor/event look/timer implementation (like in the porting document). and only then one would move to more advanced topics.
I saw that Clement had a set of VM related books on his desk at INRIA, maybe posting the list would be great!
The book that explains the best how to implement a high performance VM for
Smalltalk and why is Urs Holzle phd <http://www.cs.ucsb.edu/~urs/oocsb/self/papers/urs-thesis.html>. Other relevant books on my office focus on specific topics, such as Advanced Compiler Design and Implementation by Steven Muchnick for optimizing compilers or The garbage collection handbook by Richard Jones, Antony Hosking and Eliot Moss. All the best,
Phil
On Tue, Sep 16, 2014 at 11:48 AM, Clément Bera <bera.clement@gmail.com> wrote:
2014-09-16 1:46 GMT+02:00 Eliot Miranda <eliot.miranda@gmail.com>:
Hi Ronie,
On Mon, Sep 15, 2014 at 2:37 PM, Ronie Salgado <roniesalg@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-mem...> 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@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
On 09/16/2014 06:34 AM, Clément Bera wrote:
The book that explains the best how to implement a high performance VM for Smalltalk and why is Urs Holzle phd <http://www.cs.ucsb.edu/~urs/oocsb/self/papers/urs-thesis.html>.
Agreed. This is good (almost required) reading for anyone who wants to understand how to implement dynamic languages in a way that is not slow, and to understand why performance of dynamic languages does not need to be much slower than that of statically-typed languages. After reading this paper, it's also good to think about the fact that it describes work that was done over 20 years ago, and that hardware has changed a great deal in the interim, and think hard about what improvements might be made today over the techniques that Urs and the Self team came up with back then. Regards, -Martin
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@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)
2014-09-16 13:14 GMT+02:00 Ben Coman <btc@openinworld.com>:
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.
Real-time is usefull there, yes. But Smalltalk and Cog will never get there. Except as a DSL / code generator tool (which means a MDE approach, more or less). (And code generation is where Pharo to C or LLVM-IR gets us interested) Dynamic optimisations, lack of static typing: they will laugh you out in any of those fields. Even if their developpers use Python behind their back. Thierry
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-py... and the list goes on.... and on..... and on.... On Tue, Sep 16, 2014 at 2:48 PM, Thierry Goubier <thierry.goubier@gmail.com> wrote:
2014-09-16 13:14 GMT+02:00 Ben Coman <btc@openinworld.com>:
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.
Real-time is usefull there, yes. But Smalltalk and Cog will never get there. Except as a DSL / code generator tool (which means a MDE approach, more or less).
(And code generation is where Pharo to C or LLVM-IR gets us interested)
Dynamic optimisations, lack of static typing: they will laugh you out in any of those fields.
Even if their developpers use Python behind their back.
Thierry
2014-09-16 14:19 GMT+02:00 kilon alios <kilon.alios@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-py...
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. Thierry
On Tue, Sep 16, 2014 at 2:33 PM, Thierry Goubier <thierry.goubier@gmail.com> wrote:
2014-09-16 14:19 GMT+02:00 kilon alios <kilon.alios@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-py...
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.
You are old fashion Thierry, now dynamic languages are used for embedded stuff :-) - Ruby to control robots: http://artoo.io/ - Javascript for drone : http://nodebots.io/ - Javascript for embedded boards: https://tessel.io/ -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/
2014-09-16 14:55 GMT+02:00 Serge Stinckwich <serge.stinckwich@gmail.com>:
On Tue, Sep 16, 2014 at 2:33 PM, Thierry Goubier <thierry.goubier@gmail.com> wrote:
2014-09-16 14:19 GMT+02:00 kilon alios <kilon.alios@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-py...
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.
You are old fashion Thierry, now dynamic languages are used for embedded stuff :-) - Ruby to control robots: http://artoo.io/ - Javascript for drone : http://nodebots.io/ - Javascript for embedded boards: https://tessel.io/
Ah, Serge, if those could be relevant ;) Only dreamers believe one can do good software with dynamic, creative approaches. Of course they may succeed at one point, because there is no proof we need to put a straightjacket to a developper to get safe, fast and good quality code. Nowadays, you can't even do programming language research without doing a type system, and proofs and .... FP and static type systems have won, and there is nothing left of the creative spirit in programming. Thierry
I don't know maybe you are correct I have not coded for embeded platforms so I dont offer opinion about things I dont know. But I do know is that once the creator of python himself claimed that if you use python for performance then you are using the wrong language. But hey what does he know , he only created python . People having proving him so wrong for years now with many libraries targeting top performance. What makes those people special is what makes all innovators special, their unwillingness to compromise, to accept defeat and stop asking "What if?". So I am sorry I cant digest with "you are not supposed to have fun with...." I am sure you are correct and you speak from experience but I "just dont have the stomach to digest it" as we say here in Greece PS: What is RT ? On Tue, Sep 16, 2014 at 3:33 PM, Thierry Goubier <thierry.goubier@gmail.com> wrote:
2014-09-16 14:19 GMT+02:00 kilon alios <kilon.alios@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-py...
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.
Thierry
2014-09-16 14:59 GMT+02:00 kilon alios <kilon.alios@gmail.com>:
I don't know maybe you are correct I have not coded for embeded platforms so I dont offer opinion about things I dont know. But I do know is that once the creator of python himself claimed that if you use python for performance then you are using the wrong language. But hey what does he know , he only created python . People having proving him so wrong for years now with many libraries targeting top performance. What makes those people special is what makes all innovators special, their unwillingness to compromise, to accept defeat and stop asking "What if?".
There is a body of work on making Python fast, because Python is so cool that people keep using it against all odds :) I'm working on making R fast, for the same reason: non programmers using it to do big data. Think of using Python + numPy on a 100 000 CPUs supercomputer :) Fun ! Well, of course, you have scores of project trying to show that writing the same code in C++ (with the right DSL or framework) would be a hell of a lot faster and safer because of static types. Safer because non programmers wouldn't be writing code anymore, yes!
So I am sorry I cant digest with "you are not supposed to have fun with...." I am sure you are correct and you speak from experience but I "just dont have the stomach to digest it" as we say here in Greece
Sorry, but this is real. Tales of the industry... It's hard to stomach when you talk Research directions with those guys :(
PS: What is RT ?
Real-Time. Thierry
so its a people problem more than a technology problem from what you saying . As it is in most cases. I don't care if its python but 100k cpus sounds a lot of fun. Huge potential :) "Safer because non programmers wouldn't be writing code anymore, yes!" if you write programs you are a programmer , no ? Can you ever be safe in this life ? I think not . I don't believe in holy grail and static types look like a holy grail to me, similar to functional coding style. I can understand the benefit cant understand all this hype. But then I am not too attached to dynamic typing as well. I just dont want complexity imposed on me that I dont need, I want to be the boss of my code and no stupid language or language designer tell me how to code as if he know the needs of millions different coders. There I said it :D On Tue, Sep 16, 2014 at 4:23 PM, Thierry Goubier <thierry.goubier@gmail.com> wrote:
2014-09-16 14:59 GMT+02:00 kilon alios <kilon.alios@gmail.com>:
I don't know maybe you are correct I have not coded for embeded platforms so I dont offer opinion about things I dont know. But I do know is that once the creator of python himself claimed that if you use python for performance then you are using the wrong language. But hey what does he know , he only created python . People having proving him so wrong for years now with many libraries targeting top performance. What makes those people special is what makes all innovators special, their unwillingness to compromise, to accept defeat and stop asking "What if?".
There is a body of work on making Python fast, because Python is so cool that people keep using it against all odds :) I'm working on making R fast, for the same reason: non programmers using it to do big data.
Think of using Python + numPy on a 100 000 CPUs supercomputer :) Fun !
Well, of course, you have scores of project trying to show that writing the same code in C++ (with the right DSL or framework) would be a hell of a lot faster and safer because of static types.
Safer because non programmers wouldn't be writing code anymore, yes!
So I am sorry I cant digest with "you are not supposed to have fun with...." I am sure you are correct and you speak from experience but I "just dont have the stomach to digest it" as we say here in Greece
Sorry, but this is real. Tales of the industry... It's hard to stomach when you talk Research directions with those guys :(
PS: What is RT ?
Real-Time.
Thierry
On Tue, Sep 16, 2014 at 5:33 AM, Thierry Goubier <thierry.goubier@gmail.com> wrote:
2014-09-16 14:19 GMT+02:00 kilon alios <kilon.alios@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-py...
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
Le 17/09/2014 00:27, Eliot Miranda a écrit :
On Tue, Sep 16, 2014 at 5:33 AM, Thierry Goubier <thierry.goubier@gmail.com <mailto:thierry.goubier@gmail.com>> wrote:
2014-09-16 14:19 GMT+02:00 kilon alios <kilon.alios@gmail.com <mailto:kilon.alios@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-py...
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.
Been there, done that. You do it once, after you dump the people in that field and you do more valuable stuff :) I really needed that Smalltalk therapy ;) Thierry
On Tue, Sep 16, 2014 at 1:48 PM, Thierry Goubier <thierry.goubier@gmail.com> wrote:
2014-09-16 13:14 GMT+02:00 Ben Coman <btc@openinworld.com>:
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.
Real-time is usefull there, yes. But Smalltalk and Cog will never get there. Except as a DSL / code generator tool (which means a MDE approach, more or less).
(And code generation is where Pharo to C or LLVM-IR gets us interested)
Dynamic optimisations, lack of static typing: they will laugh you out in any of those fields.
Even if their developpers use Python behind their back.
http://www.altreonic.com/ has OpenComRTOSwhich looks the kind of thing we would like to target then. I know the creator of OpenCOMRTOS, in fact, he lives close to my place. http://www.altreonic.com/sites/default/files/Altreonic%20OpenComRTOS2013.pdf They happen to have a "VM" http://www.altreonic.com/sites/default/files/Altreonic%20Safe%20Virtual%20Ma... "The ultra small target independent Virtual Machine" Applications: ï· Remote diagnostics. ï· Fail safe and fault tolerant control. ï· Processor independent programming. Thanks to the use of OpenComRTOS, SafeVM tasks can operate system wide across all nodes in the network. The user can also put several SafeVM tasks on the same node. The natively running OpenComRTOS itself acts as a virtual machine for the SVM tasks, isolating them from the underlying hardware details while providing full access. Safe Virtual Machine for C So, looks like we aren't in such a black and white situation. Phil
Thierry
On Tue, Sep 16, 2014 at 4:14 AM, Ben Coman <btc@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@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
Le 17/09/2014 00:13, Eliot Miranda a écrit :
+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.
And I remember a HP network analyser whose GUI was written with Digitalk/V. But this is work where you go dual: you put your real-time control loop on a core, making sure it will never be interrupted, and you let the soft stuff (GUI and all) outside of the RT loop. There I can see Cog and Smalltalk, not in the inner loop. Thierry
participants (9)
-
Ben Coman -
Clément Bera -
Eliot Miranda -
kilon alios -
Martin McClure -
phil＠highoctane.be -
Ronie Salgado -
Serge Stinckwich -
Thierry Goubier