4 ms·
>The goal is to take standard applications and JIT them to their AVX-512 equivalent such that we can fuzz 16 VMs at a time per thread. What happens if the exec
by aaaaaaaaaab 8y ago
>The goal is to take standard applications and JIT them to their AVX-512 equivalent such that we can fuzz 16 VMs at a time per thread.
What happens if the executable already contains AVX512 (or other SIMD) instructions?
Though I guess you can rewrite them into their scalar equivalent first, and convert that into AVX512.
- pjc50 8y agoYou could also set the processor capability bits in the VM to pretend the processor is an older one, which will generally cause the application to fallback to a compatible piece of code. It's pretty rare in non-maths-heavy code.
- gamozolabs 8y agoI do this as much as possible. I even go out of my way to compile things if I have access to source with a weaker version of x86, or even cross compile it for something like MIPS. This is done however not due to a theoretical limitation of the tooling, but rather a practical one in that I haven't written SSE lifters and decoders yet. If I were to write these it would work just fine.
- vnorilo 8y agoThe real problem is when different VMs branch differently. You essentially have to run both sides of a branch in serial with masked lanes. The author mentions this and states that the method works only because the VMs are very deterministic. I don't understand how he deals with indirect jumps.
- DSingularity 8y agoYou mean the possibility that the branch target is different on the different VMs? He can fork the vectorization if the targets diverge. I’m not sure what he does though.
- vnorilo 8y agoSure, but how does that not utterly destroy performance as the fork would probably lead to multiple sub-forks down the line.. or lane? :)
- DSingularity 8y agoWhen you are fuzzing the ultimate goal is to explore as much as you can of the entire search space. Forks cant hurt performance. They are just another potential execution path to be vectorized.
- OskarS 8y agoHe writes that he's using a special type of IL for this technique, presumably he forbids indirect jumps in it.
- gamozolabs 8y agoTechnically right now if they have AVX instructions my lifter screams at me and tells me to not be lazy and implement those instructions ;) However if I were to lift AVX instructions I would lift them to their scalar counterparts in my IL (eg. by emitting 16 32-bit operations). Lets say there are 16 `vpaddd`s in a row, thus creating a 16x16 matrix, when I lift it I'd lift these adds to 128 individual adds, and then generate 128 `vpaddd`s. While I'm doing 16x more the `vpaddd`s I'm also running 16x more VMs than the application originally had, thus it cancels out, and the net effect is that I'm still running `vpaddd`s as fast as the CPU can execute them. Technically in this case my stuff might even be faster as it's going to be 128 adds instead of 16, which means the CPU is running based on instruction throughput longer and decoding the same instruction and keeping latencies down. However it's possible that this transposition of the matrix might increase dependencies between instructions or something of the sorts which might slow down performance. That being said, AVX is pretty much only used for memory loads and stores in string operations in most programs anyways, so it doesn't matter much.