Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #39887 > unrolled thread

Loop optimisation.

Back to article view | Back to comp.lang.javascript

Contents

  Loop optimisation. The Natural Philosopher <tnp@invalid.invalid> - 2021-04-10 18:41 +0100
    Re: Loop optimisation. John G Harris <niam@jghnorth.org.uk.invalid> - 2021-04-10 19:14 +0100
      Re: Loop optimisation. The Natural Philosopher <tnp@invalid.invalid> - 2021-04-11 11:33 +0100
        Re: Loop optimisation. John G Harris <niam@jghnorth.org.uk.invalid> - 2021-04-11 15:03 +0100
          Re: Loop optimisation. "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2021-04-11 07:38 -0700
            Re: Loop optimisation. Jonas Thörnvall <jonas.thornvall@gmail.com> - 2021-04-11 13:36 -0700
            Re: Loop optimisation. John G Harris <niam@jghnorth.org.uk.invalid> - 2021-04-12 18:05 +0100
              Re: Loop optimisation. The Natural Philosopher <tnp@invalid.invalid> - 2021-04-12 23:16 +0100
                Re: Loop optimisation. Jonas Thörnvall <jonas.thornvall@gmail.com> - 2021-04-13 05:19 -0700
                  Re: Loop optimisation. "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2021-04-13 06:21 -0700
          Re: Loop optimisation. The Natural Philosopher <tnp@invalid.invalid> - 2021-04-12 01:36 +0100
            Re: Loop optimisation. John G Harris <niam@jghnorth.org.uk.invalid> - 2021-04-12 18:04 +0100
              Re: Loop optimisation. The Natural Philosopher <tnp@invalid.invalid> - 2021-04-12 23:09 +0100
                Re: Loop optimisation. John G Harris <niam@jghnorth.org.uk.invalid> - 2021-04-13 20:08 +0100
                  Re: Loop optimisation. The Natural Philosopher <tnp@invalid.invalid> - 2021-04-13 21:41 +0100
                    Re: Loop optimisation. John G Harris <niam@jghnorth.org.uk.invalid> - 2021-04-14 18:24 +0100
    Re: Loop optimisation. Kristjan Robam <he12457@hotmail.com> - 2021-04-10 13:36 -0700
      Re: Loop optimisation. The Natural Philosopher <tnp@invalid.invalid> - 2021-04-11 11:34 +0100
    Re: Loop optimisation. "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2021-04-10 22:22 -0700
      Re: Loop optimisation. The Natural Philosopher <tnp@invalid.invalid> - 2021-04-11 11:36 +0100
      Re: Loop optimisation. Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2021-04-14 02:20 +0200
        Re: Loop optimisation. "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2021-04-14 06:48 -0700
          Re: Loop optimisation. Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2021-04-14 17:31 +0200
            Re: Loop optimisation. Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2021-04-14 18:00 +0200
              Re: Loop optimisation. The Natural Philosopher <tnp@invalid.invalid> - 2021-04-14 19:25 +0100
              Re: Loop optimisation. Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2021-04-14 23:10 +0200
                Re: Loop optimisation. "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2021-04-17 09:45 -0700
              Re: Loop optimisation. "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2021-04-17 09:43 -0700
                Re: Loop optimisation. Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2021-04-17 21:45 +0200
                  Re: Loop optimisation. Scott Sauyet <scott.sauyet@gmail.com> - 2021-04-18 19:06 -0700
            Re: Loop optimisation. "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2021-04-17 08:50 -0700

Page 2 of 2 — ← Prev page 1 [2]

#39928

Michael Haufe (TNO) wrote:

> Modern JavaScript engines use JIT compilation.

AFAIK, they always did.  What is new with “modern JavaScript engines”, IOW 
Google V8 (JavaScript), is only that the source code is compiled to native 
machine code instead of bytecode for a virtual machine.

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | <http://PointedEars.de/es-matrix>
<https://github.com/PointedEars> | <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | Please do not cc me./Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#39936

On Tuesday, April 13, 2021 at 7:20:42 PM UTC-5, Thomas 'PointedEars' Lahn wrote:
> Michael Haufe (TNO) wrote: 
> 
> > Modern JavaScript engines use JIT compilation.
> AFAIK, they always did. What is new with “modern JavaScript engines”, IOW 
> Google V8 (JavaScript), is only that the source code is compiled to native 
> machine code instead of bytecode for a virtual machine. 

Afraid not. They were all interpreters 

- Firefox 3.1 was the first browser to introduce a JIT in version 3.1 called TraceMonkey [1]
- Google followed Firefox closely and introduced their competitor V8 in Chrome 2, which was more of a compiler than a JIT [2]
- Microsoft added a JIT in IE9 with Chakra [3]
- Webkit added their compiler in version 3.2 AFAICT [4]
- Finally, Opera added their compiler/JIT with Carakan in version 10.5

Comparatively speaking at the time Firefox had the fasted engine at the time, followed by Chrome. Firefox had the advantage namely because they extended their interpreter with a JIT instead of performing an AOT compilation. For short running code they could finish executing with the plain interpreter before Chrome would finish compilation. For longer running code it was neck and neck as they would both be competing with compiled JS by then. At the time it seemed Firefox still did better than Chrome as the former could switch back to the interpreter when their was code with unstable types, where Chrome had to throw away and recompile on the fly, or had to fall back to the most general types. Example: I have a variable 'foo' and in my code I assign objects, booleans, strings, and arrays to it. Most people don't write code like that, but some do (like some un-named people in this group). Chrome performed poorly on those types of code-bases.

Today I can't tell the difference usually. Mozilla does track some of the competition still but practically they are so close now it's not too noticeable for most applications:

<https://arewefastyet.com/win10/benchmarks/overview?numDays=60>

[1] <https://brendaneich.com/2008/08/tracemonkey-javascript-lightspeed/>
[2] <https://en.wikipedia.org/wiki/V8_(JavaScript_engine)>
[3] <https://en.wikipedia.org/wiki/Chakra_%28JScript_engine%29>
[4] <https://webkit.org/blog/189/announcing-squirrelfish/> [5]
[5] <https://en.wikipedia.org/wiki/Presto_(browser_engine)#ECMAScript_engines>

[toc] | [prev] | [next] | [standalone]

#39937

Michael Haufe (TNO) wrote:

> On Tuesday, April 13, 2021 at 7:20:42 PM UTC-5, Thomas 'PointedEars' Lahn
> wrote:
>> Michael Haufe (TNO) wrote:
>> 
>> > Modern JavaScript engines use JIT compilation.
>> AFAIK, they always did. What is new with “modern JavaScript engines”, IOW
>> Google V8 (JavaScript), is only that the source code is compiled to
>> native machine code instead of bytecode for a virtual machine.
> 
> Afraid not. They were all interpreters
> 
> - Firefox 3.1 was the first browser to introduce a JIT in version 3.1
> called TraceMonkey [1] -

No, certainly not.  The wording “a new kind of Just-In-Time (JIT) compiler” 
does not imply that previous script engines interpreted source code.

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | <http://PointedEars.de/es-matrix>
<https://github.com/PointedEars> | <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | Please do not cc me./Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#39939

Thomas 'PointedEars' Lahn wrote:

> Michael Haufe (TNO) wrote: 
>> On Tuesday, April 13, 2021 at 7:20:42 PM UTC-5, Thomas 'PointedEars' Lahn
>> wrote:
>>> Michael Haufe (TNO) wrote:
>>> > Modern JavaScript engines use JIT compilation.
>>> AFAIK, they always did. What is new with “modern JavaScript engines”,
>>> IOW Google V8 (JavaScript), is only that the source code is compiled to
>>> native machine code instead of bytecode for a virtual machine.
>> 
>> Afraid not. They were all interpreters
>> 
>> - Firefox 3.1 was the first browser to introduce a JIT in version 3.1
>> called TraceMonkey [1] -
> 
> No, certainly not.  The wording “a new kind of Just-In-Time (JIT)
> compiler” does not imply that previous script engines interpreted source
> code.

This should clarify your misconception:

<https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey/Internals/Bytecodes>

See also: 

<https://softwareengineeringdaily.com/2018/10/03/javascript-and-the-inner-workings-of-your-browser/#:~:text=The%20JavaScript%20engine%20is%20the,MacOS%2C%20Windows%2C%20or%20Linux.>

| [00:03:39] JM: Mathias Bynens, you are a software engineer at Google
| working on developer advocacy on the V8 team. Welcome to Software
| Engineering Daily.
| 
| […]
| 
| Give me a high-level perspective for the steps that are happening as this
| webpage with some various forms of JavaScript opens up.
| 
| [00:04:26] MB: […]
| 
| So the first thing that happens is the JavaScript source code goes into
| the JavaScript [engine’s] parser, which then takes that code and turns
| into an object-based representation, which we call an abstract syntax tree
| or an AST. Armed with AST, we can do some transformations on the code, do
| some [inaudible 00:05:06] here and there, but mainly the reason to have
| this AST is so that we can feed it into the first phase of execution,
| which is the interpreter.
| 
| So our interpreter in V8, it’s called Ignition. This interpreter generates
                                                       ^^^^^^^^^^^^^^^^^^^^^
| bytecode, which then runs in the interpreter. At that point we’re actually
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Since this is actually *compilation* (conversion of human-readable source 
code to machine-readable code), that part of the “interpreter” is actually
technically a _compiler_.

And since the machine-readable code is not “interpreted“ by the CPU 
firmware, but by a software, the "machine" that executes/“interprets” it is 
called a *virtual machine*.

IOW: a JIT-compiler converts source code to bytecode to be 
executed/“interpreted” by a virtual machine.

| running the JavaScript already, which is great. It’s like all we have to
| do is sparse it and then generate some bytecode in the interpreter, which
| can happen pretty quickly. So that’s great for a code that only needs to
| run once. For example, a lot of code on the web is code that initializes
| the webpage and you don’t run that in a loop very open, right? You only
| run it once. You load the page. So all that magic can happen in the
| interpreter with the bytecode that we generate.
| 
| But that’s not the end of the story, because sometimes code gets repeated
| quite often or we see that the same code paths get hit over and over and
| over again, and that point it might make sense to start optimizing those
| specific functions, right?
| 
| That’s why while we’re running the bytecode in the interpreter, JavaScript
| engines – Well, V8 does this, but all JavaScript engines basically do
                                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
| this. […].
`----

JIT-compilation of source code to bytecode to be executed by a virtual 
machine is nothing unusual for so-called "interpreted languages".  For 
example, the same happens with Perl and Python code since time immemorial.

Unfortunately, there is a lot of confusion about this (on the Nets).

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | <http://PointedEars.de/es-matrix>
<https://github.com/PointedEars> | <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | Please do not cc me./Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#39941

On 14/04/2021 17:00, Thomas 'PointedEars' Lahn wrote:
> And since the machine-readable code is not “interpreted“ by the CPU
> firmware, but by a software, the "machine" that executes/“interprets” it is
> called a*virtual machine*.
> 
> IOW: a JIT-compiler converts source code to bytecode to be
> executed/“interpreted” by a virtual machine.

Today, with any CISC machine, the 'machine readable code' *is* 
interpreted by the microcode ;-)



-- 
It’s easier to fool people than to convince them that they have been fooled.
Mark Twain

[toc] | [prev] | [next] | [standalone]

#39942

Thomas 'PointedEars' Lahn wrote:
 
> <https://softwareengineeringdaily.com/2018/10/03/javascript-and-the-inner-workings-of-your-browser/#:~:text=The%20JavaScript%20engine%20is%20the,MacOS%2C%20Windows%2C%20or%20Linux.>
> 
> | [00:03:39] JM: Mathias Bynens, you are a software engineer at Google
> | working on developer advocacy on the V8 team. Welcome to Software
> | Engineering Daily.
> | 
> | […]
> | 
> | Give me a high-level perspective for the steps that are happening as
> | this webpage with some various forms of JavaScript opens up.
> | 
> | [00:04:26] MB: […]
> | 
> | So the first thing that happens is the JavaScript source code goes into
> | the JavaScript [engine’s] parser, which then takes that code and turns

The original reads “JavaScript engine sparser”.  I assumed that it is a 
typo.  But:

> […]
> | running the JavaScript already, which is great. It’s like all we have to
> | do is sparse it and then generate some bytecode in the interpreter, […]
          ^^^^^^

So maybe it was not a typo.  Is “sparse” in this context a part of 
compiler/language developer jargon, or a repeated typo (perhaps produced by 
the autocorrect feature of a word processor which did not know “parse”)?  If 
it is jargon, was does it mean (“string parse”?), and what exactly does it 
refer to?

As “sparse” is a proper English word (an adjective) with another meaning,
I was not successful finding it as a developer jargon term by Web search and 
in common online dictionaries and encyclopaedia (e.g. Wiktionary, FOLDOC, 
Merriam–Webster’s, Oxford Dictionary of English, Wikipedia).  It is not 
contained in the Jargon Lexicon’s glossary 
<http://www.catb.org/~esr/jargon/html/go01.html> either.

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | <http://PointedEars.de/es-matrix>
<https://github.com/PointedEars> | <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | Please do not cc me./Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#39965

On Wednesday, April 14, 2021 at 4:10:32 PM UTC-5, Thomas 'PointedEars' Lahn wrote:
> Thomas 'PointedEars' Lahn wrote: 

> > | So the first thing that happens is the JavaScript source code goes into 
> > | the JavaScript [engine’s] parser, which then takes that code and turns
> The original reads “JavaScript engine sparser”. I assumed that it is a 
> typo. But: 
> 
> > […]
> > | running the JavaScript already, which is great. It’s like all we have to
> > | do is sparse it and then generate some bytecode in the interpreter, […] 
> ^^^^^^ 
> 
> So maybe it was not a typo. Is “sparse” in this context a part of 
> compiler/language developer jargon, or a repeated typo (perhaps produced by 
> the autocorrect feature of a word processor which did not know “parse”)? If 
> it is jargon, was does it mean (“string parse”?), and what exactly does it 
> refer to? 

It seems like a typo to me. A quick glance over my compiler texts say nothing on this.

[toc] | [prev] | [next] | [standalone]

#39964

On Wednesday, April 14, 2021 at 11:00:26 AM UTC-5, Thomas 'PointedEars' Lahn wrote:
> This should clarify your misconception: 
> 
> <https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey/Internals/Bytecodes> 

Yes, I'm aware as mentioned in my last response. I don't think we disagree. What the modern "JIT"s do is different than what the original interpreters were accomplishing. As mentioned in Brendan's original post on TraceMonkey they enabled the ability to dynamically go from the interpreted byte code to more low-level forms including machine code with direct register access.

<https://brendaneich.com/2008/08/tracemonkey-javascript-lightspeed/>

> See also: 
> 
> <https://softwareengineeringdaily.com/2018/10/03/javascript-and-the-inner-workings-of-your-browser/#:~:text=The%20JavaScript%20engine%20is%20the,MacOS%2C%20Windows%2C%20or%20Linux.> 
> 
> | [00:03:39] JM: Mathias Bynens, you are a software engineer at Google 
> | working on developer advocacy on the V8 team. Welcome to Software 
> | Engineering Daily. 
> | 
> | […] 
> | 
> | Give me a high-level perspective for the steps that are happening as this 
> | webpage with some various forms of JavaScript opens up. 
> | 
> | [00:04:26] MB: […] 
> | 
> | So the first thing that happens is the JavaScript source code goes into 
> | the JavaScript [engine’s] parser, which then takes that code and turns 
> | into an object-based representation, which we call an abstract syntax tree 
> | or an AST. Armed with AST, we can do some transformations on the code, do 
> | some [inaudible 00:05:06] here and there, but mainly the reason to have 
> | this AST is so that we can feed it into the first phase of execution, 
> | which is the interpreter. 
> | 
> | So our interpreter in V8, it’s called Ignition. This interpreter generates 
> ^^^^^^^^^^^^^^^^^^^^^ 
> | bytecode, which then runs in the interpreter. At that point we’re actually 
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 
> 
> Since this is actually *compilation* (conversion of human-readable source 
> code to machine-readable code), that part of the “interpreter” is actually 
> technically a _compiler_. 

A "compiler" does not execute code, its role is to perform translation. You can represent these with Tombstone diagrams:

<https://en.wikipedia.org/wiki/Tombstone_diagram>

If the target is machine-code it can be executed by a process.

An "interpreter" is a language processor that operates directly on the source language and inputs to generate outputs. These can be represented with I-Diagrams

<https://3.bp.blogspot.com/-wS9tQZmRGTA/VAiQuxJqSHI/AAAAAAAAE4E/LyVRjB4qNqo/s1600/7.png>

> And since the machine-readable code is not “interpreted“ by the CPU 
> firmware, but by a software, the "machine" that executes/“interprets” it is 
> called a *virtual machine*. 

JITs are an example of a hybrid model. The comment above is consistent with what is described in the Dragon Book on page 2 or 3.

> [...]
> | That’s why while we’re running the bytecode in the interpreter, JavaScript 
> | engines – Well, V8 does this, but all JavaScript engines basically do 
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 
> | this. […]. 
> `---- 

Even the first implementation of JavaScript used bytecode but Brendan states earlier in the thread that a VM was not part of it:

<https://twitter.com/BrendanEich/status/1047985952428195841>

> JIT-compilation of source code to bytecode to be executed by a virtual 
> machine is nothing unusual for so-called "interpreted languages". For 
> example, the same happens with Perl and Python code since time immemorial. 
>
> Unfortunately, there is a lot of confusion about this (on the Nets).

I think you and I are using the term "JIT" a little different. I was not including the source -> bytecode generation + interpretation as part of it. I was only including what happens next with that bytecode.

What's the most appropriate definition? I don't know.

[toc] | [prev] | [next] | [standalone]

#39966

Michael Haufe (TNO) wrote:

> On Wednesday, April 14, 2021 at 11:00:26 AM UTC-5, Thomas 'PointedEars'
> Lahn wrote:
>> This should clarify your misconception:
>> 
>> <https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey/Internals/Bytecodes>
> 
> Yes, I'm aware as mentioned in my last response. I don't think we
> disagree.

I think we do.  You still appear to think that “JIT” is something new.
It isn’t:

> What the modern "JIT"s do is different than what the original
> interpreters were accomplishing. As mentioned in Brendan's original post
> on TraceMonkey they enabled the ability to dynamically go from the
> interpreted byte code to more low-level forms including machine code with
> direct register access.

As I already said, this has happened *from the beginning*, since the very 
first version of SpiderMonkey in Netscape Navigator.  TraceMonkey only 
*improves* that.

>> Since this is actually *compilation* (conversion of human-readable source
>> code to machine-readable code), that part of the “interpreter” is
>> actually technically a _compiler_.
> 
> A "compiler" does not execute code, its role is to perform translation.

You don’t say.  Will you *please* learn to read more carefully? :-(

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | <http://PointedEars.de/es-matrix>
<https://github.com/PointedEars> | <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | Please do not cc me./Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#39981

Thomas 'PointedEars' Lahn wrote:
> Michael Haufe (TNO) wrote: 
> 
> [ ... ]You still appear to think that “JIT” is something new. 
> It isn’t:

>> What the modern "JIT"s do is different than what the original 
>> interpreters were accomplishing. As mentioned in Brendan's original post 
>> on TraceMonkey they enabled the ability to dynamically go from the 
>> interpreted byte code to more low-level forms including machine code with 
>> direct register access.

> As I already said, this has happened *from the beginning*, since the very 
> first version of SpiderMonkey in Netscape Navigator. TraceMonkey only 
> *improves* that.

Do you have any evidence of this?  I strongly remember TraceMonkey being 
the first JIT JS compiler, and the Brendan Eich article already mentioned
[1] and an Ars Technica one from 2008 [2] seem to confirm this, although 
it's not entirely explicit.

The question is whether before TraceMonkey any engines had Just-in-Time
compilation, meaning that using runtime performance numbers they would
hot-swap more performant low-level snippets in place of the current
running ones.  As far as I can tell, until 2008's TraceMonkey, all engines
used only Ahead-of-Time compilation techniques.

The MDN article on bytecode [3] does not offer anything new here.  That
the engine generates bytecode is certainly not news to a programming
languages enthusiast like Michael Haufe.  The question is when JIT 
compilation came to the engines.  And if there's any evidence that it
was available before TraceMonkey, I'd be very interested in seeing it.

  -- Scott



  [1]: https://brendaneich.com/2008/08/tracemonkey-javascript-lightspeed/
  [2]: https://arstechnica.com/information-technology/2008/08/firefox-to-get-massive-javascript-performance-boost/
  [3]: https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey/Internals/Bytecodes

[toc] | [prev] | [next] | [standalone]

#39963

On Wednesday, April 14, 2021 at 10:31:44 AM UTC-5, Thomas 'PointedEars' Lahn wrote:
> Michael Haufe (TNO) wrote: 
> 
> > On Tuesday, April 13, 2021 at 7:20:42 PM UTC-5, Thomas 'PointedEars' Lahn 
> > wrote: 
> >> Michael Haufe (TNO) wrote: 
> >> 
> >> > Modern JavaScript engines use JIT compilation. 
> >> AFAIK, they always did. What is new with “modern JavaScript engines”, IOW 
> >> Google V8 (JavaScript), is only that the source code is compiled to 
> >> native machine code instead of bytecode for a virtual machine. 
> > 
> > Afraid not. They were all interpreters 
> > 
> > - Firefox 3.1 was the first browser to introduce a JIT in version 3.1 
> > called TraceMonkey [1] -
> No, certainly not. The wording “a new kind of Just-In-Time (JIT) compiler” 
> does not imply that previous script engines interpreted source code.

I wasn't implying that the source-code itself is directly interpreted, there can be and and often are intermediate representations that are interpreted instead such as a form of bytecode [1]. Working directly on the original AST can be more complicated than more simplified forms.

[1] <https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey/Internals/Bytecodes>

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.javascript

csiph-web