Why would people who write compilers have to write their own register allocators? I'd target PIR and use symbolic registers that IMCC will analyze and allocate automatically anyway.
That seems to be what the second half of your comment says, but I really don't understand what you mean here. Doesn't any IR have to emit some sort of unique symbols?
The issue is that register allocation is one of the more complex but also more time consuming phases of a compiler (examples of degenerate cases of both can be found in parrot right now, check the threads on degenerate cases for the reg allocator). With the current parrot design a language like perl would create PIR code at runtime and imcc would spend time in the register allocator to map to parrot registers. Later the jit will need to spend again time to map to HW registers (I think the current parrot jit does this only in a very limited way, ie it doesn't actually map parrot regs to hw regs, but only temp values). So again you spend lots of run time doing again register allocation. Of course you can avoid the last step and just don't do much optimization, but the code will run slowly. The end result is that using a register-based VM didn't help improve performance but it actually hurts it (a register-based design can make for a faster interpreter, but if you want speed you use a jit, not an interpreter). It would be more sensible if parrot didn't contraint the number of registers, that way at least you don't need to pay for the register allocator in imcc: the register numbers would be simply what most compiler guys call virtual registers, leaving to the jit the duty of allocating them to hw registers as it sees fit. The register-based design has also an impact on bytecode size: unless they are optimized they are going to take a significant amount of memory and disk space.
Parrot uses typed registers, yes, but they are not mapped to HW registers (and with the current design that would be very hard to do in an efficient way while preserving the current semantics). The main issue is whether using a register-based bytecode is any better at helping with executing the code fast once you use a jit. And the answer there is that it doesn't help at all. Except Itanium, all the other arch have fewer registers than parrot, so you can't map them all. If you map a few fixed registers you may miss performance opportunities, because the bytecode could use other registers for the time critical code (note also that the actual number of mappable registers depends on the plaform so you could have ok performance on ppc and terrible performance on x86, exposing HW details to people producing the bytecode). The only sane option left is to do whole-method analysis and map only the hot registers, surprisingly the same thing jits for stack-based bytecode do. The end result is that having a register-based vm doesn't help at all for this issue.
Well, "it will run" is more whishful thinking than anything. Having actually implemented a.net runtime (mono) and knowing a bit about the parrot internals, I can say you that parrot won't run any significant.net program anytime soon and even if it will it will be very slow. Significant changes would be needed in the design to make it work and I don't expect that to happen any time soon.
Note that writing a big chunk of the perl interpreter in java or C# is not necessarily a bad thing:-) One of the reasons parrot was born was to make for a cleaner runtime vs the current perl5 internals. Whether parrot will succeed in this is still waiting on the jury (or better on parrot reaching at least some sort of beta quality release). People may want to read the slides at http://www.research.ibm.com/vee04/Hylton.pdf by a Python developer. He writes:
It's not much fun to implement Python in C
In relation to the time and lines of code it took to implement CPython and IronPython.
Implementing perl in C# or Java would also have the advantage of defining some sort of specification for Perl the language which is currently defined more or less as what the current perl C implementation does (even if the perl test suite work is also helping define a more formal specification).
I doubt parrot will be implemented in HW any time soon:-) A virtual machine that is register-based makes for a faster implementation of an interpreter vs a stack-based VM. Of course, if the issue is performance using an interpreter is not ideal:-) Once you jit the code it doesn't matter much if the bytecode was register or stack based (except that the register based code requires you to make harder and slower analyses of the code if you need to check for type safety, for example if you care about security). Of course a VM that is register-based should not limit the number of registers: that is a limitation of the HW that doesn't need to be imposed on a sw implementation.
What matters instead is that using a register-based VM actually makes for a slower implementation when speed matters. Register allocation is one of the phases of a compiler that takes more time: perl running on parrot would need to perform it two times, first when the perl code is translated to the parrot internal register-based bytecode and a second time when parrot jits the code to native code. But that is not all: registers in a VM are a global resource and as such, the optimizations that can be applied to the code are limited if the semantics are respected. On the other hand, stack slots are local to the call frame so the jit can make more assumptions about their use. Also, deciding on a call convention becomes a hard task, because the decisions on it can't be changed once finalized (otherwise all the bytecode breaks) . The parrot internal call convention has been changed at least two or three times already and there are proposals to change it again, because call performance is very slow. A stack-based VM doen't have these issues, because changing the call convention doesn't break the existing bytecode and it can be made to map to the HW registers, which parrot can't do with the current design.
IronPython is a demonstration that dynamic languages can run pretty well on mono: the fact that mono/the CLR implement a VM for a statically typed langauge (IL) would make mono not adequate has the same relevance as saying that C is not adequate to write a virtual machine and runtime for a dynamic language because C itself is not 'dynamic'.
As for parrot running some day on top of the JVM or.net: it's possible, but has a number of issues the first of which is that until the parrot internal design has been finalized no such effort can start:-) The other major issue is that currently any language that runs on top of parrot basically needs to be implemented in C, mostly because parrot doesn't provide a nice and powerful implementation language in the same way that, say, C# could be used in mono. This basically means that all the code needed to make a language run on top of parrot is very specific to the parrot C internals and hence parrot will not be usefully ported to any othger runtime that isn't the current C implementation.
There is hope, though, that eventually the perl6 specification will emerge and that it will be possible to implement it efficiently in mono.
Just use the precompiled packages and apt-get or redcarpet. Also note that he was referring to licensing issues: mono is free software so it can be legally included in distributions. Java has some distribution restrictions.
The MS license prohibits publishing benchmark data, but you can check for yourself, for example, the performance of Reflection.Emit (mcs, for example). Last time I checked we did better also in a few cli-grande benchmarks and, of course, we could write benchmarks that highlight where we're faster. Of course we have still work to do: anyone following mono development will find that the cvs version is already much faster than 1.0 and we have a roadmap page on the web site with details on the improvements we're currently working on.
Mono, Java or C++
I'll try to address some of the issues Havoc presented.
Of course, I'm a Mono developer, so I'm biased, but hopefully people
can see my arguments are more on the technical side than advocacy.
No rewrites please: this is a very important point: we can't
just throw away the current code: we need incremental changes to not
disrupt stability and compatibility. I'll just note that using
Mono (and C#), interoperability with existing C code is much easier
than with Java because of P/Invoke.
Calling managed code from C/C++: Havoc says it's hard, but Mono
provides an easy to use interface to do that. Mono is designed to be
embedded in existing applications, not just as a runtime for standalone
completely managed programs. Also, it would be easy to create
a shared library and header files to access managed methods seamlessly:
they can be automatically generated thanks to the use of Reflection
and the Mono embedding API.
I'm not sure a "simple native component system bridge" would solve
the issues, mostly because simple systems are always found later to
be incomplete, they get changed and become big, but with all the design
warts needed to make a simple design work for not-so-simple constraints.
A minimal Mono system is currently about 2 MB on disk, but no effort yet has
been put into reducing it (and I think it's entirely possible, we have been
busy implementing features and leaving aside space optimizations). Of course,
since the default build of the core assembly has lots of features, much of
the reduction in size could be achieved by trimming features that other
systems don't have:-). Even without trimming, most people will concour that
2 megabytes of disk space for a shared component is small enough in a
desktop setting (and applications compiled to IL code are usually much
smaller than comparable C apps anyway).
Community should decide: of course, I agree. Anything that is pushed
down our throats by somebody else is not going to work for the free software
and open source communities. The solution will need to be choosen because
it actually solves issues the developers and the users see. Java had several
years to try to attract developers from our community and it had some success
in some niche areas (not for desktop applications, though). Mono has just
started, but from the comments of the developers that actually used it to
write new applications or port existing ones from C, it looks like we are
on a good adoption path (even though we didn't release a 1.0 version yet,
we are still working on debugging support and documentation is sparse).
Havoc fears the adoption of Mono or Java for the desktop would alienate people
and cause forks. I don't think that will happen with Mono, because Gnome will continue
to have a diversity of developers who'll prefer using the C libraries directly:
Mono allows to keep and interoperate with existing code very easily and we want
the migration to happen incrementally, so at first only end-user applications
would be written in managed code, while the foundation would still be in C
(at least, enough of the foundation to have people happyly writing their own
apps in c or with the existing bindings). At that point, when a managed execution
environment has proven itself to both developers and users (hopefully) we could
start discussing about using it for the foundation, too, if that makes sense.
I think Mono is positioned better here to allow this incremental shift of
both development and espectations towards a managed runtime.
Problems with a.Net clone: Havoc claims that MS controls the platform
because, even if the core is unencumbered, some assemblies are tied to MS
technologies and there is non standards body or community momentum to build
alternative solutions for a complete platform. Well, considering that until
a couple of months ago there were 5 people developing mono, we have achieved a lot,
not only in the implementation of the runtime, but also, thanks to the large
commun
Note that we still need to do some performance and memory usage optimizations for Gtk# apps: we have just focused on implementing until now. I expect the memory usage to drop significantly in the next few months as we approach a formal release.
We are not hostile at all to DotGNU. We think we have a better implementation so we keep going forward with that. I don't think we're even competing since DotGNU seems to have different targets than us: for example the reason we built a JIT from the start is because we want Mono to be an efficient developer platform that enables people to move away from unsafe and difficult to use langauges: this of course would be not compatible with an interpreter design which is slow. By all means continue with the DotGNU implementation, improve it and try to build on its strengths, but don't just call us hostile only because we have a different implementation from yours.
You should probably check out the new DynamicMethod class: it allows creating methods at runtime that are not bound to a dynamic assembly and whose code can be garbage collected once it's no longer in use. Mono implements it already.
Crunched glass is an essential component when producing glass: it dramatically reduces the energy needed to melt sand and form new glass (it melts at a lower temperatures and provides for better transfer of heat). So, not only recycling glass is good to reduce waste, but it is essential in the modern industrial glass-making processes. I worked at a glass factory, but you could have at least used google to learn how the process works.
I don't see how being able to execute java bytecode makes a runtime less likely subject to possible patent issues. If that would be the case, Mono would be in a better position anyway, since it actually runs complex java programs (like Eclipse; it also passes more than 99.5% of the mauve java tests) unlike other systems that support it 'in principle'.
What you seem to miss, though, is that patents on virtual machines technologies are as likely to apply to Mono as to Parrot, kaffe or other such efforts. Picking on Mono is short-sighted: the real issue is software patents and people should try to get the USPTO on track instead of whining on slashdot.
Slashdot Mirror
The issue is that register allocation is one of the more complex but also more time consuming phases of a compiler (examples of degenerate cases of both can be found in parrot right now, check the threads on degenerate cases for the reg allocator). With the current parrot design a language like perl would create PIR code at runtime and imcc would spend time in the register allocator to map to parrot registers. Later the jit will need to spend again time to map to HW registers (I think the current parrot jit does this only in a very limited way, ie it doesn't actually map parrot regs to hw regs, but only temp values). So again you spend lots of run time doing again register allocation.
Of course you can avoid the last step and just don't do much optimization, but the code will run slowly. The end result is that using a register-based VM didn't help improve performance but it actually hurts it (a register-based design can make for a faster interpreter, but if you want speed you use a jit, not an interpreter).
It would be more sensible if parrot didn't contraint the number of registers, that way at least you don't need to pay for the register allocator in imcc: the register numbers would be simply what most compiler guys call virtual registers, leaving to the jit the duty of allocating them to hw registers as it sees fit.
The register-based design has also an impact on bytecode size: unless they are optimized they are going to take a significant amount of memory and disk space.
Parrot uses typed registers, yes, but they are not mapped to HW registers (and with the current design that would be very hard to do in an efficient way while preserving the current semantics).
The main issue is whether using a register-based bytecode is any better at helping with executing the code fast once you use a jit. And the answer there is that it doesn't help at all. Except Itanium, all the other arch have fewer registers than parrot, so you can't map them all. If you map a few fixed registers you may miss performance opportunities, because the bytecode could use other registers for the time critical code (note also that the actual number of mappable registers depends on the plaform so you could have ok performance on ppc and terrible performance on x86, exposing HW details to people producing the bytecode).
The only sane option left is to do whole-method analysis and map only the hot registers, surprisingly the same thing jits for stack-based bytecode do. The end result is that having a register-based vm doesn't help at all for this issue.
Well, "it will run" is more whishful thinking than anything. Having actually implemented a .net runtime (mono) and knowing a bit about the parrot internals, I can say you that parrot won't run any significant .net program anytime soon and even if it will it will be very slow. Significant changes would be needed in the design to make it work and I don't expect that to happen any time soon.
Note that writing a big chunk of the perl interpreter in java or C# is not necessarily a bad thing:-)
One of the reasons parrot was born was to make for a cleaner runtime vs the current perl5 internals.
Whether parrot will succeed in this is still waiting on the jury (or better on parrot reaching at least some sort of beta quality release).
People may want to read the slides at http://www.research.ibm.com/vee04/Hylton.pdf by a Python developer. He writes:
It's not much fun to implement Python in C
In relation to the time and lines of code it took to implement CPython and IronPython.
Implementing perl in C# or Java would also have the advantage of defining some sort of specification for Perl the language which is currently defined more or less as what the current perl C implementation does (even if the perl test suite work is also helping define a more formal specification).
I doubt parrot will be implemented in HW any time soon:-)
A virtual machine that is register-based makes for a faster implementation of an interpreter vs a stack-based VM. Of course, if the issue is performance using an interpreter is not ideal:-)
Once you jit the code it doesn't matter much if the bytecode was register or stack based (except that the register based code requires you to make harder and slower analyses of the code if you need to check for type safety, for example if you care about security). Of course a VM that is register-based should not limit the number of registers: that is a limitation of the HW that doesn't need to be imposed on a sw implementation.
What matters instead is that using a register-based VM actually makes for a slower implementation when speed matters. Register allocation is one of the phases of a compiler that takes more time: perl running on parrot would need to perform it two times, first when the perl code is translated to the parrot internal register-based bytecode and a second time when parrot jits the code to native code.
But that is not all: registers in a VM are a global resource and as such, the optimizations that can be applied to the code are limited if the semantics are respected. On the other hand, stack slots are local to the call frame so the jit can make more assumptions about their use. Also, deciding on a call convention becomes a hard task, because the decisions on it can't be changed once finalized (otherwise all the bytecode breaks) . The parrot internal call convention has been changed at least two or three times already and there are proposals to change it again, because call performance is very slow. A stack-based VM doen't have these issues, because changing the call convention doesn't break the existing bytecode and it can be made to map to the HW registers, which parrot can't do with the current design.
IronPython is a demonstration that dynamic languages can run pretty well on mono: the fact that mono/the CLR implement a VM for a statically typed langauge (IL) would make mono not adequate has the same relevance as saying that C is not adequate to write a virtual machine and runtime for a dynamic language because C itself is not 'dynamic'.
.net: it's possible, but has a number of issues the first of which is that until the parrot internal design has been finalized no such effort can start:-) The other major issue is that currently any language that runs on top of parrot basically needs to be implemented in C, mostly because parrot doesn't provide a nice and powerful implementation language in the same way that, say, C# could be used in mono. This basically means that all the code needed to make a language run on top of parrot is very specific to the parrot C internals and hence parrot will not be usefully ported to any othger runtime that isn't the current C implementation.
As for parrot running some day on top of the JVM or
There is hope, though, that eventually the perl6 specification will emerge and that it will be possible to implement it efficiently in mono.
Just use the precompiled packages and apt-get or redcarpet.
Also note that he was referring to licensing issues: mono is free software so it can be legally included in distributions. Java has some distribution restrictions.
The MS license prohibits publishing benchmark data, but you can check for yourself, for example, the performance of Reflection.Emit (mcs, for example).
Last time I checked we did better also in a few cli-grande benchmarks and, of course, we could write benchmarks that highlight where we're faster.
Of course we have still work to do: anyone following mono development will find that the cvs version is already much faster than 1.0 and we have a roadmap page on the web site with details on the improvements we're currently working on.
I'll try to address some of the issues Havoc presented. Of course, I'm a Mono developer, so I'm biased, but hopefully people can see my arguments are more on the technical side than advocacy.
No rewrites please: this is a very important point: we can't just throw away the current code: we need incremental changes to not disrupt stability and compatibility. I'll just note that using Mono (and C#), interoperability with existing C code is much easier than with Java because of P/Invoke.
Calling managed code from C/C++: Havoc says it's hard, but Mono provides an easy to use interface to do that. Mono is designed to be embedded in existing applications, not just as a runtime for standalone completely managed programs. Also, it would be easy to create a shared library and header files to access managed methods seamlessly: they can be automatically generated thanks to the use of Reflection and the Mono embedding API.
I'm not sure a "simple native component system bridge" would solve the issues, mostly because simple systems are always found later to be incomplete, they get changed and become big, but with all the design warts needed to make a simple design work for not-so-simple constraints.
A minimal Mono system is currently about 2 MB on disk, but no effort yet has been put into reducing it (and I think it's entirely possible, we have been busy implementing features and leaving aside space optimizations). Of course, since the default build of the core assembly has lots of features, much of the reduction in size could be achieved by trimming features that other systems don't have:-). Even without trimming, most people will concour that 2 megabytes of disk space for a shared component is small enough in a desktop setting (and applications compiled to IL code are usually much smaller than comparable C apps anyway).
Community should decide: of course, I agree. Anything that is pushed down our throats by somebody else is not going to work for the free software and open source communities. The solution will need to be choosen because it actually solves issues the developers and the users see. Java had several years to try to attract developers from our community and it had some success in some niche areas (not for desktop applications, though). Mono has just started, but from the comments of the developers that actually used it to write new applications or port existing ones from C, it looks like we are on a good adoption path (even though we didn't release a 1.0 version yet, we are still working on debugging support and documentation is sparse).
Havoc fears the adoption of Mono or Java for the desktop would alienate people and cause forks. I don't think that will happen with Mono, because Gnome will continue to have a diversity of developers who'll prefer using the C libraries directly: Mono allows to keep and interoperate with existing code very easily and we want the migration to happen incrementally, so at first only end-user applications would be written in managed code, while the foundation would still be in C (at least, enough of the foundation to have people happyly writing their own apps in c or with the existing bindings). At that point, when a managed execution environment has proven itself to both developers and users (hopefully) we could start discussing about using it for the foundation, too, if that makes sense. I think Mono is positioned better here to allow this incremental shift of both development and espectations towards a managed runtime.
Problems with a .Net clone: Havoc claims that MS controls the platform
because, even if the core is unencumbered, some assemblies are tied to MS
technologies and there is non standards body or community momentum to build
alternative solutions for a complete platform. Well, considering that until
a couple of months ago there were 5 people developing mono, we have achieved a lot,
not only in the implementation of the runtime, but also, thanks to the large
commun
Note that we still need to do some performance and memory usage optimizations for Gtk# apps: we have just focused on implementing until now. I expect
the memory usage to drop significantly in the next few months as we approach a formal release.
We are not hostile at all to DotGNU.
We think we have a better implementation so we keep going forward with that. I don't think we're even competing since DotGNU seems to have different targets than us: for example the reason we built a JIT from the start is because we want Mono to be an efficient developer platform that enables people to move away from unsafe and difficult to use langauges: this of course would be not compatible with an interpreter design which is slow. By all means continue with the DotGNU implementation, improve it and try to build on its strengths, but don't just call us hostile only because we have a different implementation from yours.
You should probably check out the new DynamicMethod class: it allows creating methods at runtime that are not bound to a dynamic assembly and whose code can be garbage collected once it's no longer in use.
Mono implements it already.
Mono has already support for generics, both in the runtime and in the C# compiler (use the gmcs variant).
Crunched glass is an essential component when producing glass: it dramatically reduces the energy needed to melt sand and form new glass (it melts at a lower temperatures and provides for better transfer of heat). So, not only recycling glass is good to reduce waste, but it is essential in the modern industrial glass-making processes.
I worked at a glass factory, but you could have at least used google to learn how the process works.
What you seem to miss, though, is that patents on virtual machines technologies are as likely to apply to Mono as to Parrot, kaffe or other such efforts. Picking on Mono is short-sighted: the real issue is software patents and people should try to get the USPTO on track instead of whining on slashdot.