On 05/05/2015 06:35 AM, Paolo Bonzini wrote:
On 02/05/2015 02:13, John Snow wrote:
I wrote a loop to batch the ascii-hex conversion instead of letting
printf do it; then ran some more very, very scientific tests:
memset alone:
real 0m10.888s
user 0m9.303s
sys 0m9.146s
send-batching:
real 0m6.541s
user 0m5.027s
sys 0m4.941s
memset+batching+b64:
real 0m3.675s
user 0m2.582s
sys 0m1.718s
So it still seems as if the b64 batching is a strict improvement
speed-wise. I'll send the non-b64 batching patch separately later,
unless you have thoughts otherwise.
Ok, this is more similar to what I'd expect (3.6 * 6 / 4 = 5.4, I'm not
sure if you have the memset optimization in the send-batching test).
I did, yes. Hence the "very, very scientific" warning. I just pushed
patches down my stack and tested with each new optimization.
Unoptimized is still ~14s.
Hex is obviously more debuggable compared to Base64 (unless you starred
in the Matrix movies), so I'm a bit undecided about this one. Anyone
can break the tie?
Paolo
I specifically left things that alter control flow using hex nibbles --
such as the FIS packets, PRD tables, and all other existing tests. I
only use the b64 encoding for raw data patterns, which don't really need
to be debugged. Either they match or they don't: any particular values
are uninteresting.
Any future test can be switched to/from hex/b64 by just altering
"mem{read,write}()" to "buf{read,write}()" as desired. I specifically
opted not to alter *all* qtest IO for this very reason.
Does that help? :)
If you're not opposed to the rest of this series, I will send a v2
including the hex batching optimization.
--js
