суб, 9. мај 2020. у 14:50 Laurent Desnogues <laurent.desnog...@gmail.com> је написао/ла: > > On Sat, May 9, 2020 at 2:38 PM Aleksandar Markovic > <aleksandar.qemu.de...@gmail.com> wrote: > > > > суб, 9. мај 2020. у 13:37 Laurent Desnogues > > <laurent.desnog...@gmail.com> је написао/ла: > > > > > > On Sat, May 9, 2020 at 12:17 PM Aleksandar Markovic > > > <aleksandar.qemu.de...@gmail.com> wrote: > > > > сре, 6. мај 2020. у 13:26 Alex Bennée <alex.ben...@linaro.org> је > > > > написао/ла: > > > > > > > > > This is very much driven by how much code generation vs running you > > > > > see. > > > > > In most of my personal benchmarks I never really notice code > > > > > generation > > > > > because I give my machines large amounts of RAM so code tends to stay > > > > > resident so not need to be re-translated. When the optimiser shows up > > > > > it's usually accompanied by high TB flush and invalidate counts in > > > > > "info > > > > > jit" because we are doing more translation that we usually do. > > > > > > > > > > > > > Yes, I think the machine was setup with only 128MB RAM. > > > > > > > > That would be an interesting experiment for Ahmed actually - to > > > > measure impact of given RAM memory to performance. > > > > > > > > But it looks that at least for machines with small RAM, translation > > > > phase will take significant percentage. > > > > > > > > I am attaching call graph for translation phase for "Hello World" built > > > > for mips, and emulated by QEMU: *tb_gen_code() and its calees) > > > > > > > Hi, Laurent, > > > > "Hello world" was taken as an example where code generation is > > dominant. It was taken to illustrate how performance-wise code > > generation overhead is distributed (illustrating dominance of a > > single function). > > > > While "Hello world" by itself is not a significant example, it conveys > > a useful information: it says how much is the overhead of QEMU > > linux-user executable initialization, and code generation spent on > > emulation of loading target executable and printing a simple > > message. This can be roughly deducted from the result for > > a meaningful benchmark. > > > > Booting of a virtual machine is a legitimate scenario for measuring > > performance, and perhaps even attempting improving it. > > > > Everything should be measured - code generation, JIT-ed code > > execution, and helpers execution - in all cases, and checked > > whether it departs from expected behavior. > > > > Let's say that we emulate a benchmark that basically runs some > > code in a loop, or an algorithm - one would expect that after a > > while, while increasing number of iterations of the loop, or the > > size of data in the algorithm, code generation becomes less and > > less significant, converging to zero. Well, this should be confirmed > > with an experiment, and not taken for granted. > > > > I think limiting measurements only on, let's say, execution of > > JIT-ed code (if that is what you implied) is a logical mistake. > > The right conclusions should be drawn from the complete > > picture, shouldn't it? > > I explicitly wrote that you should consider a wide spectrum of > programs so I think we're in violent agreement ;-) >
lol, I will write down "violent agreement" in my mental notebook of useful phrases. :)) Yours, Aleksandar > Thanks, > > Laurent > > > Yours, > > Aleksandar > > > > > Sorry if I'm stating the obvious but both "Hello World" and a > > > Linux boot will exhibit similar behaviors with low reuse of > > > translated blocks, which means translation will show up in > > > profiles as a lot of time is spent in translating blocks that > > > will run once. If you push in that direction you might reach > > > the conclusion that a non JIST simulator is faster than QEMU. > > > > > > You will have to carefully select the tests you run: you need > > > a large spectrum from Linux boot, "Hello World" up to synthetic > > > benchmarks. > > > > > > Again sorry if that was too trivial :-) > > > > > > Laurent
