OK I gave it a shot, but I know I did it wrong...:
void TypedSort(const FunctionCallbackInfo<Value>& args) {
Isolate* isolate = Isolate::GetCurrent();
HandleScope scope(isolate);
if (args.Length() < 1 || !args[0]->IsTypedArray()) {
isolate->ThrowException(
Exception::TypeError(
String::NewFromUtf8(isolate,
"First argument should be an array")));
return;
}
Handle<TypedArray> arr = Handle<Uint16Array>::Cast(args[0]);
int size = arr->Length();
double other_arr[size];
for (int i = 0; i < size; i++){
other_arr[i] = arr->Get(i)->NumberValue(); //presumably this should be
changed to work off the fact that this is a typed array... couldn't figure out
the right way of manipulating the api...
}
qsort(other_arr, size, sizeof(other_arr[0]), compare);
Handle<Array> res = Array::New(isolate, size);
for (int i = 0; i < size; ++i) {
res->Set(i, Number::New(isolate, other_arr[i]));
}
args.GetReturnValue().Set(res);
}
Updated to this ^^, probably doing something wrong cause I still get that
this is slower by most accounts.
I used benchmark js to call both initial and new functions (and compares to
js). Below are results:
C native sort x 252,557 ops/sec ±1.93% (70 runs sampled)
C native type sort x 130,923 ops/sec ±2.80% (67 runs sampled)
Javascript sort x 726,026 ops/sec ±1.37% (71 runs sampled)
Fastest: Javascript sort
Slowest: C native type sort
So it looks like this new implementation is marginally faster than previous
but still slower than js which leads me to believe that I'm doing it wrong.
The results here are consistent with what I'm getting when using the
'shameful' simplified approach to benchmarking using date.now():
Typed C time: 2 msec
----- Cost for sorting 1000 -------
JS time: 21 msec
C time: 23 msec
Typed C time: 23 msec
----- Cost for sorting 10000 -------
JS time: 148 msec
C time: 234 msec
Typed C time: 208 msec
----- Cost for sorting 100000 -------
JS time: 1594 msec
C time: 2406 msec
Typed C time: 2122 msec
Any tips/advice/insight? Is there are particular downside to running the
same operations 1000000 and doing a diff with date.now()? I hear its really
frowned upon but with differences in magnitude such as these I feel like
its safe to say C consistently underperforms JS in this circumstance with
my naive implementation, and unfortunately so does my specific use of Typed
Arrays using V8 as well. Any info would be great. Also there's a lot of
flaws in this for a number of reasons that i wont get into rn.
Thanks so much Ben and Jochen!
On Wednesday, October 26, 2016 at 4:02:45 AM UTC-4, Ben Noordhuis wrote:
>
> On Wed, Oct 26, 2016 at 3:42 AM, Samantha Krieger <[email protected]
> <javascript:>> wrote:
> > OK I see. My bad on that assumption.
> >
> > The truth is I actually wanted to write a native node module to do a lot
> of
> > manipulation of dynamic JS objects (from a few to many thousand
> properties
> > of varying types). I wrote this example as a test because I started
> noticing
> > the overhead of marshaling objects in C++ was higher than I expected.
> Are
> > there any v8 data structures that would make ^^ task reasonably faster
> in
> > C++? Or would pulling the objects into v8 using the API just be
> expensive?
> > If so, what is the ideal situation that would improve performance by
> > re-writing using v8? Fairly static types? That was the impression I got
> from
> > the few tutorials I found out there...
>
> Jochen mentioned typed arrays and that is really the best way to go if
> you have to shift a lot of data from JS to C++ land or vice versa.
> Node.js uses the same technique in many places.
>
--
--
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups
"v8-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
