Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jan 31 2019 22:42
    rhuanjl synchronize #5885
  • Jan 31 2019 22:39
    MikeHolman synchronize #5923
  • Jan 31 2019 22:28
    MikeHolman synchronize #5923
  • Jan 31 2019 19:48
    MikeHolman synchronize #5923
  • Jan 31 2019 19:03
    penzn synchronize #5903
  • Jan 31 2019 17:15
    penzn synchronize #5903
  • Jan 30 2019 22:33
    wyrichte opened #5927
  • Jan 30 2019 22:33

    wyrichte on ADO_test

    Update ChakraCoreStatic.cpp (compare)

  • Jan 30 2019 22:32
    wyrichte closed #5916
  • Jan 30 2019 20:20
    MikeHolman synchronize #5923
  • Jan 30 2019 19:56
    MikeHolman synchronize #5923
  • Jan 30 2019 19:53
    MikeHolman synchronize #5923
  • Jan 30 2019 19:35

    wyrichte on Test-PR-webhook---don't-merge

    Update ChakraCoreStatic.cpp (compare)

  • Jan 30 2019 19:35
    wyrichte synchronize #5916
  • Jan 30 2019 19:07
    wyrichte synchronize #5925
  • Jan 30 2019 18:54

    wyrichte on Test-PR-webhook---don't-merge

    Update ChakraCoreStatic.cpp (compare)

  • Jan 30 2019 18:54
    wyrichte synchronize #5916
  • Jan 30 2019 18:12
    wyrichte closed #5926
  • Jan 30 2019 18:12
    wyrichte opened #5926
  • Jan 30 2019 01:43
    wyrichte synchronize #5925
Jai Verma
@jaiverma
@MSLaguana @Penguinwizzard thanks!
Bruce Pascoe
@fatcerberus
Quick question: I want to implement a function SSj.assert which if the assertion fails, instantly causes a breakpoint if the debugger is attached. If I call JsDiagRequestAsyncBreak from a JsNativeFunction callback, will it break as soon as that callback returns or can more JS code run in the meantime?
Bruce Pascoe
@fatcerberus
Is it normal that functions created using new Function()have worse runtime performance (by a factor of, it seems, ~3-4x) than an equivalent function defined in the source code? I know eval'd code is slower because it needs to add extra instructions into the bytecode to capture completion values but I wasn't expecting new Function() to be slower too
Jimmy Thomson
@MSLaguana

Probably depends on the function? I just did

var y  = 0
function foo() {
    var x = 1
    var z = y + x
    return z
}

var bar = new Function([], `var x = 1
    var z = y + x
    return z`);

foo();
bar();

and looked at the bytecode, and foo and bar were identical. Are you doing more complex things with "arguments" or "super" or anything?

Bruce Pascoe
@fatcerberus
Huh, weird. I was writing a lodash-style query library and came up with the idea to compile the query to a JS for-loop. I found that I got better performance if I wrote out the jitted query to a CommonJS module and require'd it vs. passing the source code to new Function()
No fancy closures or arguments or anything, just a basic JS function with a for loop in it
Jimmy Thomson
@MSLaguana
Were you doing a lot of new function calls? One thing different between native parsing and parsing from a JS string would be the encoding; we always parse utf8, and so if text comes in as utf16 (e.g. a JS string) there's a reencoding step
but that wouldn't be the perf of the function, that'd be the perf of compiling the function
Bruce Pascoe
@fatcerberus
No, the performance test was for creating a function once and calling it tens or hundreds of thousands of times
Jimmy Thomson
@MSLaguana
But I guess that would happen anyway, when writing the output file
hmm
Bruce Pascoe
@fatcerberus
I'm aware that that the initial function parsing and compilation would be a massive performance hit
Jimmy Thomson
@MSLaguana
I'd be curious to see how the bytecode differs between the two cases, but if you have a nontrivial amount of code that's not so fun to look at
I suppose one other thing is that new Function'd code is treated in the same way as eval, as dynamic code, while code passed as a script file is treated differently, it may be that the jit treats them differently.
Bruce Pascoe
@fatcerberus

Basically if I have a query that looks like

from(array).where(n => n % 2 === 0).select(n => n * 8).reduce((a, n) => a + n, 0);

that gets "jitted" to a function which is called to actually run the query

((array, filter0, map1, reducer, acc) => {
    for (let i = 0, len = array.length; i < len; ++i) {
        value = array[i];
        if (!filter0(value)) continue;
        value = map1(value);
        acc = reducer(acc, value);
    }
    return acc;
})
The jitted functions are cached so they can be reused whenever the same combination and order of query operators is seen
If I write that function out to a module and require it in, it's fast. Passing the same exact source code to new Function is slower by a factor of 3-4
As a workaround for now I implemented that query-compilation solution directly in the host (miniSphere) and now my from() queries are super fast :)
Jimmy Thomson
@MSLaguana
I just tried using that exact function, and I still get identical bytecode for both the direct-in-sourcecode version and the new function'd one. I suspect the difference comes via the JIT then, which may have different heuristics for dynamic functions
Bruce Pascoe
@fatcerberus
Funny thing is It’s even slower if I use eval to create the function, as though it never gets jitted at all in that case
Jimmy Thomson
@MSLaguana
The eval version does have different bytecode
Bruce Pascoe
@fatcerberus
I know eval code has subtle differences in runtime semantics so that doesn’t surprise me as much
Bruce Pascoe
@fatcerberus
But no problem in the end; I implemented my evil trick directly in the host which isn't actually a problem since the goal was to use self-hosted JS to add a feature to my API :smile:
(Didn't want the array iteration to be done on the native side since that would be a performance sinkhole)
Jimmy Thomson
@MSLaguana
We only support dynamic linking for ChakraCore on windows at this point; Some people have tried statically linking and it can work, but there are some gotchas. We support both static and dynamic linking on Linux and OSX
Bruce Pascoe
@fatcerberus

Following up on the query compiler system I discussed above, I've implemented it and now my built-in from() beats everyone else's functional libraries by a comfortable margin :smile:

const arr = /* 100K random floats between 0-1000 */;
from(arr)
        .where(n => n < 500)
        .take(100)
        .select(n => Math.floor(n))
        .plus("rando string")
        .shuffle()
        .count(it => typeof it);

Benchmarking results:

 event                 count  time (us)   % run  avg (us)    % avg |
--------------------------------------------------------------------
 Underscore _.chain()  1,001  2,398,028  93.7 %     2,395   95.3 % |
 Lodash _.chain()      1,001     43,649   1.7 %        43    1.7 % |
 from.js 1.0           1,001     38,226   1.5 %        38    1.5 % |
 Lazy.js Lazy()        1,001     21,433   0.8 %        21    0.9 % |
 from() (mS 5.3+)      1,001     15,326   0.6 %        15    0.6 % |
Bruce Pascoe
@fatcerberus
image.png
What would cause MSVC not to be able to find the headers and/or .lib when using the NuGet package?
I've tried everything but can't get it to work. I don't want to keep committing CC binaries to my repo :frowning:
Jimmy Thomson
@MSLaguana
dumb question; has it downloaded the chakracore nuget package?
Bruce Pascoe
@fatcerberus
I completely blew away the packages/ directory and let it re-fetch everything and still no dice
Just checked that it exists in packages/ to make sure, and it does
At one point while fumbling around I got it to find the header... but then it didn't link the .lib so I still couldn't build
Jimmy Thomson
@MSLaguana
Have you specified that your different projects have a dependency on the nuget package?
e.g. is it in the references of your projects?
Bruce Pascoe
@fatcerberus
How do I check?
Jimmy Thomson
@MSLaguana
expand the References node
Bruce Pascoe
@fatcerberus
When I installed it I told it to install for both miniSphere and Cell, for some reason it says it's installed for SSj too even though that program doesn't depend on it (note the version field in the NuGet pane)
Nothing listed under References at all... which is weird because I also depend on Allegro and that finds the headers and links just fine
image.png
No option to add a CC reference...
My packages.config looks like this if it helps
<?xml version="1.0" encoding="utf-8"?>
<packages>
  <package id="Allegro" version="5.2.4.0" targetFramework="native" />
  <package id="AllegroDeps" version="1.7.0.0" targetFramework="native" />
  <package id="Microsoft.ChakraCore.vc140" version="1.11.3" targetFramework="native" developmentDependency="true" />
</packages>
Jimmy Thomson
@MSLaguana
Unfortunately I'm not particularly experienced with consuming nuget packages for c++… and I can't find a lot of documentation either
Bruce Pascoe
@fatcerberus
Honestly I think there's something wonky with the Allegro packages where they screw up the config and prevent other packages from working, I've had issues adding other dependencies in the past
Jimmy Thomson
@MSLaguana
Maybe try explicitly adding to your include paths to include packages/<whatever the chakracore folder is>, and similarly for the library path?
Bruce Pascoe
@fatcerberus
Well, that worked (along with adding ChakraCore.lib to the list of libs to link in), I kind of figured NuGet was supposed to deal with all that automatically though (it usually does)...
Jimmy Thomson
@MSLaguana
I would have hoped so, but perhaps the .net nuget packages have additional metadata that native ones don't? Or that the one we publish doesn't? To be honest, the nuget packages that we publish are purely for people outside our team, so we have been reactive rather than proactive about it. If you happen to know of a better way to package things, we'll probably make the change :)
Bruce Pascoe
@fatcerberus
I would, but I'd like to know for sure that something is wrong with the CC packages first and it's not a bad interaction with the Allegro ones... don't want to fix the thing that isn't broken :)
It's possible NuGet doesn't like my project setup too... I have the .sln + all .*proj files in the same directory and MSVC generally seems to prefer one .vcxproj per directory
Bruce Pascoe
@fatcerberus
This debugger behavior is convenient but I'm not 100% convinced it isn't a bug