Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!purdue!haven!vrdxhq!daitc!daitc.daitc.mil From: jkrueger@daitc.daitc.mil (Jonathan Krueger) Newsgroups: comp.arch Subject: Re: RISC and emulated languages Message-ID: <513@daitc.daitc.mil> Date: 9 May 89 18:48:51 GMT References: <158@bms-at.UUCP> Sender: jkrueger@daitc.daitc.mil Reply-To: jkrueger@daitc.daitc.mil (Jonathan Krueger) Organization: DTIC Special Projects Office (DTIC-SPO), Alexandria VA Lines: 32 In article <158@bms-at.UUCP>, stuart@bms-at (Stuart Gathman) writes: >There is one interesting feature of RISC architecture that I haven't seen >mentioned much: the fact that an emulated/interpreted program will often >run faster than a compiled one. >... >This approach turns a RISC machine into a CISC machine with user defined >microcode. Unlike loadable microcodes of yesteryear, the cache is swapped >by line on a demand basis. One might also cite relational engines for DBMS, which interpret query languages (even when executing "compiled" procedures, they do not generate standalone images, they just pre-fetch and "decode" (parse and optimize) the query. Clearly this approach yields a more flexible system than linking (ISAM, VSAM, etc.) routines into each image. The surprising part is it can be faster, too. One reason is that the engine can do a better job of staying in cache than the images. The engine implements common functions that service everyone. The most often used ones are found in cache. (Sets of images lose even when the operating system supports execution from shared memory, because it's hard to decide at runtime whether each image's routines can service other images.) And unlike loadable microcodes of yesteryear, they allocate fast memory in response to usage patterns that vary at runtime. So next time you get a new release of your RDBMS, just tell management that you're installing new microcode :-) -- Jon Jonathan Krueger ...uunet!daitc!jkrueger jkrueger@daitc.mil (703) 998-4600 My opinions are not necessarily those of my wallpaper.