EVMMAX Implementers Call #2

Transcript

[Music] Yeah. So, welcome to the second uh meeting for EVM Max. Um yeah, it's been a while since the first one. So, I guess we can get updates from folks who are working on um EVM Max probably did client teams to see if anything's moved along. Mhm.

Yeah. This is air from the Ethereum JS team. Um the JavaScript the arithmetic library with the field context is mostly complete. um pending uh a few of the uh Montgomery multiplication preset functions. Uh I got the first two completed, so the 64-bit and the 128 bit. And the rest are in the pipeline. Uh they should be done by the end of the week.

So, uh, regarding PESO, um, uh, I've I've got I haven't started yet and I've got, um, um, some had some performance and and Petra stuff to do. So, I'll I'm planning to start it uh, after uh, in February and I might have something to share for the the next sync.

Thank you. Uh Rada. Hi guys. Good to see you again. Uh so basically uh recently we we implemented version of 66 um 66 uh 9890 with the vectorzed form. I've just pushed the PR to the draft PR to the EVM EVM1 repo and yeah so it looks that some basic test unit test now pass and uh and uh we now based on this uh we will be working on uh on implementation of some more advanced algorithms probably I would try to start with uh with pad and hash and um yeah so so basically in this

PR the are uh arithmetic instructions and the operation instructions are implemented. The gas schedule is not updated. Yes, it's based on the uh on the previous version of this EAP. So now we have two PRs two draft PRs. Which one which one of them implements the old version without vectorized uh without without nonvectorized version or sequential or whatever we call it and the second one implements the vectorzed version. So we will be able now to try to at least compare the usability of this. Probably not not not in the in the in the state where we can compare some um some uh efficiency.

Okay. Yeah, that's very cool. This means that we can actually get accurate numbers for how long it takes to do like a Poseidon hash using SIMD. So I that's that's only the implementation of the instruction on the low level. It's still just implement just uh just um it's a it's a naive C++ implementation on the back end. Yeah. So, so I haven't used some uh uh some uh processor specific instructions for for this kind of uh operations.

Okay, I see. Yeah. So then it just uses the API for SIMD but in the back end it's using sequential operations. Yeah, exactly. Exactly. Okay, I see. Okay, that makes sense. stop now at all but uh but I would like first to check how it's useful to implement this uh this this Padon hash from the perspective of of the of the EVM bite code. Yeah. Okay. I see that makes sense. Cool. Thanks for the update. Um does anyone else have any updates?

Uh I can give a quick update. I did go ahead and implement or simulate an implementation of Poseidon on a couple of different fields and for a few bit a few different input widths. And one thing I noticed is the arithmetic reduction. It's roughly 5% more efficient, but there's another or is sorry, it's roughly 5x more efficient. But there's another reduction that we don't really emphasize in the EIP, which is getting rid of the stack cost. I I didn't even realize that all these operations were using immediates. Uh and that's another 5x reduction. So we do see actually about a 10x speed up on larger programs like um five input besidon for example. Um and so one note

I have about this is it would be good to rewrite the EIP a little bit or maybe write more supporting documents uh sort of emphasizing these two sides to it, the arithmetic and the stack reduction thing. Um could you elaborate? So what we're having here is we have a Poseidon implementation that's in JavaScript or something and then we have another Poseidon implementation using EVM Max and the EVM Max one is 5x more efficient. Is that correct?

Uh no I was comparing the Solidity Poseidon implementation to the EVM Max implementation. Okay. I see. Yeah. And so it's a direct comparison between between the most gas efficient current Poseidon on the blockchain versus what we could get with EVM Max. And it's just like simulated in JavaScript. Okay. So the the EVM Max one is 5x more efficient than the solidity one. 10x total. Okay. 10x more efficient. Mhm. So it's uh but it's uh uh it's already implemented this this this version in VM max. So this just uh some kind of estimation at the moment.

It's it's an estimation um but it's based on the actual assignment. Yeah. Okay. So so so so yeah. So I as a next step I would like just to just to take the poson um posed implementation in solidity and try to rewrite it to to to the EVM max. Um it depends how much how many steps I will need to do. um in between maybe it will be just uh possible to implement using our own internal API to generate the bite code for EVM max. uh in the worst case I would have to add this support for for EVM max up codes uh to solidity compiler hopefully not

yeah I think it makes sense to roll our own by code generator at least for now because the paradigm is very different than solidity or even ule because they don't really have like immediate operations for addition and multiplication Actually they do already some kind of immediates support for some kind of immediates but they are more related to the to the ef support uh I mean immediate arguments but yeah how how I didn't know that uh how how to how to exactly uh how how can look in uh in in Ule on U

level or solidity level. I have no idea at the moment. So probably it's it's it I I need to do first some first um uh some first attempt and see if it's really uh makes sense to do it in any of these any of those uh languages. Yeah, but I will try to bite code just direct bite code generation at at first. Thanks, John. Uh, did anyone else have any updates that they wanted to share um before moving to questions?

Okay, cool. Um, so I guess we can move to questions. Um, does anyone have any questions that they would like to ask? I have one. So is 6690 the only EIP in question? So are we only going to support vectorzed operations or is this in addition to non-vector operations? Reddit.

Yeah. So, so in my opinion uh we first need to need to check if it really gives us something uh which is worth to to to have this vector support. That's what we have that's why we have two different versions now. And I think it's a matter of time just and a matter of the discussion to to decide which way we want to go. Uh I personally not fully sure that we should go with vector at the moment but maybe it's a matter of of getting deeper into the the different uh use cases.

Uh Axic did you want to say something? Yeah, not not much more to add. Um, but generally I do feel like that the unless we get a confirmation that the the vectorized route is the the optimal one. Um, I think the main motivation with the vectorzation was that you could utilize uh vectorization within the CPU, but it that is limited to much lower width. So you couldn't it's limited to like 128 bits maybe 256 at best. uh if you want to vectorize in a CPU. Um and because of that, I feel like these should be like two different EIPs and two different like feature sets. Um but

what Radic said, I think makes a lot of sense. Getting a better feel to where it would be useful um would be a good first step, right? I guess that depends on who the end users are. Like if we imagine the end users are going to be uh implementing elliptic curves then we would have to assume that there's going to be some sort ofund or at least 256 bits uh modular arithmetic that needs to be done. Um but if we assume that it's like people who are going to want to implement starks then the sd operations would be pretty useful.

Yeah, I I just want to maybe that's that's a question we should we should ask what's the what's the real uh uh what's the real end user we are targeting here for this CIP and uh because I would like to uh avoid the situation when we are doing something uh apart from from the real use cases and from the end users who should have some um really valuable input to the the to the way how it's designed in the end. So so so but actually I think that some cooperation or maybe some even in person meeting with us and our R&G team or any other cryptographic team cryptographic

teams uh from Ethereum would be very beneficial. Okay, makes sense. Yeah, I guess we can sort of hash that out offline as to who the end users are and what they want because that does have a big uh it does have big ramifications on whether SMD is useful to all of them or to any of them. Um, were there any other questions?

Uh, chunks. Okay, this is sort of a followup to the last one. Uh, but I'm wondering from the perspective of the implementers, if we have a sequence of multiplications and it's not vectorzed, can you sort of statically analyze that at I guess runtime? um and then use SIMD SIM SIMD like opportunistically I guess is that possible or no I guess to clarify I'm just questioning how how far we can get without vectorization using like sequences of naive operations

I'm uh that's good question. So, uh I think that's it's from the top of my head just uh so we can we can try to to to implement this kind of a support on the also on the on the compiler or or any any language we are going to use on the compiler level just to to introduce this kind of optimization or we can go a little bit or we can introduce it a little bit later. So on the EVM level if it's possible or maybe I'm I'm saying nonsense now now but uh but that's also my idea that it should

be um should be somehow resolved this way that if it's possible you just use uh CIMD version if it's not possible or it's not uh it doesn't make sense you just go with the the regular one and this should be decided by the kind of a compiler optimization step I believe. But yeah, maybe this is something also to discuss later and to and get more into details before. Um, and I think Dano, we've spoke in the past and you said that it wouldn't be great to have this MD API and it just does sequential operations in the

background because it's uh I think did you say it was like a waste of option if anyone else wants to answer? Oh, it's 5:30. Could you start repeat that from the beginning again? It's way early morning. Right. So um we spoke in the past about using the SIMD API and in the background it's doing like sequential operations and then if we then later in the then later in the future we can upgrade to like uh using SIMD in the background. I think you said that this is not beneficial because it's wasting bite

code but I might be misremembering. Yeah, I don't recall talking about that particular bathroom. You might have been having a conversation with someone else, though. Oh, okay. From what I've observed, we have like these stride arguments and the count arguments in every invocation. And so it it should add uh like three bytes of overhead for every instruction. So yeah, there would be by code bloat. Yeah. Would these be immediate or stack based? I mean, there's different ways to deal with flow.

They're they're immediates. Um, but the the size of the contract just gets very large if you have like a long a program with many steps, right? Yeah. So, so basically for this new vectorized version, the the number of immediates rise from rises from from three to seven u and each immediate is one bite size. So, so yeah, it's it's it's a it's also we I think we should try to to to have this exactly that that's a good reason also to have these two versions and try to compare in the end how how um how much we can gain from from from having this this vectorzed version uh comparing

to how bigger the the bite has to be. Okay, that makes sense. So I guess um does anyone else have any questions? So rather than a concern about wasting bite code, but sounds like I am concerned that we're overloading EVMax or something that could be done more efficiently with a separate um SIMD instruction set because um there's going to be a big need for small integer SIMDs um for stuff like Falcon. Um so that's that's stuff to consider, but I think yeah, prototype would be the best way to

get the comparison. Um, so would that be a separate EIP that has um basically SIMD instructions? So it's a bit more low level. Yeah, I mean there's a really old one out there. Um, but I think before we start talking EIPs, I think we need to get better understanding of what we're going to get in the water for with lattice and quantum resistant before we commit to an SMD solution. Mhm. Okay, makes sense. Um, so I guess the questions we have right now, well, we know that without SIMD, the the EVM Max uh version is faster than the Solidity

version. And currently for the Prooseidon implementation that Chance has, it's 10X. Uh, was it Meren 31 that you used Chance? That was for both AltPN 128 and M31. Yeah. Okay. I see. Um we don't know what the speed up is if we used SIMD EVM Max versus Solidity. Um we conjecture that for alt BN uh for BN254 the SIMD won't be a great speed up but for smaller fields it will. Um, so that's one question that I'll write down

that it'd be great to answer. I guess I just want to interject. I was benchmarking gas costs, not speed. I don't know if those are the same. Oh, I see. Um, and the issue there is that maybe the gas cost is off. So, it's not actually 10x reduction. Maybe we've mis mis computed the gas cost for EVMX. Is that right? Um, I wasn't necessarily implying that. I just wanted to clarify that I didn't do do actual speed tests.

Okay. H Okay, let me write that down. But there is an EVM pricing working group that'll probably want this to come in at actual wall clock time. So, that is a a good notation that to let us know about. Okay. So confirm EVMX gas numbers plus uh wall clock time uh and also investigate the SIMD version. I think once we have proper SIMD numbers, we'll

be in a much better place to figure out if we can if we should do the SIMD API versus the regular API. Uh and I guess we want to also do this for alt bn uh for bn254 and also for some small field uh since we do conjecture that the small field will be a lot faster with sim. Um yep. Yeah. Um also uh my team was also investigating CIMD instructions and the availability of the of them in current hardware. I think um what's mostly

available is AVX2 which is 256 bit um and the 512bit ones were not so widely available. So I think we might also have to think about what uh is like the requirements to be running this and what to be most mostly available um to to people that will be running the clients, right? Yeah. Yeah. I think that's a good point.

Uh we probably can't assume AVX 512. Uh, I previously in the past said because Mac uses Neon and that's 128, we could go for that, but I'm happy to be like wrong there. Or does anyone have strong opinions? Cuz I don't know if anyone's actually running nodes on uh like a Mac. It's possible, but it might be just uh not a lot of people. Um, any strong opinions on 128 versus 256?

Uh, I guess with the hardware requirements would basically push it up to 256. Uh, cuz those are what the uh those are what they use. No strong. Okay. So, I'll write down investigate SIMD comparisons with uh AVX2. Uh, and we want to investigate with small fields and BM24 for Poseidon.

Uh, I believe that's most of the question. Does anyone else have any other questions? Okay. Uh, looking at the action items from last week, it seems that we also had a item on how to basically speed up the testing pipeline. essentially having a front end that allows us to quickly like create Poseidon a Poseidon implementation or any other implementation.

Chance I believe you was going to look into it but I think radic you also had some points on it. Uh what was the status of that tool? Um, I haven't looked into it explicitly, but I have opinions about how we should do this. It would be nice if we could compile to an assembly and then sort of assemble that into bite code because we're going to have a bunch of sequences of like these up codes with immediates and um it it would just be easy to have like a sort of highle languages that compiles to an assembly like that.

Um yeah, that's basically my opinion on it. Uh I guess how quickly could we get this high level language? Um I mean, yeah, I see that we don't want to spend too much time on uh this tool when the end tool will probably be the compiler just integrating it. Yeah. Um it could be done pretty quickly. I mean, so the question is, do we want to benchmark these things in the actual node implementations or do we want to sort of write an EVM max backend that is independent of an EVM node and then sort of execute code inside of that for

benchmarking. Um, and then we can investigate some stuff in there and benchmark actual performance without having to like muck around in actual Ethereum node implementations, right? Um, that's the first point. And the second point is I kind of think that solidity is incompatible with this EDM max thing because I you'd have to do a lot of static analysis in solidity I think with like loop unrolling and stuff like that to get optimal uh I guess performance out of EVM Max which I mean they might be willing to do. I I just I don't it seems like a tall order compared to like writing something novel.

axer there's no static analysis in in the compiler they're pretty simple rules doing all of those things at at the same time I think radic is an opinion that solidity is is good enough for this in the past the scheduling so the only one complex algorithm in there is the stack allocation or stack uh scheduling um and at some point it has been really sub-optimal um to support something like EVMX but having a initial support just for the op codes that is is fairly simple um according to radic um

I guess it's yet to be seen how the stack scheduler um would affect this because you know we not using the stack so hopefully it wouldn't but it's a bit unknown at this point. Yeah, exactly. I think that uh uh would be good to first start with some simple uh simple support for the EVM max uh op codes in but not sure about it. So, so I need to as I said I need to first because uh from what I understand we have some implementation in solidity already the the of the of the pose hash uh with uh with I would say legacy VM

and uh and uh and next I think I will try I I should I I I will try to to to implement first the the bite code generation but maybe maybe it will be much more easier just to add the support for the instruction instruction in Ule and try to use Ule for this purpose. But but yeah uh I think it should be it should be feasible to do it but uh but on the other hand we have to we have to check how how convenient is to to use it later and to write some more uh more complicated algorithms algorithms in this. So yeah so immediate value should be should be

quite easy but uh but but the question is how how comfortable it will be in the end. Yeah the current Poseidon implementation is mostly ule inside of solidity right now and I have a a script that generates the ule and so that could be adapted to generate EVM max ule assuming we had that. Yeah. Yeah. And al and also honestly I I haven't checked yet this uh this tool prepared by Jared uh and uh and also I would like to do it before before start doing anything in in solidity. So yeah, but it's for the next call.

Okay, that sounds good. Uh I guess we'll leave that with Roger. Cool. Uh, any other questions that anyone wants to bring up? Uh, if not then I think we can wrap up.

But I'll just uh repeat the free sort of items on the list which is to confirm the EVM max numbers plus the wall clock time. uh investigate SIMD comparisons uh using AVX2 or whatever 256 bit registers uh both with small fields and with BN254 for Poseidon and uh investigate this tool for allowing us to basically go end to end uh with like a Poseidon implementation or other implementations. So just any sort of front end that allows us to implement uh algorithms using EVMX instructions

and that's it. Yeah, I can I can also add this comparison between uh um I can do it for the next for the next call. of the comparison between the the legacy solidity version of POS hash and uh hopefully I will be able to to use our internal tool to for bite code generation to generate the the bite code uh EVM max byte code uh which u calculates this hash using EVM max any of these two versions I believe the the the vectorzed version should be better but I'll try to do it in both okay okay that sounds done. Um assuming that next call is in one month

from now. Okay, that sounds great. Uh any questions from anyone before we wrap up? Cool. All right. Thanks for attending, guys. Uh yeah, I'll see you in a month. Um, yeah. Have a nice day. Thank you. Z. See you.