|[2 earlier articles]|
|Re: General byte-codes reference firstname.lastname@example.org (Daniel Dunbar) (2000-12-08)|
|Re: General byte-codes reference email@example.com (2000-12-11)|
|Re: General byte-codes reference firstname.lastname@example.org (2000-12-11)|
|Re: General byte-codes reference Norman_member@newsguy.com (Norman Culver) (2000-12-18)|
|Re: General byte-codes reference email@example.com (2000-12-18)|
|Re: General byte-codes reference firstname.lastname@example.org (Pat Caudill) (2000-12-18)|
|Re: General byte-codes reference email@example.com (2000-12-20)|
|Re: General byte-codes reference firstname.lastname@example.org (2000-12-21)|
|Re: General byte-codes reference email@example.com (2000-12-31)|
|From:||firstname.lastname@example.org (Steve Meyer)|
|Date:||20 Dec 2000 17:24:02 -0500|
|Organization:||Global Network Services - Remote Access Mail & News Services|
|Posted-Date:||20 Dec 2000 17:24:01 EST|
On 18 Dec 2000 00:42:50 -0500, Norman Culver <Norman_member@newsguy.com> wrote:
>>Hi, I'm interested in learning a bit more about byte codes in
>>general. ie: If one were to write an interpreted language, what sort
>>of byte codes to use?
This might be slightly off topic but nearly all compiler writing area
conference proceedings are filled with papers on better and "faster"
"methods" for virtual machine (aka byte code) optimization. However,
as I read the papers, performance comparison is always against "slow"
current Java interpreted performance not against same program written
or compiled into C where academic optimizations would would be so
small it would not be visable on bar charts. Or am missing something?
I think at least as of now projects such as c-- are much more
>You have to take into account various factors such as CPU speed,
>memory speed and cache size. I've been doing a series of experiments
>with interpreters hand coded in assembler for some of the latest
>processors. It is possible to fit an entire interpreter into the L1
>cache (64 KB) of a 1 Ghz AMD but it won't fit into the 16 KB cache of
>a Pentium III. The Pentium IV with 12,000 trace cache entries looks
>very interesting but I don't have one to play around with.
>The choice of byte codes is highly dependent upon the CPU architecture
>so I would go with a generalized form in the object modules and let
>the loader adapt them to the run time environment.
My experience from digital hardware simulation area, where huge effort
has been put into performance, is that just reducing code size to fit
in cache does not help much. Better measure is combined data and code
>Call me crazy but I think that the OS kernel may best be interpreted
>when CPU speed hits 2GHZ and above.
Steve Meyer Phone: (415) 296-7017
Pragmatic C Software Corp. Fax: (415) 296-0946
220 Montgomery St., Suite 925 email: email@example.com
San Francisco, CA 94104
Return to the
Search the comp.compilers archives again.