lil perp
lil perp
I'm also running into this issue
+1 to exposing CU consumption if we want users to request tighter CU limits
Can you elaborate on why higher CU limits is problematic? Will make it easier to brainstorm suggestions!
Also, if im reading it correctly, the banking stage thread first filters out tx based on max block cu limits and then tries to acquire the write lock for tx...
The scenario i'm imagining is that there are 10 tx with hot accounts at front of buffer with max cu request of 1.4m, they max out the cost tracker cus...
This is intended since it allows you to place an order and have it stay open at the end of the tx. We could potentially introduce a fill or kill...
this makes it so you make the tx fail if there is no fill: https://github.com/drift-labs/protocol-v2/pull/1218
the square root fn as is right now looks like it's about 2-5x faster, which is important for drift ui and why we have the recursive implementation any ideas on...
solana uses 64 bit architecture, i'm guessing you're using 128 bit architecture. if you're using apple, i'd use x86_64 toolchain
thanks for the feedback! we can do a better job here, will take a look at these tools for the pr you shared, a contributor review it and gave approval...