Skip to content

[loader] Add fast methods for reading typed arrays - #794

Merged
dcodeIO merged 20 commits into
AssemblyScript:masterfrom
MaxGraey:improve-loader
Sep 2, 2019
Merged

[loader] Add fast methods for reading typed arrays#794
dcodeIO merged 20 commits into
AssemblyScript:masterfrom
MaxGraey:improve-loader

Conversation

@MaxGraey

@MaxGraey MaxGraey commented Aug 26, 2019

Copy link
Copy Markdown
Member

@MaxGraey
MaxGraey marked this pull request as ready for review August 27, 2019 11:39
@MaxGraey
MaxGraey requested a review from dcodeIO August 27, 2019 11:40

@jtenner jtenner left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks really good.

Comment thread lib/loader/index.js Outdated
@dcodeIO

dcodeIO commented Aug 27, 2019

Copy link
Copy Markdown
Member

Can you explain what's so slow about __getArrayView?

@MaxGraey

Copy link
Copy Markdown
Member Author

Can you explain what's so slow about __getArrayView?

Most slow method is __getArray which unnecessary for typed arrays. For typed arrays __getArrayView could be much simpler and faster. In this PR I try do this simplification

@MaxGraey

MaxGraey commented Aug 27, 2019

Copy link
Copy Markdown
Member Author

Just some interop bench results on sha256-as example which return Uint8Array:

using __getArray:

Sha256AS#hash x 164,524 ops/sec ±1.41% (87 runs sampled)

using __getArrayView:

Sha256AS#hash x 520,705 ops/sec ±0.63% (86 runs sampled)

using new __getUint8Array:

Sha256AS#hash x 656,971 ops/sec ±0.33% (91 runs sampled)

@dcodeIO

dcodeIO commented Aug 27, 2019

Copy link
Copy Markdown
Member

I see, thanks. However, I'm a bit concerned that this increases the loader's source by about 50%, and I wonder if there's maybe a way to make __getArrayView / __getArray perform better instead?

@MaxGraey

MaxGraey commented Aug 27, 2019

Copy link
Copy Markdown
Member Author

Most of people using babel / webpack / rollup / uglifyjs for browser which could three shaking and remove unused methods during build bundle. For node.js platform size of js is not big deal at all. Also we could build binding tool like wasm-bindgen which could remove unnecessary js code, do some inlining and generate js glue code/wrappers for exported wasm methods/classes automatically. I guess much bigger problem is interop speed currently

@dcodeIO

dcodeIO commented Aug 27, 2019

Copy link
Copy Markdown
Member

I agree that we should make this faster, yeah, just hoping that this can be accomplished in less code.

@MaxGraey

Copy link
Copy Markdown
Member Author

It will be great do similar stuffs for __allocArray and create set of __allocUint8Array ... __allocFloat64Array without retrieve rtti info. But for this we need preserve ids for typed arrays as I recently mentioned in slack.

@jtenner

jtenner commented Aug 27, 2019

Copy link
Copy Markdown
Contributor

If I might comment on the size problem.

Can't we have it the old way?

wasm.getTypedArray(TypedArrayConstructor, pointer)

@jtenner

jtenner commented Aug 27, 2019

Copy link
Copy Markdown
Contributor

Also, most of us don't mind slightly larger bundle sizes to trade off for speed. Maybe we could make a more performant loader with a larger size and have a smaller one for web bundles?

Comment thread lib/loader/index.js Outdated
@jtenner

jtenner commented Aug 27, 2019

Copy link
Copy Markdown
Contributor

Well for instance the loader could be way simplified in node.js environments at least. Could I submit a pull request for a node-loader?

For instance, Buffer.from(buffer).toString("utf16le", stringPointer, rtSize) works great for strings.

@MaxGraey MaxGraey changed the title [loader] Add fast read from memory methods for typed arrays [loader] Add fast methods for reading typed arrays Aug 27, 2019
@MaxGraey

Copy link
Copy Markdown
Member Author

@dcodeIO I leave complete get rid of rest cached U8 ... F64 values and mem checks for you and focused in this PR only on Typed arrays if you don't mind

Comment thread lib/loader/index.js
@MaxGraey
MaxGraey requested a review from dcodeIO August 29, 2019 11:22
@MaxGraey

Copy link
Copy Markdown
Member Author

Ok, I guess it's ready

@dcodeIO
dcodeIO merged commit b479950 into AssemblyScript:master Sep 2, 2019
@MaxGraey
MaxGraey deleted the improve-loader branch September 2, 2019 08:40
MaxGraey referenced this pull request in torch2424/as-bind Sep 8, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants