Turbofan + Ignition release plan && comms plan

@ZibbyKeaton

Hey All,

So now that 5.9 is stabilized and 6.0 is soon to be released we need to make a decision about which we would like to release. The options include:

Releasing with 5.9 in a semver-minor ASAP 🎉
Holding off until 6.0 ❤️

Once we decide which we are going to move forward with we will also need to co-ordinate with @ZibbyKeaton and the rest of the foundation comms team to make sure that we are properly getting the word out to our community.

This could include:

A blog post
Social Network Coverage
External media coverage

We should make sure that which ever path we choose above we leave enough time for the comms team to plan a release.

If people from @nodejs/ctc could chime in on preference for the version with the emoji above that would be greatly appreciated. If you have a potential path forward that was not mentioned please add it to the comments and we can adjust above.

If you think we have missed anything regarding the outbound communication related to the release please chime in

/cc @hackygolucky

Both approaches are good for me, as long as we ship one before mid-august. The plan should be to ship 6.0 asap, or 5.9 if that is not possible.

@MylesBorins

@MylesBorins I think similar to last time, it would be nice to write a detailed blog on the subject and we can post it on our Medium blog and share on social. I can also share with a few media folks that are generally interested in this. Happy to review the blog and write an outline too, if that would be helpful to you. In terms of timing, do you happen to know when this will be?

We are still trying to work out the timing. How much lead time do you need for a media push?

@MylesBorins

@MylesBorins I will likely push this out to the media day of. I wanted to get a sense of timing, so I can put it into our editorial calendar and if it's around NodeSummit, I would reach out to the media attending the conference to give them a heads up.

@nodejs/ctc based around the above. How do people feel about doing a push to land V8 5.9 next week so we can do it around Node Summit and get a media push? I've tagged this for ctc-agenda so we can discuss tomorrow.

Sounds good to me – I’ll update the 8.2.0 proposal in a bit and remove V8 5.9 from it, the plan here sounds good and I can see that having better communications around the introduction of TF+I will be a good idea.

@addaleax

I agree using the release where TF+I is enabled to generate awareness and to re-enforce the calls @addaleax has already been making asking for people to performance test and give us feedback is a good idea.

@vsemozhetbyt

I was asked by @vsemozhetbyt to provide a link to a performance issue I found between V8 5.8 and V8 6.1. Basically Typescript code targeting ES6 is 6x slower in my test than when targeting ES5. See my comment to nodejs issue 14220.

@winksaville

@winksaville from how I read that conversation, it seems the problem is resolved in V8 6.1. Can you please check if the same problem exists in 6.0 and 5.9?

Yes all is well with V8 6.1. Can you provide links to Node prebuilts with V8 5.9 and 6.0?

…

On Wed, Jul 19, 2017, 1:54 AM Matteo Collina ***@***.***> wrote: @winksaville <https://github.com/winksaville> from how I read that conversation, it seems the problem is resolved in V8 6.1. Can you please check if the same problem exists in 6.0 and 5.9? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#155 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA-hHMM42TmGXQIe0FMf80uYyd2McPv5ks5sPcQrgaJpZM4OaZ8b> .

@winksaville

@winksaville
V8 5.9: last nightly

Unfortunately, our first distributed V8-canary build already has V8 6.1. I hope somebody can link you to V8 6.0 Node.js build (I have an old canary one for Windows x64, let me know if it can be of any help).

I'll try the 5.9 build tomorrow but don't use Node on Windows. Anyone can fork my code if desired. Actually, if 6.1 is what's going to ship why worry about 5.9 or 6.0?

…

On Wed, Jul 19, 2017, 10:25 AM Vse Mozhet Byt ***@***.***> wrote: @winksaville <https://github.com/winksaville> V8 5.9: last nightly <https://nodejs.org/download/nightly/v9.0.0-nightly20170718f406a7ebae/> Unfortunately, our first distributed V8-canary <https://nodejs.org/download/v8-canary/> build already has V8 6.1. I hope somebody can link you to V8 6.0 Node.js build (I have an old canary one for Windows x64, let me know if it can be of any help). — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#155 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA-hHJi1Cy8O3DmUz7uTe6BaEJwz7fwfks5sPjwagaJpZM4OaZ8b> .

Actually, this is still uncertain what V8 version will be shipped with Node.js 8 LTS (see, for example, nodejs/node#14384 (comment)).

If we're only a week out from having a stable 6.0, let's go with 6.0 but let's definitely work on getting it out by mid august. I'm cutting the 9.x working branch in early september and would like to get things resolved before then.

You can post it to the Foundation medium page, just add a link to the original piece at the beginning.

We should probably fix the errata (by @jkummerow and @hashseed) before republishing though.

We already published, but I can easily go in and make the edits, please just let me know what they are asap.

Refs: nodejs/node#14528

@ZibbyKeaton

@ZibbyKeaton

When V8 was first built the optimizing JIT Compiler was dubbed: Crankshaft.
How "small integers" are tested. Specifically:
```
function sum (base, max) {
  var total = 0

  for (var i = base; i < max; i++) {
    total += i
  }
}
// all big
sum(65536, 131071)
```
This function counts from 0, to 65536, to 65536 + 65537 = 131073, eventually going over the range of small int (2 ** 31 - 1 = 2147483647). However, unlike "all big" as the test claims to be, it is still going from small (0) to big.

After my changes, the benchmark would then need to be re-run across the different V8 versions, but locally (Node.js v8.2.1 with V8 5.8):
```
sum small x 21,061 ops/sec ±1.68% (88 runs sampled)
from small to big x 14,684 ops/sec ±0.50% (91 runs sampled)
all big x 9,515 ops/sec ±0.46% (90 runs sampled)
```
On Node.js v9.0.0-v8-canary20170724c045f1f8dc with V8 6.2.4:
```
sum small x 16,438 ops/sec ±1.40% (86 runs sampled)
from small to big x 14,751 ops/sec ±0.67% (90 runs sampled)
all big x 11,993 ops/sec ±5.12% (84 runs sampled)
```
Note how there is a large drop-off from "from small to big" to "all big" on both versions, unlike the overlapping lines in the graph currently.

The background info in the blog post will also need to be updated:

In the case of integers (that is, when we specify a number in JS without a decimal), V8 assumes that all numbers are 32bit - until they aren’t. This seems like a fair choice, since in many cases a number is within the ~~0-65535~~-2147483648-2147483647 range. If a JavaScript (whole) number exceeds ~~65535~~2147483647 the JIT Compiler has to dynamically alter the underlying type for the number to ~~64bit~~a double (or: a double-precision floating point number) - this may also have potential knock on effects with regards to other optimizations.

Object creation benchmarks don't actually create the objects because TF optimized it away. Again, with my changes, the benchmark results are more useful:

Node.js v8.2.1 with V8 5.8:

literal x 28,455,810 ops/sec ±1.19% (83 runs sampled)
class x 21,993,317 ops/sec ±1.13% (86 runs sampled)
constructor x 28,093,899 ops/sec ±0.73% (82 runs sampled)

Node.js v9.0.0-v8-canary20170724c045f1f8dc with V8 6.2.4:

literal x 31,861,977 ops/sec ±0.88% (86 runs sampled)
class x 32,265,246 ops/sec ±0.65% (90 runs sampled)
constructor x 32,120,661 ops/sec ±0.99% (87 runs sampled)

Polymorphic benchmark results are unreproducible on V8's d8 CLI, so there might be something weirder going on. A note saying this could be attached to that specific section as it's not as easily fixable, like the following (but feel free to change it):

Edit: We have been informed by the V8 team that the results for this specific benchmark are not reliably reproducible. The results and the subsequent analysis should therefore be taken as reference only, not at face value.

/cc @davidmarkclements @mcollina Would it be possible for you to re-run the updated benchmarks (davidmarkclements/v8-perf#6)?

Re https://www.nearform.com/blog/node-js-is-getting-a-new-v8-with-turbofan/:
Besides the notes in the comments, there are some draft fragments in the text:

(Maybe a sentence about the BigInt proposal should be included here?)

Grabbing all of an objects values (properties?)

Re "ITERATING OVER OBJECTS" plot: the orange line and the red line are blended so it seems the red line is missed. Maybe it is worth to be mentioned explicitly.

Re "CREATING OBJECTS": posible typo (of -> or):

less than half the speed of using an object literal of a constructor

Thanks everyone for reviewing! I don't think this issue is the right place for discussing those changes. Can you please open issues to the repo, so that we can easily reply and discuss each one individually?

We will address them asap.

So the plan for this is with 6.0 next week or the week after? Is that correct?

@Fishrock123

So the plan for this is with 6.0 next week or the week after? Is that correct?

@Fishrock123 My understanding is that we intend to release Node.js 8.3.0 this upcoming week with V8 6.0. @nodejs/release

I'm going to remove the ctc-agenda label from this since, as far as I know, no one is opposed to that plan. Feel free to re-add it if I'm wrong or if there is some other aspect that needs to be addressed at the meeting. @MylesBorins

@MylesBorins

@MylesBorins are you still planning to write a blog around this for Node.js Collection?

Since 8.3.0 landed with TF/I, I think this can be closed. Comment or re-open if I'm wrong. Thanks.

Navigation Menu

Repository navigation

Turbofan + Ignition release plan && comms plan #155

8 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Turbofan + Ignition release plan && comms plan #155

Description

Activity

mcollina commented on Jul 17, 2017

ZibbyKeaton commented on Jul 18, 2017

MylesBorins commented on Jul 18, 2017

ZibbyKeaton commented on Jul 18, 2017

MylesBorins commented on Jul 18, 2017

addaleax commented on Jul 18, 2017

mhdawson commented on Jul 18, 2017

winksaville commented on Jul 18, 2017

mcollina commented on Jul 19, 2017

winksaville commented on Jul 19, 2017

vsemozhetbyt commented on Jul 19, 2017

winksaville commented on Jul 20, 2017

vsemozhetbyt commented on Jul 20, 2017

jasnell commented on Jul 20, 2017

8 remaining items

mcollina commented on Jul 27, 2017

TimothyGu commented on Jul 28, 2017

ZibbyKeaton commented on Jul 28, 2017

vsemozhetbyt commented on Jul 28, 2017

TimothyGu commented on Jul 28, 2017

vsemozhetbyt commented on Jul 28, 2017

vsemozhetbyt commented on Jul 28, 2017

vsemozhetbyt commented on Jul 28, 2017

mcollina commented on Jul 28, 2017

Fishrock123 commented on Jul 28, 2017

Trott commented on Jul 29, 2017

ZibbyKeaton commented on Jul 31, 2017

Trott commented on Aug 13, 2017

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions