On Fri, Nov 03, 2000 at 10:52:45AM -0800, Steve Fink wrote:
> Jarkko Hietaniemi wrote:
> >
> > Some sort of SGI megaserver, dunno MHz, but load is high (more than
> > five times the number of CPUs...), so the following numbers are a tad slow,
> > but I guess relatively right:
> >
> >
Jarkko Hietaniemi wrote:
>
> Some sort of SGI megaserver, dunno MHz, but load is high (more than
> five times the number of CPUs...), so the following numbers are a tad slow,
> but I guess relatively right:
>
> -O3 none
>
> switch 7.027.70
> orig16.
Some sort of SGI megaserver, dunno MHz, but load is high (more than
five times the number of CPUs...), so the following numbers are a tad slow,
but I guess relatively right:
-O3 none
switch 7.027.70
orig16.59 15.92
naive 18.96 18.96
hyb
Another compiler nit:
cc-1116 cc: WARNING File = vm.c, Line = 84
Non-void function "count_ops" (declared at line 59) should return a value.
}
^
--
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'. -- Jack Cohen
Fwiw:
BSDI BSD/OS 4.0.1 .../GENERIC i386
gcc version 2.7.2.1
-O3 none
GOTO1.739.31
SWITCH 7.4019.81
Everything else 12.62 15.24
--
John Porter
On Thu, Nov 02, 2000 at 06:43:10PM -0500, Ken Fox wrote:
> Jarkko Hietaniemi wrote:
> > FWIW, I would like to see results for these little tests also for
> > other platforms than just gcc on Intel (on Linux...) :-) I tried
> > quickly hacking the test script and C source to be more portable
> > bu
Steve Fink wrote:
> and I get the same numbers for -O (I used -O3) but different numbers
> without optimization. Maybe we should assume optimization?
The difference was probably -fomit-frame-pointer that I used in both
the -g and -O cases. Some of my code was fragile to optimization so I
wanted t
Jarkko Hietaniemi wrote:
> FWIW, I would like to see results for these little tests also for
> other platforms than just gcc on Intel (on Linux...) :-) I tried
> quickly hacking the test script and C source to be more portable
> but it took me more than a few minutes so I gave up...
I just tried
> I think the best architecture would be one with two dispatch systems.
> A really fast/simple one (possibly obscure) that's used for small
> instructions like array indexing, counter increments, sub calls, etc.
It wouldn't be the first time when a hybrid solution proves to be the
best balance be
Steve Fink wrote:
> I just did all that because the magnitude of the difference between
> using separate functions and using the closer-to-assembly solutions
> (switch and goto) seemed too large. I can easily believe they're faster,
> but not by that much, and I didn't want to unnecessarily lose t
Simon Cozens wrote:
>
> On Wed, Nov 01, 2000 at 05:35:17PM -0800, Steve Fink wrote:
> > Algorithm Inline? OptimizationTime (sec)
> > GOTO- -O3 1.35
> > FUNCALL_HYBRID yes -O3 4.20
> > FUNCALL_
On Wed, Nov 01, 2000 at 05:35:17PM -0800, Steve Fink wrote:
> Algorithm Inline? OptimizationTime (sec)
> GOTO- -O3 1.35
> FUNCALL_HYBRID yes -O3 4.20
> FUNCALL_PREDICTABLE no -
Ken Fox wrote:
>
> I was noodling around with a couple different VM implementations
> and thought I would ask other people if they were doing the same.
> It would be nice to divide and conquer the exploration of different
> implementations.
>
> I looked into 3 different dispatching techniques. H
I was noodling around with a couple different VM implementations
and thought I would ask other people if they were doing the same.
It would be nice to divide and conquer the exploration of different
implementations.
I looked into 3 different dispatching techniques. Here's the list
with timings on
14 matches
Mail list logo
