EVMMAX Implementers Call #3

Transcript

welcome to the evm max implementers call number three uh and to start off can we get some updates uh maybe from first I barely can hear you K from from who first the update oh sorry yeah you're going to a little bit choppy um I guess radic I think I can I can give some update uh so basically uh I've been working

last um um last couple of days on uh on some examples on with evm Max and uh I prepared uh prepared uh the example with um poso implementation in evm Max I can sh I just sharing it in the in the chat this is just a PR to evm one which uh implements poson hash uh using evm Max up codes uh with the vectorized and non-vectorized version uh of this and yeah so there are some statistics basically uh but I think the main uh the main

um the main thing I would like to I would like to present is that uh it's possible to implement this hash with a quite efficient way uh with evm Max and uh assuming of course uh some cost model very simple cost model that every mul every addition and every multiplication is just even if this in this vectorized version is just a uh I believe one and and two gas and everything everything is um mentioned in the in the pr uh we can implement this Posen hush like below like the cost the cost below the

5,000 gas Coast uh and uh yeah so I think it's good if everybody would be able for the next couple of days to review this and and read go go through this and uh give me some feedback on this yeah uh so there is a there are benchmarks not only not which not only calculate the gas cost of the of this uh of this uh implementation but also also the gas rate for for this implementation so so it's kind we can see that we have a lot of still a lot of space to to lower the gas cost for for part of the part of the

instructions and even try to go below 3,000 gas per one hush uh I I think that's my rough estimation now uh you can also see at the bottom you can also see at the bottom the the number of op codes and the op codes histograms used for different cases uh yeah uh so yeah that's that's one thing I also recently started working on the implementation of mod precompile with the with the evm max using some implementation of the evm max up code support in your language so you so solidity intermediate

representation and uh yeah and but I haven't finished yet I have some results already but uh but uh I would like to wait until with the presentation wait until until I will have something more um more generally I would say and uh and something which I would like to also have a feedback on yeah this is a this is great uh could you say what was the CPU time difference between the simd version and the non simd version it's a it's not exactly the the simd version is a vectorized version but without any usage of uh of the of

the SD instruction uh processor processor of instruction yeah so but it helps a lot with the it helps a little with the code size of course because we can have a lower code smaller code size but also we uh we also can save uh uh some time on Switching context between the evm and the and the and the and the instruction instruction uh computation yeah because for vectorized version especially for matrix multiplication we can we we just do one uh like free free multiplication at at once without going back to the to the evm context yeah so

that somehow also helps the the the CPU time you have I believe Pavo correct me if I'm wrong because they are I'm not very familiar with the evm one benchmarks but uh but the time the CPO time you can see in the in the First Column of this uh of this uh table in the pr in the pr and the gas rate of course in the in the last one with gas used and of course what's also important in this PR I also assume that uh we somehow introduced uh introduced already um gas repricing for pushup codes uh and even with this with this so

I lower all the push up codes instruction cost to one gas and even for this uh with this modification we have like uh 200 million gas per second now the the the the the gas rate for this and yeah like quickly Computing from the from the uh from the log from the benchmarks it's like 10% faster in CPU time uh with the comment what radic said it's it's not strictly any optimized underneath it just saves you The Interpreter Loop uh time and uh yeah mostly you

don't go outside of the instruction execution very often yeah and and this example of the poson hush is the example taken from uh from chance uh implementation in solidity and uh thisam example works on uh uh input of two fields which two two two values which each of them is 256 bits uh yeah so so so not as a next step I would like also to implement something like with this for the smaller field and probably for this uh for this case it would be much it would have much

more sense to to use the SD uh yeah I agree um yeah and it' also be interesting to see the speed difference between the smaller field and um I guess this was b254 um yeah I'm yeah it's pretty exciting I'm pretty excited to see the difference between the small field non simd and the small field s0 there were sort of estimates that we can sort of reduce the time by like X but I'm still dubious I'm yeah pretty curious to see what that comes out to you yeah and uh also also what's worth

uh mentioning is that for this case we uh we we need like we we we waste not waste okay that's we waste like 30% of the time uh of the gas cost basically not I I haven't measured time for this exact part but but at least from the from the gas cost uh we was like a 30% of gas off for for constant initializations so for this for this for this hash so uh it means that uh if we will have a like a higher um higher level interface for this like for example it will not take only the it will not be the typical hash function

but for example uh for example it will be just a function implemented and which which implements uh which implements just a proof verification so it will it will it will it will um run this constant initialization only once and just calculate the I don't know like 3 to 32 hashes or 6 16 hashes at once without reinitialization of the constants so so probably it will it will it will amortise quite well and uh we should also have much better amortised result of the of the of the of the of the gas cost of of this proof verification so but yes that's another I

would like to to to to to prepare a use case for okay uh do we have a way to do that right now so we initialize the constants like once and then no uh okay I see okay no no no we don't have we don't have uh that's that's that's the question is if the question is if it will be really needed uh so so the answer is if you want to have uh because I assume that evm Max will be just a tool and everybody will be able to implement uh Implement their version of the functionality they need uh and uh and if they if someone will need the proof verification probably this uh this this constant initialization will not be a

problem but if someone would like to have a only hash function used by others uh this 30% of the gas probably will make uh a difference for them but yeah that's not sure but uh we have to decide maybe later uh if it's really worth uh researching on how to how to initialize these constants U better than it's now because uh yeah yeah yeah that makes sense I think it's great that you sort of pulled it out so we can always know what the exact percentage of initialization cost is to the total cost yeah I I will also I will also prepare

some uh CPU time benchmarks for this constant initialization because the gas cost you know it it depends on the how how well the gas is defined the gas cost is defined for in this case for for push instructions and and for for this data copy version for for the data copy basically up code how how how how it's close to the to the real CPU CPU time and uh if it's overpriced probably it will if it it will if it's strongly overpriced probably probably the the the the the cost of initialization in regarding CPU times will be much much much lower so yeah but not sure about it

at all so I will check it okay I see and do you think that we need to repic other things because I think you said that the ad and M were priced at one and two gas yeah for for in this case yeah so but and and for this vectorized I I haven't introduced the the gas model Jared prepared in the in the EIP uh I just used the the the the model from non non vectorized version so basically just a the the the the cost of the ve gas cost of the vectorized version is just the cost of the sum of the all um single instruction in the in the in the vectorize in the vector vector

so uh but but I think it's I wouldn't I wouldn't put too much attention to to the gas cost I would I would focus on the on the real CPU time and uh in the in time we can we can Define uh or use any any gas wle which is uh which which is which reflects the CPU cost um well and I haven't checked how how exactly the the the gas cost model is now Define in this Jared's EIP but I used only the the the the the definition of the of the op codes yeah that makes sense I guess uh one thing that might come up is that if

we don't have something like fractional gas then uh it's unclear how we're going to price this in in like a fair or SL competitive way um if you just can't get below one so one option that I think has been floated before is to take to do fractional gas for the uh each operation in the like so you have a vectorized invocation and however many operation arithmetic operations you do you charge a the cost model for the uh the each each arithmetic sub operation

charges a fractional gas and then you would like round up to an integer value I I think that's been like somewhat floated but I I don't know that that was also just an idea I had um but I yeah I think that that is probably something to explore down the line if uh as uh imple the this as the implement with smaller Fields is explored um I just have one question is the

uh is so the so the EV so the the vectorized version should be compatible with EIP 6690 other than gas costs um is it is there um Standalone uh evm bite codes for these available I'd be curious to see how it performs in G yeah uh so so yeah it's it's exactly exactly compatible with the CIP except uh except the the gas model and the bite code I I believe it's available in the pr uh if you look at the one

moment um I believe in okay I I will send you I will send you the link to great but yeah so yeah ah yeah sorry that's even it's even easier uh I just because I I've been doing this like couple weeks ago and already forgot where exactly it is but yeah yeah so I will I will send you yeah cool um two other questions one um where I took a I just started glancing at the PR but what does the overhead from push come from is that from storing the like constants that you're using yeah exactly

so so so for this non dat copy version We I just use the the basically uh pushing all the values to the stack and then uh then transfer it into the to the evm memory and then to uh and then to to evm Max context as far as yeah exactly how Okay cool so we can effectively consider those to be not I mean uh like in a product in in an imple the implementation could embed these in a data section uh yeah yeah there is memory without the need to push yeah

exactly there is a version also with the data data uh data copy uh of code which which doesn't require pushes but uh the cost and the cost of course regarding the gas cost is of course much better uh it's like uh I tell you it's like about uh 100 1,700 is for for push version and about one 1,300 is for for data copy version so when when the total when the total gas cost is like like 42,000 so yeah okay um there are four different versions of the bite code and

they are they are linked in the in the pr comment okay do you have um I would be uh I guess I would be curious if there's a rough idea of what the added overhead would be if because I'm assuming like we're this is unrolling um unrolling Club yeah yeah yeah yeah um have you done any like napkin calculations or or just rough calculations of what we what the added overhead might be if we were to

like not unroll this at all yeah yeah yeah so so I haven't done it I haven't done it yet but uh because so so basically for POS has it was quite easy to implement this as I did with just unroll unrolled Loop and rolling Loop but uh but of course there is there is another another exercise I need to do is to implement this with uh with this uh um U version of uh supporting evm Max up codes uh because uh and and try to Benchmark this and and measure the gas of course but uh from uh so but but first I need because now I'm using this

U version for for implementation this Expo promile which is much more complicated regarding all the all the regarding the control flow of the of this of this PR compile and uh and that's why I decided to use to make it in U not in the in the in the Rite code but uh but but what's worth noticing that this fuel version at least for now uh doesn't is is based on the in in support in solidity is based on the uh first version of eof supporting solidity which has implemented none of the none of the none of the regular optimization which is uh which is done on on the on

the on the on the assembly level so so so so probably the code will be will be not very efficient okay yeah great great work looks awesome yeah thanks Ric uh are there any other updates um yeah I have something that I was I was kind of reviewing our like evm

Max like code for a BN curve uh because we kind of started using this as a implementation of the pre-compile to some level and uh and uh and we switched from uh so to compute the inversion of the of the element in the field uh we used the adchain that uh implements the exponent um and we we uh we did experiment to switch to uh to Elian algorithm and uh and that gives us like five times Improvement in performance in this area

um um none of these like either adchain so ad chain is the best we can have but the the Montgomery multiplication underneath it's not um fully optimized and kind of the same story is with thean algorithm so it's not really like fair comparison because we didn't nailed any of these to the like the the the optimal level but still I think five 5x Improvement is is significant enough that I started considering adding this as a instruction to to VM Max um not sure what how you feel about it but definitely on the like

pre-compile implementation make a difference and yeah and we were able to actually um finally uh pass the the previous implementation we had from some external Library uh in terms of performance of these pre Compass oh and the 5x wasn't in evm Max was it wasn't using evm Max well it's it's kind of so we have like evm Max so we have a like C++ uh module that implements EV Max in a sense the API is kind of the same so

you you define a modulus and you have three operations addition subtraction and multiplication so it's kind of mimics the evm Max instruction design and this is also used to implement evm Max instructions but uh we can use that uh on like native level as a kind of API and so it's like mostly some of the precompilers we have are implemented this way uh but to be strict with the with the evm max model we couldn't we didn't there was no like conversion instruction let's say and we used

adchain because it felt more compatible with future EV Max Evolution but uh yeah obviously we can switch to elium algorithm internally without modifying modifying evm Max but it seems it's very beneficial to have it as a separate instruction actually yeah and also also from my experience with with xbot uh there is also a case for xbot where where where calculation of the inversion in the in the power of two field in this case is uh is needed and uh and implementation of this uh this

inversion in evm Max using using uh um using this this this fuel is kind of kind of difficult basically it's difficult and uh and would be very very very beneficial and and convenient to have this as a separate separate instruction especially that the algori for for inversion uh for power of two fields and uh and uh and OD field is well defined yeah yeah I think it makes sense I mean if you're doing sort of anything to do with elliptic curves you're probably going to want to use inversion

and probably square root at some point so adding the inversion in as an instruction makes sense and if we're not using addition chains it means that you can actually implement it as a efficient procedure because addition chains you sort you need to know what the exponent is beforehand but if you're using ukian algorithm it's just a generic uh you can pass in the modulus at a runtime so yeah I I I think it'd be a good idea to have an inversion uh specific up codes there unless only one that disagrees yeah it also shrinks the

kilobyte of cod into three bytes what did you say is that from 14 kilobytes it's no it's like adchain has around 300 instructions right so you replace this 300 instructions which is around one 1,000 bytes into like single instruction so it also massively saves the code size right all right yeah thanks for the update uh yeah if no one has any opinions against the

inversion up code I think we can just move forward and adding it okay cool uh are there any other updates cool um I guess we can look at what we mentioned last week uh so confirming the evm gas number and the wall clock time for Poseidon uh so yeah this is done by radc uh Implement and implementing and comparing the Legacy solidity version of Poseidon hash with the evm Max B code version um so this is also done by radic and I think the last

thing that chance is not here was to investigate uh simd comparisons using avx2 for small fields and BN 54 for Poseidon uh radic I think you said you're probably going to pick that up uh yeah yeah I think I will I will be able to do it for the next call assuming that it's uh in a month from now okay cool and uh yeah I'm not sure does C++ have good simd does it have a good simd API I've never used uh no idea actually at the moment but probably it has but uh but so we can just use okay I probably it has but uh

not sure how efficient it will be because uh I'm working on the on the Apple silicon so processor so so not sure how how exactly it will look here but in case it will not be possible to measure it uh in um in the in the correct way I will try to use different different machine okay I see okay cool that's sounds good um so we can carry that task uh forward to the next uh meeting um was there anything else you wanted to uh sort of put on your task list R yeah I I will also be pushing this this uh X mode promile and we'll try to

prepare some similar report for for for it uh as I did for for the poson for the next call I will also maybe if if nobody is against I will try also to extend the the the EIP with the inversion instruction I will push the pr and uh and yeah that's I think that's all for for for this couple of weeks okay that makes sense and would the I guess the inversion op code the simd version would allow you to invert uh multiple things uh in parallel is that correct or is it

yeah yeah that's that's how I implemented this already in uh in in evm one but only for for the for the power roof two uh modulus okay nice nice cool um is there anyone else who wants to sort of mention what they'll be doing for um before the next meeting or or something or any questions um I just wanted to ask quickly like do people have um opinions over proposing evm Max for like a specific Fork like maybe pushing for um

Amsterdam um I mean from nethermind side as well like we don't really have any updates um and we haven't really started working on implementing it but you know if we had maybe a clearer timeline of like if it was going to be included soon then maybe we could start working on it uh radic what do you what do you think uh so so B basically we we talked internally in ipsilon regarding the timeline I think the the the the fork after fusaka so I believe it's Amsterdam uh it's would be great to to have it introduced there uh and I think it's pH uh but of course we need to we need to

work a little bit on the EIP and uh and prepare the the the the the version so to let the clients Implement give the feedback get got the feedback from got the feedback from everybody so maybe the the the retreat also will be some how um will s allows allow also discuss it with the with the IRG team and and photographers from material but um but yeah so so so definitely I think Amsterdam is it's it's it's would be it's a good um good time to to introduce it yes after youf okay thank

you yeah I think one strong data point that would be compelling to at least maybe the like rollups and people like this is what is the sort of concrete performance we get with the once we have simd like what is the lower Bound for this and then we can compare against whatever they're using right now I believe most are probably using Poseidon uh so if we can say something like uh with simd Poseidon gets you 10x improvement over whatever you're doing this saves you I don't know 100,000 gas or whatever I think this is like a very strong like way to sort of uh put the uh improvements in

perspective yeah regarding this there is some discussion or some some some opinion from scroll under the vitalic vitalik's tweet I I just shared in the in the in the in the chat P Pavo found it yesterday uh so they they are very I would say maybe not very but very they have very negative opinion regarding posum uh regarding the the efficiency of this has function but uh I haven't I haven't checked anything what exactly implementation they used if they used their own implementation of they just they took something from uh from existing libraries but um uh but yeah so so so so we should also

take it into consideration definitely right I can I can speak to them to see what they were using um I guess this post is about uh migrating ethereum State try to posidon uh which is a sort of a stronger post ridon than just doing it inside of a evm like a contract for example um because in a contract there's like yeah a lot of people use it because it's more efficient in these ZK circuits uh so I think it might be a more nuanced argument for them but I can definitely check uh what they were using and what they think about

sort of using it just in just for like verifying proofs for example I would also like to to to have some base of uh of most important and most uh most popular algorithm used in in by the ZK and l2s uh so it will be good um good so so just to use it to to to implement other use cases using KVM Max and maybe use it as a as a as a good selling points uh of the of this of this

proposal right yeah I can definitely reach out to them and ask like what uh what algorithms are you currently using apart from Poseidon and or at least What fields are you using with Poseidon as well uh what is the cost what would you like to see reduced and uh yeah we can just take that take that list back uh were there any other questions or I have kind of related thing um so let's say like evm Max end up in in evm um so how difficult is it to implement

it in some ZK circuit let's say like it's it has like some natural modules I I assume right so well this operation like modules operation is kind of natural but like is it difficult to switch to something else or is um I think it's definitely not as nice as having a fixed modulus like b254 um but as far as I know most ZK uh proving systems have this thing called Big num or big int uh so it's definitely not nicer than having a fixed uh modulus but I don't

think it's like super difficult either uh especially if I guess they were doing especially if we had something like xod before but is it like um for example some kind of like Montgomery algorithm multiplication right or if you have two different primes right um the one that I saw being used before was using the Chinese remainder fing but this was by Aztec I'd have to double check what people are using now I that was as far as I know sort of the state of the arc maybe it could have changed within the last couple of

months um it definitely wasn't Montgomery though um but I don't think it matters that much because the Montgomery uh the internals of what's happening with ad mod and M mod is not exposed uh so I don't think it yeah I don't think it matters too much okay I yeah maybe there's ways to optimize it in ZK since you know the modulus of the contracts

beforehand uh but I I'd have to think about it I'm not sure okay thanks for the answer I guess one question I also had was whether So the plan is to replace xod with this as well is that correct yeah so so maybe not just replace but I would like to uh I would like to have another another case and it was also somehow related to the gas repricing or xot repricing precompile discussion uh and I proposed because I implemented the poson has and I proposed also that I can check how it could be uh

how it could be implemented ITV Max regarding the gas cost and maybe all the discussion regarding uh regarding the the xot repricing will be uh we we can wait with this change and just just to release the the the implementation as a as a e as a eifi evi implementation of X mode here uh in in the evm max but yeah so we'll see but this is just another another and and this algorithm looks like much more complicated than than poson hush so I also would like to would have liked to uh to see um how convenient it is to to

implement this and I have already a couple of additional additional already comments uh but I will I will present it later when I will have some more comprehensive report on this yeah yeah mostly we trying to find some examples outside of elliptic curves uh that seems to be a bit more difficult to implement in E Max so posidon hash was kind of interesting because it has a big array of constants that you need to Hash in and this is not straightforward to do in evm Max I mean it's definitely different that you would do in Native software um

and yeah x x mode is also very interesting because you get the modulus from from the user input which is nothing we have with elliptic [Music] curves right that makes sense um is there any other questions uh in terms of like do we want to replace of I don't know uh it's if you have something that it's like good good implementation maybe

there was some idea that we could replace pre compar with biteco at some point but uh it's for for me it's hard to hard to say how how serious this is yeah I guess my thought was that this does introduce uh uh like I guess some complexities to the clients right I guess they'd have to compile um like the pre-compile into evm Max and now they have a evm Max compiled contract in their repository or is it somewhat different like how would the how would

it look well the the like the idea is just to add some hard work to just dump a bite code at the address and the bite code will do like more or less what the pre-compile was doing or like maybe exactly identically uh it's I mean that was at least idea to replace the identi pre compile which is kind of trivial and you can write a bite code that does exactly the same thing that the precompile does and U yeah so that's that's definitely can be done uh it's question is it worth the like

effort um yeah what are the gains out of it what are the kind of problems and uh that's something we are thinking about at least to have a prototypes of evm implementations of pre compiles but I think until we have prototypes of pre compiles to the level that covers most of most of them or like significant amount of I I wouldn't really consider it seriously because I mean it's a lot of kind of questions related like if you replace half of the precompile is it was

it worth it or or not like how does it help or I guess the ideal solution would be to replace all of them and and that's kind of cleanups the evm design very much but besides this it's yeah and also I think I don't know I think we like in general we weren't super great about cleaning up cleaning up the design of ethereum in general we we rather add new things instead of improving existing uh so it's hard to tell like what people will say like what is the top priority

like next years and maybe clean up of evm will not be on the list yeah I'd definitely be interested to know the positives of doing this um I heard it before but I sort of sidelined it just because it seems I mean precompilers have the nice ux where you can sort of update the uh underlying library and it just gets faster and it's like not a thing that you need to coordinate between different um uh clients where whereas I guess with the bite code it might not be the ca I don't know it might not be maybe there's a way to do

it um one nice thing uh just another point one nice thing is that it might be POS possible to replace the underlying implementations of the pre compiles with just like the API being used for evm Max that might be one thing that could be done and then it doesn't actually break any client any it doesn't need like client synchronization yeah I mean if it's it's some way if we replace a PR compile with a bite code a bite code become comes kind of a spec of the precompile so assuming it's kind of it

defines the same spec that before the clients are kind of free to bypass it at least right this is this is the case already happening with the system contracts they're not like strictly computational intensive but to my to my knowledge uh some clients they prefer like not to execute evm just do whatever the contract would do with given input so it's kind of like native implementation of the semantic of a contract but the code is there and if someone takes it and kind of ignore it it will behave the same uh I also know like like for example ZK sync

implemented some of the pre- compiles in evm because they prefer that to to get the like evm compatibility by sacrificing efficiency but at least they didn't have to create another ZK circuit specific to some specifically for some pre-compile so they just implemented that in in solidity and gives the same results right so at least having a spec that is evm bite code I think has some benefits yeah actually that's a good point uh in that you wouldn't need the pre- compiles for everything the evm Max uh upcode can be can replace uh then

by yeah yeah I think definitely we should have a conversation on the pros and cons of this uh to see if like if if it's worth it especially with things like ZK circuits and how they're affected as well yeah so like like final note from M would be we kind of use the existing pre compiles at least they're related to uh to to final Fields uh or like modulus arithmetic is our kind of Benchmark for evm Max uh usability right if we can Implement that and it's it doesn't look so bad um and it's kind of perform like in some

relation to the native I think that's good sign that the design is is capable of uh yeah accumulating this this use case yeah yeah I agree definitely um are there any other questions um I I have a quick question uh I it's quite I guess a basic one about the spec but I'm just trying to understand like what exactly is the connection between evm Max and simd cuz I mean they're always kind of grouped

together but I see there's a separate EIP for simd right so would it make sense to have one without the other or like why they always grouped together um yeah I haven't clicked on the uh EIP yet I had to switch to mobile uh but I'm guessing it defines simd operations uh like probably as op codes whereas the evm max um API just says we have a vector of things and the simd sort of semantics is sort of hidden behind this API of having a vector of things uh so I'm guessing the EIP 616 has like actual SD op codes

being exposed in the evm oh okay I think I understand this so sorry when you when we speaking about Poseidon and using simd that's because it's kind of be behind the API which allows you to use simd under the hood right right exactly um yeah if you have two vectors and you're just like element wise adding them you could just do that uh using simd under the hood uh yeah okay thank you makes sense uh your other question is does it make sense to have one without the other and uh I'm not actually

sure uh maybe people would want simd operations anyway it's not really clear to me um maybe rodc or I think Doo had a had a point on this no I have no opinion on this at all actually yeah you mean about uh this 616 yeah oh um I don't know uh yeah it's it might be interesting to reviewing but it's I think it's it's not really related to evm Max right so it's it's not a crossover of

the CD instructions in VM and evm Max instructions to that gives you the CD evm Max instructions so it was it is pretty old I don't know I mean I think you could extract some utility out of it but I think it's yeah it will be some amount of work too to do something useful with this yep cool um yeah I guess one other thing is um sort of figuring out what needs to be

what are the open questions that we have before we can even like ship this in Amsterdam it seems the simd uh uh sort of version of Poseidon is the only one I have at the top of my hand I have also one one one something something which can be also worth um uh worth considering is that um there are a lot of different use cases where this vectorized vectorized op codes are not very useful and um and of course there are a lot of cases where they are very useful

but but the question is if maybe we should have both like non vectorized and vectorized op codes for this and uh and uh and of course uh because it it will basically basically if we have non vectorized version we have a just op code with uh with three bytes of um uh of the immediate value immediate arguments but with vectorized we always need to have like seven immediate arguments which is four additional bites for each instructions each instruction and U and uh and something which which maybe we should we should also consider Maybe based on some more examples we we should prepare um if it's if it's worth

to have like a two different sets of of instruction for evm Max so non non vectorized and non vectorized ver um so I guess the way we would figure that out is to just look at what the different use cases are and see if there's any that yeah that really benefits from having non vectorized uh version like for example for xot I I I don't see any uh any any any any any any any part of the implementation where where it's beneficial to have this this vectorized uh version but yeah right that makes

sense I also have a question um I think we should go with ax 256 right for the simd implementation um or do we want to look at 512 uh I think we can't do 512 because that's uh sort of more esoteric uh 256 I don't have a strong opinion on the 128 is sort of the lowest it's sort of the is the lowest common denominator just because neon and um avx2 uh so I don't know what people have opinion uh what people

think right yeah good point is 2017 I don't know how widely adopted it is but I might be mistaken I can double check um but like for Max it's a neon which is like 128 I guess Ric you can maybe just uh check for 128 and 256 I guess the performance increase would just be linear so be another 2x but uh I'm not super sure yeah I I I will check you mean you mean using this this simd instru SD instructions yeah yeah yeah exactly yeah I I I I will check it but

definitely definitely I need to get a little bit deeper into this because I at the moment I have exactly no no no no idea how it exactly Works what I know how it works but what exactly what exactly uh integer size they accept and uh and where it can be useful so yeah yeah that makes sense I guess uh the plony Free Library they've uh sort of used uh simly quite extensively so that might be a good uh sort of inspiration they used it for Poseidon as well I believe can you provide some link or

yeah right uh was there any other questions people wanted to ask um okay cool I think we can just summarize so there is the in inversion op code uh that rodic's going to add uh then comparing uh the different simd uh versions uh comparing simd versus non simd for Poseidon um I can go and ask the l2s or the ZK rollups who are using solidity to

like verify their proofs like what algorithms they'd like to see uh getting reduced um there's Po's Point uh but I guess it's not super immediate about sorry uh replacing some of the pre compiles um with evm Max and yeah I have a point here to just discuss all the open questions for shipping just in Amsterdam is there anything else that I've missed cool okay cool uh yeah thanks for joining guys uh I'll see you in one month or I guess I'll see some of you

soon