[v8-users] Why for loop will become faster if divided in two loop?

[brn]

Hey.

I found curios things in d8 version 5.9.0(git hash 
b086856f0a15374286529bb56668f19bd18c4965).
This is my code samples

/**
 * @fileoverview
 * @author Taketoshi Aono
 */

const Benchmark = require('benchmark');
const suite = new Benchmark.Suite;

const anyType1 = 'a';
const anyType2 = 2;
const anyType3 = /klfjakl/;
const anyType4 = {a:2,b:3};
const anyType5 = {f:2,d:4};
const anyType6 = Date.now();

const anyMap1 = {a:2,b:3};
const anyMap2 = {f:2,d:4};
const anyMap3 = {e:2,f:4};
const anyMap4 = {h:2,i:4};
const anyMap5 = {j:2,k:4};
const anyMap6 = {l:2,m:4};

const sameType1 = 1;
const sameType2 = 2;
const sameType3 = 3;
const sameType4 = 4;
const sameType5 = 5;
const sameType6 = 6;


function heavy() {
  let ret = 0;
  for (let i = 0; i < 100; i++) {
let a = Date.now()
ret += a;
  }
  return ret;
}

// add tests
suite
  .add('one loop', () => {
for (let i = 0; i < 1; i++) {
  heavy();
  heavy();
}
  })
  .add('divide loop', () => {
for (let i = 0; i < 1; i++) {
  heavy();
}
for (let i = 0; i < 1; i++) {
  heavy();
}
  })
  .on('cycle', function(event) {
console.log(String(event.target));
  })
  .on('complete', function() {
console.log('Fastest is ' + this.filter('fastest').map('name'));
  })
  .run({ 'async': true });



And if you run in this code nodejs -v7.2.1.
Divide loop is faster than one loop.

I think it's strange, so I check generated code.

ONE LOOP

optimization_id = 2
source_position = 0
kind = OPTIMIZED_FUNCTION
stack_slots = 22
compiler = turbofan
Instructions (size = 1445)
0x3f4a6c304800 0  55 push rbp
0x3f4a6c304801 1  4889e5 REX.W movq rbp,rsp
0x3f4a6c304804 4  56 push rsi
0x3f4a6c304805 5  57 push rdi
0x3f4a6c304806 6  48bac200 REX.W movq rdx,0xc2
0x3f4a6c30481010  e84bf9dfff call 0x3f4a6c104160  (Abort);; 
code: BUILTIN
0x3f4a6c30481515  cc int3l
0x3f4a6c30481616  4883ec30   REX.W subq rsp,0x30
0x3f4a6c30481a1a  48897580   REX.W movq [rbp-0x80],rsi
0x3f4a6c30481e1e  488b55a8   REX.W movq rdx,[rbp-0x58]
0x3f4a6c30482222  488b45b8   REX.W movq rax,[rbp-0x48]
0x3f4a6c30482626  488b5dc0   REX.W movq rbx,[rbp-0x40]
0x3f4a6c30482a2a  660f1f44   nop
0x3f4a6c30483030  4533c0 xorl r8,r8
0x3f4a6c30483333  48bf1027 REX.W movq rdi,0x2710
0x3f4a6c30483d3d  48b90100 REX.W movq rcx,0x1
0x3f4a6c30484747  493ba5900c REX.W cmpq rsp,[r13+0xc90]
0x3f4a6c30484e4e  0f86ae02   jna 0x3f4a6c304b02  <+0x302>
0x3f4a6c30485454  a801   test al,0x1
0x3f4a6c30485656  0f85a004   jnz 0x3f4a6c304cfc  <+0x4fc>
0x3f4a6c30485c5c  483bc8 REX.W cmpq rcx,rax
0x3f4a6c30485f5f  0f842c00   jz 0x3f4a6c304891  <+0x91>
0x3f4a6c30486565  f6c301 testb rbx,0x1
0x3f4a6c30486868  0f859304   jnz 0x3f4a6c304d01  <+0x501>
0x3f4a6c30486e6e  488bf3 REX.W movq rsi,rbx
0x3f4a6c30487171  48c1ee20   REX.W shrq rsi, 32
0x3f4a6c30487575  83eeff subl rsi,0xff
0x3f4a6c30487878  0f808804   jo 0x3f4a6c304d06  <+0x506>
0x3f4a6c30487e7e  48c1e620   REX.W shlq rsi, 32
0x3f4a6c30488282  48898570ff REX.W movq [rbp-0x90],rax
0x3f4a6c30488989  4c8bce REX.W movq r9,rsi
0x3f4a6c30488c8c  e90c00 jmp 0x3f4a6c30489d  <+0x9d>
0x3f4a6c30489191  33c0   xorl rax,rax
0x3f4a6c30489393  4c8bcb REX.W movq r9,rbx
0x3f4a6c30489696  48898570ff REX.W movq [rbp-0x90],rax
0x3f4a6c30489d9d  41f6c101   testb r9,0x1
0x3f4a6c3048a1a1  0f856404   jnz 0x3f4a6c304d0b  <+0x50b>
0x3f4a6c3048a7a7  4c898d78ff REX.W movq [rbp-0x88],r9
0x3f4a6c3048aeae  4c3bcf REX.W cmpq r9,rdi
0x3f4a6c3048b1b1  0f8d4102   jge 0x3f4a6c304af8  <+0x2f8>
0x3f4a6c3048b7b7  be0100 movl rsi,0x1
0x3f4a6c3048bcbc  498b45a0   REX.W movq rax,[r13-0x60]
0x3f4a6c3048c0c0  ba0100 movl rdx,0x1
0x3f4a6c3048c5c5  83fe01 cmpl rsi,0x1
0x3f4a6c3048c8c8  0f851b02   jnz 0x3f4a6c304ae9  <+0x2e9>
0x3f4a6c3048cece  493ba5900c REX.W cmpq rsp,[r13+0xc90]
0x3f4a6c3048d5d5  0f867c02   jna 0x3f4a6c304b57  <+0x357>
0x3f4a6c3048dbdb  498bc0 REX.W movq rax,r8
0x3f4a6c3048dede  488bda REX.W movq rbx,rdx
0x3f4a6c3048e1e1  49ba REX.W movq r10,0x0
0x3f4a6c3048ebeb  4c895588   REX.W movq [rbp-0x78],r10
0x3f4a6c3048efef  90 nop
0x3f4a6c3048f0f0  c5f957c0   vxorpd xmm0,xmm0,xmm0
0x3f4a6c3048f4f4  49bc709289080100 REX.W movq r12,0x108899270;; 
external reference (Runtime::DateCurrentTime)
0x3f4a6c3048fefe  49bbd13bb8122d32 REX.W movq r11,0x322d12b83bd1   
 ;; object: 0x322d12b83bd1 
0x3f4a6c304908   108  493ba5900c REX.W cmpq rsp,[r13+0xc90]

Re: [v8-users] Re: Linking V8 to app on Windows

[DánielN]

This bug is fixed now: 
https://bugs.chromium.org/p/v8/issues/detail?id=6158==ID%20Type%20Status%20Priority%20Owner%20Summary%20HW%20OS%20Component%20Stars=1000

On Wednesday, 1 March 2017 18:16:49 UTC, DánielN wrote:
>
> I would like to add some more information to this topic. It could be 
> useful to someone later. The previous version of V8 I am using is about a 
> year old now and I would like to debug javascript in the embedded vm that 
> is why I need the latest version.
> I struggled a lot to make it work. I did not managed to create the 
> necessary static libs. First I linked the obj files. It was a working but 
> ugly solution. Then I found this topic that led me to the "proper" solution.
>
> I had to have the static libs with statically linked runtime.
>
> Here are the steps that worked for me:
>
> download and unzip 
> https://storage.googleapis.com/chrome-infra/depot_tools.zip to a folder 
> (e.g. d:\Dev\v8-3\depot_tools)
> prepend (not append!) depot_tools to PATH:> 
> path=d:\Dev\v8-3\depot_tools;%PATH%
> > gclient
> > set DEPOT_TOOLS_WIN_TOOLCHAIN=0
> > fetch v8
> > cd v8
> (if the next step does not work reinstall Win SDK 10 (maybe just the 
> debugging tools from it suffices))
> > gn gen --args="is_debug=false is_component_build=false 
> v8_use_snapshot=true v8_use_external_startup_data=false 
> v8_static_library=true" --ide=vs out\Default
> > call "C:\Program Files (x86)\Microsoft Visual Studio 
> 14.0\VC\vcvarsall.bat" amd64
> > msbuild out\Default\all.sln /nologo /t:Build 
> /p:Configuration=GN,Platform=x64 /v:normal
>
> Three things to highlight
> 1. The "shard" feature seems to have disappeared. The v8_base.lib is 0.4G 
> in release.
> 2. v8_libsampler.lib, DbgHelp.lib and Shlwapi.lib should probably be 
> linked to the project to avoid unresolved external references
> 3. I had to change BUILD.gn to sort out several project failures caused by 
> the referenced but not created wasm_test_signatures.lib:
> v8_source_set("wasm_test_signatures") {
>   sources = [
> "test/common/wasm/test-signatures.cc", #this is new
> "test/common/wasm/test-signatures.h",
>   ]
>   configs = [
> ":external_config",
> ":internal_config_base",
>   ]
> }
>
> I also added a new file "test/common/wasm/test-signatures.cc". This file 
> is only one line, it includes test/common/wasm/test-signatures.h.
> After these changes gn gen generated the correct project file 
> (wasm_test_signatures.vcxproj) that created the missing 
> wasm_test_signatures.lib. (Interestingly "msbuild 
> out\Default2\obj\wasm_test_signatures.vcxproj  /nologo /t:Build 
> /p:Configuration=GN,Platform=x64 /v:normal" did not fail but it did not 
> create the lib, either)
>
> And finally this is how I link V8 to my project on Windows:
> #if defined(_WIN32)
> #//define V8_SHARD
> #define V8_SNAPSHOT
> #//define V8_EXTERNAL_SNAPSHOT
> #if defined(V8_SHARD)
> #pragma comment(lib, "v8_base_0.lib")
> #pragma comment(lib, "v8_base_1.lib")
> #pragma comment(lib, "v8_base_2.lib")
> #pragma comment(lib, "v8_base_3.lib")
> #else
> #pragma comment(lib, "v8_base.lib")
> #endif//V8_SHARD
> #pragma comment(lib, "v8_libbase.lib")
> #pragma comment(lib, "v8_libplatform.lib")
> #pragma comment(lib, "v8_libsampler.lib")
> #pragma comment(lib, "icui18n.lib")
> #pragma comment(lib, "icuuc.lib")
> #pragma comment(lib, "winmm.lib")
> #pragma comment(lib, "DbgHelp.lib")
> #pragma comment(lib, "Shlwapi.lib")
> #if defined(V8_SNAPSHOT)
> #if defined(V8_EXTERNAL_SNAPSHOT)
> #pragma comment(lib, "v8_external_snapshot.lib")
> #else
> #pragma comment(lib, "v8_snapshot.lib")
> #endif
> #else
> # pragma comment(lib, "v8_nosnapshot.lib")
> #endif//V8_SNAPSHOT
> #endif//_WIN32
>
>
> This is a the version I built: bfa425cc0841f17294e933e8d3611aad42deb2ee 
> (Tue Feb 28 07:31:08 2017 -0800)
>
> The problem with wasm_test_signatures.lib seems to be a bug. Could someone 
> please confirm and fix it?
>
> Is there a document that describes how to link V8 to projects? It can be 
> quite a daunting job to upgrade it from an older version.
>
> On Friday, 18 November 2016 17:22:55 UTC, Ivan P. wrote:
>>
>> Found solution. So just if someone needs- 
>> 1. update v8/gni/v8.gni, put static library 
>> template("v8_source_set") {
>>   static_library(target_name) {
>> 2. generate build files with gn
>> 3. Run ninja -j1 -C yourbuilddir d8
>> Build only d8 - this will build all necessary libs.  
>> Then pick yourbuilddir/obj/*.lib and following
>> yourbuilddir/icuuc.dll
>> yourbuilddir/icuuc.dll.lib
>> yourbuilddir/icuuc.dll.pdb
>> yourbuilddir/icui18n.dll
>> yourbuilddir/icui18n.dll.lib
>> yourbuilddir/icui18n.dll.pdb
>> yourbuilddir/icudtl.dat
>> Link with all libs from picked, except you need to select between 
>> v8_nosnaphshot.lib or v8_external_snapshot.lib depending on what you need.
>> Hoping 

Re: [v8-users] debugging protocol

[DánielN]

If I press F5 in Chrome nothing happens but this:
CDT: {"id":34,"method":"Page.reload","params":{"ignoreCache":false}}
V8: {"error":{"code":-32601,"message":"'Page.reload' wasn't found"},"id":34}

V8 does not seem to understand "Log.*", "Page.*", "Emulation.*", 
"Rendering.*", "DOM.*", "CSS.*", etc. messages though we could write logic 
to react accordingly to these kind of commands.
"Runtime.*", "Debugger.*" messages work when they are forwarded from CDT to 
V8.
For example:
CDT: {"id":6,"method":"Runtime.enable"}
V8: {"id":6,"result":{}}
...
CDT: 
{"id":25,"method":"Debugger.setBreakpointByUrl","params":{"lineNumber":0,"url":"1.js","columnNumber":0,"condition":""}}
V8: 
{"id":25,"result":{"breakpointId":"1.js:0:0","locations":[{"scriptId":"26","lineNumber":0,"columnNumber":0}]}}

It looks Chrome never closes the WS connection (except when the inspector 
tab itself is closed) and even the WS pings are sent.

In my application I do not have logic to close the WS connection (except 
when my app quits) and I do not have WS reconnect logic either.



On Tuesday, 4 April 2017 07:08:05 UTC+1, Zac Hansen wrote:
>
> do you have it working if you connect with chrome then refresh chrome that 
> it works?  
>
> When I reconnect to the same embedded v8 app, I get a slightly different 
> set of messages that don't properly set up the debugger the second time.
>
> Thanks.
>
>
> On Thursday, March 23, 2017 at 9:32:15 AM UTC-7, DánielN wrote:
>>
>> Eventually I managed to sort it out. It does not seem to have huge 
>> interest about it but I share it anyway, someone might find it useful.
>> Basically we have to create a web socket server along with our VM that we 
>> want to debug. Anything that comes through the ws connection (commands from 
>> CDT) has to be forwarded to the InspectorClient 
>> (v8_inspector::V8InspectorClient, 
>> v8_inspector::V8InspectorSession::dispatchProtocolMessage method) and 
>> anything (events and responses) that comes from the InspectorFrontend 
>> (v8_inspector::V8Inspector::Channel) has to be sent through the ws 
>> connection. We do not want to touch the JSON messages at all, no need for 
>> parsing. We just forward them to CDT/V8. The tricky bit is the 
>> runMessageLoopOnPause and quitMessageLoopOnPause methods. They have to be 
>> overridden. runMessageLoopOnPause should not return and has to handle 
>> messages until quitMessageLoopOnPause is called. That's it. In CDT we can 
>> see the call stack, scripts, we set break points, whatever. Launch your 
>> browser with --remote-debugging-port= then type 
>> http://localhost:/devtools/inspector.html?ws=localhost:2000 
>> (localhost:2000 where the ws server listens) and you can start debugging 
>> your v8 context.
>>
>> On Friday, 3 March 2017 09:41:44 UTC, DánielN wrote:
>>>
>>> I have just started exploring debugging. I am lifting code 
>>> (InspectorClient, InspectorFrontend) from d8 to my test project. I would 
>>> like to connect my embedded v8 VM to CDT and debug it. Does anyone have 
>>> some simple example that does that? It seems to me to be a long way and a 
>>> big learning curve from dismantling d8 code to connect to CDT.
>>> Any help would be very much appreciated.
>>>
>>> On Friday, 3 March 2017 09:21:43 UTC, Ben Noordhuis wrote:

 On Fri, Mar 3, 2017 at 10:10 AM, Rishi Kumar  
 wrote: 
 > Hi, 
 > 
 > I was reading and using the debugging protocol from this page 
 > https://github.com/v8/v8/wiki/Debugging-Protocol . Its looks like it 
 has 
 > been removed from the github wiki. I dont know how to get that link 
 page to 
 > complete my work. I need these protocol documentation which was clear 
 and 
 > proper in that page link. is anyone can help me to get that ? 

 This is the new API: 
 https://github.com/v8/v8/wiki/Debugging-over-the-V8-Inspector-API 

 The old JSON-based protocol was deprecated two or three years ago and 
 was removed recently. 

>>>

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [v8-users] v8 version: 4.6.2, appear "segment fault" when call the api "LowMemoryNotification"

[Jakob Kummerow]

Version 4.6.2 is just a daily snapshot that has never been officially
supported, and by now is severely outdated. Nobody knows or cares whether
it has bugs. You should use the tip of a supported branch, e.g. right now
branch-heads/5.7, see e.g.
https://gist.github.com/domenic/aca7774a5d94156bfcc1 for a detailed writeup.

Generally speaking, crashes during garbage collection can have any number
of reasons, including both V8 bugs and bugs in your embedding application.

As a side note: are you sure that triggering emergency GCs manually is what
you want? Usually it's best to just let the GC do its thing. A lot of
thought and effort is going into the internal heuristics for when to do how
much work, to ensure that you're getting a great tradeoff between short
pauses, high performance, and low memory consumption.


On Mon, Apr 10, 2017 at 11:39 AM, Ivan Y  wrote:

> Hi, here
>
> when I use the api "LowMemoryNotification", my program will appear
> "segment fault" at times, I just want to know whether this is a known bug
> in version 4.6.2.
>
> (1) call position in my program:
>
>
> 
>
>
> (2) the backtrace from coredump file
>
>
> 
>
>
>
> --
> --
> v8-users mailing list
> v8-users@googlegroups.com
> http://groups.google.com/group/v8-users
> ---
> You received this message because you are subscribed to the Google Groups
> "v8-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to v8-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[v8-users] v8 version: 4.6.2, appear "segment fault" when call the api "LowMemoryNotification"

[Ivan Y]

Hi, here

when I use the api "LowMemoryNotification", my program will appear "segment 
fault" at times, I just want to know whether this is a known bug in version 
4.6.2.

(1) call position in my program:




(2) the backtrace from coredump file





-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [v8-users] How to debug the v8 src code by exec `tools/run-tests.py --outdir out.gn/x64.debug`

[Jakob Kummerow]

There's no existing support for this. Pausing on breakpoints requires
running in a debugger, which run-tests.py doesn't implement.

As a workaround, you could put an UNREACHABLE() into the source where you'd
want to break and then run the test suite. run-tests.py will then print the
command line for any failing test(s), which you can use to run that test in
isolation within your debugger (after removing the UNREACHABLE() again).

Hope this helps,
Jakob

On Mon, Apr 10, 2017 at 10:31 AM, Early  wrote:

> Hi,I want to debug the v8 src code while runing the `tools/run-tests.py
> --outdir out.gn/x64.debug`.
> So, is there any way to help me to pause on a breakpoint which was set on
> a cc file in v8/src, when I run the `tools/run-tests.py --outdir
> out.gn/x64.debug`?
>
> --
> --
> v8-users mailing list
> v8-users@googlegroups.com
> http://groups.google.com/group/v8-users
> ---
> You received this message because you are subscribed to the Google Groups
> "v8-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to v8-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[v8-users] How to debug the v8 src code by exec `tools/run-tests.py --outdir out.gn/x64.debug`

[Early]

Hi,I want to debug the v8 src code while runing the `tools/run-tests.py 
--outdir out.gn/x64.debug`.
So, is there any way to help me to pause on a breakpoint which was set on a 
cc file in v8/src, when I run the `tools/run-tests.py --outdir 
out.gn/x64.debug`?

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.