Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.misc > #1020
| From | "Rod Pemberton" <do_not_have@noavailemail.cmm> |
|---|---|
| Newsgroups | comp.lang.misc |
| Subject | Re: Learning to code by reading code |
| Date | 2012-02-23 07:03 -0500 |
| Organization | Aioe.org NNTP Server |
| Message-ID | <ji5a0v$23m$1@speranza.aioe.org> (permalink) |
| References | (9 earlier) <4f43548d$0$3083$7b1e8fa0@news.nbl.fi> <jhvobn$ujr$1@speranza.aioe.org> <jhvtig$fam$1@dont-email.me> <ji2ht3$9j3$1@speranza.aioe.org> <ji2otf$n6q$1@dont-email.me> |
"BartC" <bc@freeuk.com> wrote in message news:ji2otf$n6q$1@dont-email.me... > "Rod Pemberton" <do_not_have@noavailemail.cmm> wrote in message > news:ji2ht3$9j3$1@speranza.aioe.org... > > "BartC" <bc@freeuk.com> wrote in message > > news:jhvtig$fam$1@dont-email.me... > >> "Rod Pemberton" <do_not_have@noavailemail.cmm> wrote in message > >> news:jhvobn$ujr$1@speranza.aioe.org... ... > >> > There are two fundamental problems with interpreters that > >>> can't be overcome: 1) they reimplement the mechanisms of > >> > assembly language which slows things down alot > > What does that mean? > It means that an assembly operation, say moving data to a register from memory, will generally be one or maybe two instructions in assembly. However, for a virtual machine used by an interpreter, there will be more instructions to perform the equivalent move of data to a virtual machine register from memory. I.e., the use of a virtual machine forces the hardware capabilities of a microprocessor to be reimplemented in software for the virtual machine. So, you've got say one or two instructions in assembly for some operation, or you've got say five to ten instructions in assembly to implement the same operation in assembly code for the virtual machine. The interpreter reimplements in assembly for it's virtual machine what the instruction set already does for the native register set. That's overhead. > >> Every instruction that the interpreter deals with could be implemented > >> by a carefully hand-crafted and optimised block of assembly code! > > > > So? An interpreter still reimplements for a virtual machine what native > > assembly already does, i.e., slower. > > I don't understand that either. But perhaps you're comparing an > interpreter and compiler for the *same* static language? My > assumption is that interpreters are used for dynamic languages, > and compilers for static ones. It's true for any interpreter. > >> Sometimes better than automatically compiled code. > > > > The "hand" optimized sequences for interpreters are much smaller than > > what a compiler usually optimizes. So, while the small pieces might be > > optimized better, overall the larger compiler pieces are better > > optimized. > > That's true up to a point. But when interpreters are working with > higher-level data, you might need fewer pieces anyway; see my a:=b*c > example below. Also with a limited number of handlers for each bytecode, > the entire executable code can be more compact than that of equivalent > compiled code (even allowing for the extra data demands of the bytecode > itself), making it more cache-friendly. > With an interpreter, you have a bunch of small code snippets that have to be executed. If you call them, then the resulting code will not be as fast as compiled code that will be inlined and not use calls. Of course, there are interpreters that can do inlining of code pieces, however, that requires a built-in compiler which has overhead also. With a compiler, the overhead is in the compiler, it's not in the interpreter. The resulting compiled code from a compiler doesn't need an interpreter or built-in compiler. > [...] > Your complaint then is that when an interpreter gets too clever, then it's > because it's cheating! No, I just think the definition of an interpreter should be limited to interpretation. Compiling to compiling. etc. If it's some type of hybrid system, of which there are a few, then we need another term(s) for it. Some "interpreters" can generate inlined code. They are hybrid combinations of interpreting and compiling. > >> C is pretty good, but it has to spend a lot of time recognising > >> constructs in the source code [which] could be expressed > >> directly in a higher level language and which can be executed > >> directly (vector operations for example). It doesn't always > >> manage to do that. > > > > Those constructs must still be converted to assembly. So, even if > > you can "express them directly", what real advantage is that? > > Suppose you have a matrix as a built-in, intrinsic type. Then you can > write: > > a:=b*c > > ie. matrix multiplication. Right, there is a slight advantage of not having to do a bit of programming and convenient syntax ... Where is the real advantage? Matrix multiplication is low use, at least for general programming. Much of the syntax complexity for another language like C can be hidden behind #define's or procedures. > Then the interpreter knows to invoke the fastest > possible code for the operation, already developed and optimised. > > In something like C, this will be a mess of nested loops, array > indices and what-not [...] How is the interpreter any different than C here? It too converts "a:=b*c" into that "mess of nested loops [etc]" to perform the operation. Some interpreters could generate special microprocessor instructions or call a handcoded routine for better performance, but that would be atypical ... Also, it really defeats the purpose of an interpreter to put as much work into it as a highly-optimized C library. The purpose of an interpreter is to be simple and interactive. > In something like C, this will be a mess of nested loops, array indices > and what-not which may or may not end up being compiled into the > fastest processor instructions. How is the interpreter any better here? The interpreter must interpret a large set of operations equivalent that "mess of nested loops" or it must have a hand coded routine in assembly for speed ... If the compiled code doesn't need specialized instructions, then neither of those are likely to be optimized better than the C compiler working on the "mess of nested loops". The only way handcoded assembly would be better is if specialized instructions that the compiler can't generate are needed, i.e., the compiler is producing code for the x86 and generates optimized GP instructions while the handcoded routine is using faster MMX or SSE. Most interpreters aren't able to inline code pieces, so they must call each little routine which adds overhead. A compiler with optimization won't add that call overhead and can optimize multiple pieces together. Rod Pemberton
Back to comp.lang.misc | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Re: Learning to code by reading code (was: The way to read STL source code) "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-02-18 19:00 -0500
Re: Learning to code by reading code "MikeWhy" <boat042-nospam@yahoo.com> - 2012-02-18 22:34 -0600
Re: Learning to code by reading code "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-02-19 03:54 -0500
Re: Learning to code by reading code "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2012-02-19 10:42 +0100
Re: Learning to code by reading code "BartC" <bc@freeuk.com> - 2012-02-19 22:34 +0000
Re: Learning to code by reading code "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2012-02-20 12:22 +0100
Re: Learning to code by reading code "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-02-20 03:39 -0500
Re: Learning to code by reading code "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-02-19 03:54 -0500
Re: Learning to code by reading code Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-02-19 08:40 -0800
Re: Learning to code by reading code "MikeWhy" <boat042-nospam@yahoo.com> - 2012-02-19 13:17 -0600
Re: Learning to code by reading code Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-02-20 02:32 -0800
Re: Learning to code by reading code "io_x" <a@b.c.invalid> - 2012-02-20 13:02 +0100
Re: Learning to code by reading code Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-02-20 05:09 -0800
Re: Learning to code by reading code "io_x" <a@b.c.invalid> - 2012-02-20 15:11 +0100
Re: Learning to code by reading code Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-02-20 07:39 -0800
Re: Learning to code by reading code "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-02-20 04:14 -0500
Re: Learning to code by reading code "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2012-02-20 11:14 +0100
Re: Learning to code by reading code Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-02-20 05:13 -0800
Re: Learning to code by reading code Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-02-20 02:49 -0800
Re: Learning to code by reading code "io_x" <a@b.c.invalid> - 2012-02-20 13:02 +0100
Re: Learning to code by reading code Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-02-20 05:18 -0800
Re: Learning to code by reading code "BartC" <bc@freeuk.com> - 2012-02-20 13:53 +0000
Re: Learning to code by reading code Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-02-21 01:32 -0800
Re: Learning to code by reading code "io_x" <a@b.c.invalid> - 2012-02-21 16:16 +0100
Re: Learning to code by reading code Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-02-21 08:40 -0800
Re: Learning to code by reading code "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-02-20 17:36 -0500
Re: Learning to code by reading code Dombo <dombo@disposable.invalid> - 2012-02-21 00:45 +0100
Re: Learning to code by reading code "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-02-21 04:35 -0500
Re: Learning to code by reading code Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-02-21 08:48 -0800
Re: Learning to code by reading code Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-02-22 00:12 -0800
Re: Learning to code by reading code "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-02-22 06:12 -0500
Re: Learning to code by reading code Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-02-22 04:30 -0800
Re: Learning to code by reading code Geoff <geoff@invalid.invalid> - 2012-02-22 10:45 -0800
Re: Learning to code by reading code Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-02-23 01:12 -0800
Re: Learning to code by reading code "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-02-23 07:34 -0500
Re: Learning to code by reading code Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-02-23 05:46 -0800
Re: Learning to code by reading code "io_x" <a@b.c.invalid> - 2012-02-24 08:38 +0100
Re: Learning to code by reading code "io_x" <a@b.c.invalid> - 2012-02-24 08:40 +0100
Re: Learning to code by reading code "io_x" <a@b.c.invalid> - 2012-02-24 09:38 +0100
Re: Learning to code by reading code "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-02-25 05:25 -0500
Re: Learning to code by reading code Dombo <dombo@disposable.invalid> - 2012-02-25 12:50 +0100
Re: Learning to code by reading code Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-02-25 06:13 -0800
Re: Learning to code by reading code Gareth Owen <gwowen@gmail.com> - 2012-02-26 07:20 +0000
Re: Learning to code by reading code Juha Nieminen <nospam@thanks.invalid> - 2012-02-21 08:23 +0000
Re: Learning to code by reading code Juha Nieminen <nospam@thanks.invalid> - 2012-02-21 08:43 +0000
Re: Learning to code by reading code "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-02-21 04:47 -0500
Re: Learning to code by reading code Juha Nieminen <nospam@thanks.invalid> - 2012-02-21 10:09 +0000
Re: Learning to code by reading code "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-02-22 05:38 -0500
Re: Learning to code by reading code "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-02-21 04:31 -0500
Re: Learning to code by reading code Juha Nieminen <nospam@thanks.invalid> - 2012-02-21 10:05 +0000
Re: Learning to code by reading code "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2012-02-21 12:21 +0100
Re: Learning to code by reading code "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-02-22 06:04 -0500
Re: Learning to code by reading code "BartC" <bc@freeuk.com> - 2012-02-21 11:01 +0000
Re: Learning to code by reading code "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-02-22 05:59 -0500
Re: Learning to code by reading code "BartC" <bc@freeuk.com> - 2012-02-22 12:59 +0000
Re: Learning to code by reading code "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-02-23 07:03 -0500
Re: Learning to code by reading code "BartC" <bc@freeuk.com> - 2012-02-24 14:20 +0000
Re: Learning to code by reading code Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-02-21 01:27 -0800
Re: Learning to code by reading code Peter Remmers <p.remmers@expires-2011-04-30.arcornews.de> - 2012-02-20 22:25 +0100
Re: Learning to code by reading code Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-02-26 08:47 +0000
Re: Learning to code by reading code "BartC" <bc@freeuk.com> - 2012-02-26 10:55 +0000
Re: Learning to code by reading code Nomen Nescio <nobody@dizum.com> - 2012-02-22 08:59 +0100
Re: Learning to code by reading code "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-02-22 05:59 -0500
Re: Learning to code by reading code Nomen Nescio <nobody@dizum.com> - 2012-02-22 13:47 +0100
Re: Learning to code by reading code "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-02-23 06:21 -0500
Re: Learning to code by reading code Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-02-22 00:08 -0800
Re: Learning to code by reading code "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-02-19 03:54 -0500
Re: Learning to code by reading code Marco van de Voort <marcov@toad.stack.nl> - 2012-02-19 11:27 +0000
csiph-web