Dear Dan, You are doing a wonderful job and my intension is not to pass judgements on any one's technical abilities on this list. We have a bunch of very talented people here that would be difficult to match in any other group.
:> The interpreter is way too slow and we all admit to that. : :No, we don't, actually. The benchmarks show us running around twice the op :rate of perl 5 and python. Whether this is sufficient depends on what :those ops do. My thinking is the rate is insufficient, but we won't know :for sure until we have something more closely equivalent. Of course, we should finally be faster than perl/python to make the effort worthwhile. But why is this a reasonable measure? The output of parrot->C compiler on test.pbc compiled with -O0 switch gives a (ops/s) performance of 110-120M. (libparrot was compiled with an O3.) ./test_prog compiled with a -O3 give about 17-19M on my machine (PIII, 650). It is reasonable to expect these two quantities to be within a factor of 2 or thereabouts. This measure directly says something about the quality of the instruction dispatcher. :> Most use threaded code approaches : :Which require significant amounts of preprocessing on code loaded from :disk, amongst other things. It's a technique that has its own costs :associated with it. Preprocessing of code?? :> and gcc specifically allows the so called :> "labels as values" to allow threading. (It is not ansi C complaint: : :Which is why the base interpreter won't use it. If we're going to break :ANSI compliance (and we will) we're going to do it in a big way. We're :certainly not going to tie ourselves to gcc in doing it, given gcc's :rather sub-optimal optimizer. Good. We will search for solutions that will not break ANSI then. :> At the minimum, we should looking at some variant of threading. Otherwise :> there is simply no way we can have a fast interpreter. Some of the ideas of :> Gregor Purdy based on the parrot->C experience will, I think, lead to :> rediscovery of threading (maybe an efficient variant!). : :You're about a year behind. I'm well aware of threading techniques, along :with quite a few other tricks. : :I think you're passing judgement far, *far* too early. (And you're :underestimating both the design and the tricks I have handy) I know the :places we're trading off speed for simplicity and cleanliness, and I know :when and where we're going to stop doing that. Cool it! I come from an academic world where nothing is holy and all ideas are subject scrutiny. But there is no scope for personal attacks, or being judgemental. So please don't read between the lines. My only points were, this is a good time to make things faster; switches will not help substantially in this cause; theading is a possibility. Your (read: the list) response to the definition of "reasonable measure" above will tell me if I can contribute anything useful to the discussions here. If you think there is some merit to having a measure such as above, we can work on that. If you take is as an affront, I will back-off, and watch and learn from the sidelines. Regards Vinay : : Dan : -- V Vinay Associate Professor Founder Dept of Computer Science and Automation PicoPeta Simputers Pvt Ltd Indian Institute of Science 146, 5th Cross, RMV Extn Bangalore - 560 012 Bangalore - 560 080 Ph: (80) 3092776 Ph: (80) 3467567
