NNevermind I realized that I can just cast the pointer to an integer and make it work
NFrom what I've seen, it was easier to pass the typed array as a parameter and let the native code do the allocation directly into the typed array
Nnow I have a new question. How do I know my FFI call is utilising Fast API?
NWith
Takes on average.
NWhile
Takes on average.
Takes on average.
NNcopypasted from
Nreturning instead of is twice as fast btw
Nno idea
Nan ACTUAL no-op takes like
N4ns
N
Nwith
Nand returntype when defining symbols
NIg this is actually going through fast api considering my older no-op calls (from a few weeks ago) were taking around
APointers are supported as return types, as are 64 bit integers. Under the hood it works so that an extra buffer argument is passed into the call, our trampoline writes the pointer / integer into the buffer, and then on JS side we check (for positive integers) if the number has no upper bits in which case we return the lower 32 bits as a number. Otherwise, we take a BigInt out of the buffer and check if it can be safely represented as a number. If it can, we return a number. Else, the BigInt.
Nso uhh
Ncan I make an FFI call explicitly use the slow API?
Nfor comparison
AYes, mark it with . Fast API will throw if you try to call into JS so we need a way to mark functions that may call back and use slow calls for those.
Nyea thanks that works
Ncan see a 10x difference between the fast call and the slow call
AYou can also force a deopt to slow by using eg. null or Uint32Array for a buffer type, or null for pointer etc.
N
N(that 3.61ns was a fluke)
Nor wait
N
Nbecomes slower when called after a dummy bench?
ABench has some issues with the very first bench call.
Nbtw, could something here cause the call to use the ops layer instead of the fast api?
AIf either of the first two parameters is not a Uint8Array then it'll deopt to the ops layer.
A(Well, not quite ops layer but similar.)
Ntheyre both technically Uint8Arrays
NNthese two variables are the first two params
AOkay, that should be fine. Though do note that it's been seen elsewhere that doing can be surprisingly slow. If you can move it up out of the loop / bench it will probably help a lot.
Nactually now that I see it,
same params but I removed the function body from the rust function
same params but I removed the function body from the rust function
Nwithout removing function body from rust function
Nokay seems some loops were taking too much time