Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Troubleshoot AssemblyScript performance #12

Closed
abrown opened this issue Apr 6, 2021 · 8 comments
Closed

Troubleshoot AssemblyScript performance #12

abrown opened this issue Apr 6, 2021 · 8 comments

Comments

@abrown
Copy link
Collaborator

abrown commented Apr 6, 2021

Why is the AssemblyScript example slower than the Rust version? There may be additional things on the Wasm side that could make the execution time faster. E.g., I noticed that loading the big weights files with readBytes seemed to take 20-25 seconds (a as-wasi issue?).

@MaxGraey
Copy link

MaxGraey commented Apr 6, 2021

sort may be a problem. Using Weak Heap Sorting algorithm isn't stable while ECMAScript currently specify Array#sort should be stable. That's why we currently temporary fallback to simple insertion sort O(N^2) for all references. It may be a problem for huge size of entries (> 1k)

@MaxGraey
Copy link

MaxGraey commented May 4, 2021

Also as-wasi uses push for read/readAll. Recently we fixed some huge perf regression which relate to buffer's growing for Array#push. So I recommend update to v0.18.31

@brianjjones
Copy link
Collaborator

@MaxGraey Thanks for the heads up, it does run several seconds faster with that fix.

@abrown abrown closed this as completed Jul 6, 2021
@MaxGraey
Copy link

MaxGraey commented Jul 7, 2021

sort may be a problem

this issue also will be fixed soon

@abrown
Copy link
Collaborator Author

abrown commented Jul 7, 2021

@MaxGraey, just wanted to say thanks for tracking this project and looking into these AssemblyScript issues. Let us know if you have any suggestions anywhere! (E.g., hope we're doing "the right thing" to get pointers here).

@MaxGraey
Copy link

MaxGraey commented Jul 7, 2021

(E.g., hope we're doing "the right thing" to get pointers here).

Arrays and TypedArrays have special property for point to started data called dataStart so you could use this:

// @ts-ignore: decorator
@inline 
function getArrayPtr<T>(data: T[]): usize {
    return data.dataStart;
}

// @ts-ignore: decorator
@inline 
function getTypedArrayPtr(data: ArrayBufferView): usize { // ArrayBufferView is base class for Uint8Array and etc
    return data.dataStart; // it also take into account data.byteOffset
}

@abrown
Copy link
Collaborator Author

abrown commented Jul 7, 2021

Good to know! I think had read somewhere (or deduced from AssemblyScript/assemblyscript#743) that it was an unstable, undocumented thing. But now I actually see it in the the docs so it looks like we can simplify a bit.

abrown added a commit to abrown/wasi-nn-bindings that referenced this issue Jul 7, 2021
As mentioned in
bytecodealliance#12 (comment),
it is acceptable to use the `dataStart` field.
abrown added a commit to abrown/wasi-nn-bindings that referenced this issue Jul 7, 2021
As mentioned in
bytecodealliance#12 (comment),
it is acceptable to use the `dataStart` field.
@MaxGraey
Copy link

@abrown 0.19.7 now contain new stable sorting algorithm. So this should be fixed

abrown added a commit that referenced this issue Jul 23, 2021
As mentioned in
#12 (comment),
it is acceptable to use the `dataStart` field.
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

No branches or pull requests

3 participants