yeah. I didn't much go into the low-level details...
but, yeah, I personally believe there is more merit in stack-based VMs than register based ones, for the primary reasons: it is much easier for compilers to target stack-based VMs; a register-based VM will not offer much practical advantage over a stack based one unless it conforms almost exactly with the arch's available register set, and the interpreter is designed to make use of this (for example, a RISC-like register-based VM will not deliver much performance on x86...); the level of transformations applied in the JIT process to make a register VM perform well, will perform similarly effectively, if not better, than on a stack machine (it is by no means difficult to transform from a stack model into an SSA graph...). so, for a VM, if JIT is to be used, I think it is more useful to design the bytecode in such a way that it is easy to compile to, and leave most of the low-level optimization work up to the code generator. AFAIK, in terms of actual use, Parrot has not competed effectively WRT performance vs more traditional stack-based VMs. meanwhile, my C compiler has used a plain stack model, and for many of my tests had gotten performance similar to or better than GCC's output. the one area though where my compiler was weaker was in terms of floating-point / numerical code, in part this being due to SSE not being as high-performance as x87 in my tests, and in the case of x87, the difficulty of generating code that uses the FPU effectively (GCC doing a generally much better job at this). as far as parrallelism, vectors, and the GPU, I look forwards to developments in these areas. of course, part of the difficulty is that effectively exploiting parallelism proves rather difficult, and at present there are no really established and good concurrency models. approaches I have looked into personally have included: synchronous and asynchronous function and method calls (providing compiler hints as to when and how to branch and merge the execution stream); the use of "channels" (1); Erlang-style processes, and the use of serializing message pools and queues (2); .. 1. I found: http://en.wikipedia.org/wiki/Communicating_sequential_processes I remember that Rob Pike was doing some things in this area; (I remember it was related to the Plan 9 OS, but I don't remember the name of the language and can't find the papers I am looking for. 2. I can make use of this from within C and when making use of conventional threading, and personally find the use of message queues to be more "intuitive" than more far-reaching alternatives. a thread and a queue can be easily made to look like an Erlang-style process, although there are more efficient ways to implement these, such as via the use of worker threads and work-queues (I have considered this at times as a possible alternative in many situations to both hard and soft threads). another route for parallelism is explicitly parallizing some forms of numerical calculations (this route also being explored some by Microsoft and Intel). another route I use in some cases is actually to leave many subsystems under the control of dedicated threads, and where the API calls serialize just enough to relay requests to this thread (this is similar to conventional threading, except that since an entire subsystem is left under the control of a dedicated thread, it is much easier to maintain good performance due to the lack of need to lock everything). I had actually considered adding this design for a physics library I had written before, but never got to it. however, a consistent and general-purpose formal model for this kind of thing would be nice... working with shared memory models, ... is also something I have had some experience with in the past (in around 2003 I managed to make a GUI and an interactive 3D environment where both the code and world state was shared between 2 computers over a LAN, and where the memory was effectively shared between them). my C compiler includes some facilities (although never completed) specifically for working with a shared but very large address space (in effect, 128 bit segmented addressing, although the segmented nature of the addressing was effectively hidden). more recently I have been looking more into "higher level" ways of managing distributed systems (it is IMO better to manage things at the level of data and objects than at the level of shared memory addressing...). and so on... ----- Original Message ----- From: Greg Vincent To: Fundamentals of New Computing Sent: Sunday, December 07, 2008 5:56 PM Subject: Re: [fonc] ok, thoughts: VM design... The subject matter at this link location factors in additional considerations pertaining to machine architecture. g
_______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
