He's referring (not "red herring" ) to the right side citing the units while you point at the lower left showing the capabilities of the queues + L1D$.
He's referring (not "red herring" ) to the right side citing the units while you point at the lower left showing the capabilities of the queues + L1D$.You confirmed that you are here just to troll, because on the bottom left corner it s explicitely written "2 loads + 1 store per cycle"...
This is of course in reference of the L/S capability but i guess that everyone here, set apart you, did notice this a long time ago..
I think one point is the used amount of local variables/structs as these would also land on the stack plus the contents of each register, which needs to be kept for later. The ABI and 2x the regs in 64bit help of course.Yes, but it's important to see how much stack is used on x86 & x64, which was the argument which we were talking about.
The huge registers usage in your case is due to the large number of SIMD registers of the GPU, so you cannot expect that this part of code requires 64 registers on x86 or x64 (but in this case more can be used).
In short: I doubt that this code makes use of a massive stack usage at runtime on x64.
He's referring (not "red herring" ) to the right side citing the units while you point at the lower left showing the capabilities of the queues + L1D$.
It also states in the exact same diagram 2load + 1 store a cycle, no 1+1 or 2+0 or , 2+1!
I think this's another misleading information spread in the slides. I suppose that when they talk about the 2 Load Store Units, they are referring to the 2 Load Store Queues.
Whereas when they talk about the 2 loads and 1 store, they are referring to the units which do the real job.
Tell me where I have negated this.
Guess what: we were "just" discussing of the L/S capability. IF and only IF you had the pleasure to read and understand what was written...
The compatibility with the isa should be guaranteed. Stacks are private between the threads and usually are never accessed by other CPUs or DMA devices, but without rush, i think that these data should be ultimately written in RAM, or at least in caches...I think one point is the used amount of local variables/structs as these would also land on the stack plus the contents of each register, which needs to be kept for later. The ABI and 2x the regs in 64bit help of course.
One thing to add to the stack engine: Mike explicitly talked about early store to load forwarding, as stack ops usually go PUSH -> POP, not the load first. So does this have to go to the cache? Only, if some dependency got dedected, also a job of the stack engine.
Yeah, I've seen that reply. Interesting: AMD only mentions the load capacity on the right side.Not at all, he s refering to the capability per cycle, this has already been pointed by a member who told him that
Somewhere I have som big traces... These might help.The compatibility with the isa should be guaranteed. Stacks are private between the threads and usually are never accessed by other CPUs or DMA devices, but without rush, i think that these data should be ultimately written in RAM, or at least in caches...
EDIT: the stack engine must propagate the data in one specific case: if there are instructions in the flow, not managed by the stack engine, and so not removed from the flux, that uses the stack data as instructions with direct addressing, such as MOV AX,[SP+BP] etc...
EDIT: i would also like to know how aliasing problem is resolved: i can access the stack with another register, or with another offset... How this is managed?
Yeah, I've seen that reply. Interesting: AMD only mentions the load capacity on the right side.
Somewhere I have som big traces... These might help.
These instructions with direct addressing of stack ranges are the reason for the dependency checks. And if the data written to the stack needs to go to the RAM, these stores might be done at a lower priority in a deferred way.
That's enough, for small pieces of code.I don't know how to perform dynamic analysis (i never used a debugger... At most i gave an eye on assembler sources as you can see)...
The analysis has a lot of limits, if you read the paper.But the analysis Dresdenboy posted clearly demonstrates that 40% stack activity is possible... And indeed since code that uses more than 2 memory uop/cycle, probabily is RAM BW starved, the bottleneck will be not the AGUs...
So, less AGUs are better? If they are rarely used, there's no need to put 3 AGUs. And not even 2 load + 1 store unit. Right? So you can save transistors, power, and have a simpler design, right?Think of it: heavy HPC code is probabily working on data that not fit in the L1 cache... Probabily neither L2 or L3... So it must rely on RAM BW... Moreover with an IPC around 2.5, we can expect that most of them are not memory accesses, due to RAM BW limitations... Limited IPC code is that with many jumps or memory accesses, because memory is often a bottleneck... Rarely a general purpose program has IPC higher than 1.5... And with 50% of instruction being memory accesses, even two threads of this kind can not saturate 2 AGUs... More AGUs can process faster a peak, but in steady state, less than 2 agu operations/cycle are needed even for two heavy HPC threads...
In fact your code actually has just one "hot spot" for memory reads only on the innermost loop, while the rest of the time it makes a lot of integer/scalar operations:HPC software with more than 2 of IPC are software with heavy and complex calculation for each data. A convolution like image filter like the one i have posted is bandwidth starved, because it does at most a simple add and mul for each data... Too few calculations for each memory access...
The pattern would be:
- LOAD initial value (0)
- ACCUMULATE the value: load from memory two data; the addresses must be calculated from the indexes, so integer arithmetic and scratch registers must be used, multiply the two numbers and add to the accumulator
- At the end of n cycles of accumulation, divide by the number of cycles
- Repeat for each pixel.
Apart the final division, you can see that for each memory access, a FMAC is needed.
This is the worst case for Zen. If you implement as a FMAC or a FMUL and a FADD, for each couple of memory accesses you need a FMAC. So you cut in HALF the throughput, because you have not 4 AGUs, nor 4 Load ports.
But this at least requires an index increment, supposing using an onedimensional vector...
But as you can see in the code I posted, often we have 2D or 3D images.
So we have 2 or three indices to increment. And in case of convolution they are 4 or 6, as you can see in the code i gave you...
Moreover for each cycle i must calculate the offsets with 2 or 3 INT ADDs and 2 or 3 MULs.
So before I need to actually load the two data, each cycle I must do many operations before i can even load the two data...
With outside precalculation of offsets (like I said before), we can reduce this to few operations. Plus the load and the FMAC for each cycle... One index increment, memory access (with precalculated index) and a fmac. 7 operation per cycle are obtained in another code, not posted, that does more complex calculation than a single FMAC. But if you keep the code simple, you need at least 3 add a 3 mul only to calculate the offsets and only then you can load the two data...
Only with monodimensional data you need 2 indexes and so 3 arithmetic instructions (1 fmac) and 2 memory access...
EDIT: obviously i forgot the 6 CMP and the 6 conditional JUMPs... They too, in turn, are executed... 1 fused uop per cycle, plus others once a while (when an inner loop finishes)
for (x = -d_x; x <= d_x; x++)
00007FF7B640123B 45 3B C3 cmp r8d,r11d
00007FF7B640123E 7F 2D jg MeanVar+26Dh (07FF7B640126Dh)
00007FF7B6401240 42 8D 04 0B lea eax,[rbx+r9]
00007FF7B6401244 03 C1 add eax,ecx
00007FF7B6401246 0F AF C7 imul eax,edi
00007FF7B6401249 41 03 C0 add eax,r8d
00007FF7B640124C 03 C2 add eax,edx
00007FF7B640124E 48 98 cdqe
00007FF7B6401250 49 8D 0C C4 lea rcx,[r12+rax*8]
00007FF7B6401254 41 8B C3 mov eax,r11d
00007FF7B6401257 41 2B C0 sub eax,r8d
00007FF7B640125A FF C0 inc eax
00007FF7B640125C 48 63 D0 movsxd rdx,eax
val += img[x + i + sx*(y + j + sy*(z + k + sz*m))];
00007FF7B640125F F2 0F 58 01 addsd xmm0,mmword ptr [rcx]
00007FF7B6401263 48 83 C1 08 add rcx,8
00007FF7B6401267 48 83 EA 01 sub rdx,1
00007FF7B640126B 75 F2 jne MeanVar+25Fh (07FF7B640125Fh)
for (y = -d_y; y <= d_y; y++)
00007FF7B640126D 8B 8C 24 B8 00 00 00 mov ecx,dword ptr [j]
00007FF7B6401274 41 FF C1 inc r9d
00007FF7B6401277 8B 94 24 C0 00 00 00 mov edx,dword ptr [i]
00007FF7B640127E 45 3B CE cmp r9d,r14d
00007FF7B6401281 0F 8E 0B FF FF FF jle MeanVar+192h (07FF7B6401192h)Correct.He's referring (not "red herring" ) to the right side citing the units while you point at the lower left showing the capabilities of the queues + L1D$.
There's no negation. See below.Not at all, he s refering to the capability per cycle, this has already been pointed by a member who told him that :
To wich he answered :
Your negation s in the quotes i made above, and wich can all be found here, in one of your post :
http://www.portvapes.co.uk/?id=Latest-exam-1Z0-876-Dumps&exid=threads/first-summit-ridge-zen-benchmarks.2482739/page-56#post-38509839
Well, you continue to ignore the point of the discussion, which should have been clear with the post that you reported.As for discussing the LSU capabilities, so much, are you sure that it s not rather about ignoring its capabilities..?.
Absolutely. Here is the x86 version of the above code:I think one point is the used amount of local variables/structs as these would also land on the stack plus the contents of each register, which needs to be kept for later. The ABI and 2x the regs in 64bit help of course.
for (x = -d_x; x <= d_x; x++)
0007117E 3B CF cmp ecx,edi
00071180 7F 2A jg MeanVar+1ACh (0711ACh)
00071182 8D 04 32 lea eax,[edx+esi]
00071185 8B 55 E0 mov edx,dword ptr [img]
00071188 03 45 EC add eax,dword ptr [j]
0007118B 0F AF 45 10 imul eax,dword ptr [sx]
0007118F 03 C1 add eax,ecx
00071191 03 45 F8 add eax,dword ptr [i]
00071194 8D 14 C2 lea edx,[edx+eax*8]
00071197 8B C7 mov eax,edi
00071199 2B C1 sub eax,ecx
0007119B 40 inc eax
0007119C 0F 1F 40 00 nop dword ptr [eax]
val += img[x + i + sx*(y + j + sy*(z + k + sz*m))];
000711A0 F2 0F 58 0A addsd xmm1,mmword ptr [edx]
000711A4 83 C2 08 add edx,8
000711A7 83 E8 01 sub eax,1
000711AA 75 F4 jne MeanVar+1A0h (0711A0h)
for (y = -d_y; y <= d_y; y++)
000711AC 8B 4D 08 mov ecx,dword ptr [d_y]
000711AF 46 inc esi
000711B0 8B 55 F4 mov edx,dword ptr [ebp-0Ch]
000711B3 3B F1 cmp esi,ecx
000711B5 0F 8E 65 FF FF FF jle MeanVar+120h (071120h)IMO it should go to the cache too. Having two different mechanism to keep track of memory disambiguation, in the stack and in the L/S section, is overkill.One thing to add to the stack engine: Mike explicitly talked about early store to load forwarding, as stack ops usually go PUSH -> POP, not the load first. So does this have to go to the cache? Only, if some dependency got dedected, also a job of the stack engine.
The stack can be also shared between threads/cores, albeit it's a bit tricky.The compatibility with the isa should be guaranteed. Stacks are private between the threads and usually are never accessed by other CPUs or DMA devices, but without rush, i think that these data should be ultimately written in RAM, or at least in caches...
Eh. That's the problem of memory disambiguation, which is solved comparing the resulting (virtual) pointers values.EDIT: the stack engine must propagate the data in one specific case: if there are instructions in the flow, not managed by the stack engine, and so not removed from the flux, that uses the stack data as instructions with direct addressing, such as MOV AX,[SP+BP] etc...
EDIT: i would also like to know how aliasing problem is resolved: i can access the stack with another register, or with another offset... How this is managed?
No, I think that the stack engine can safely track only [RSP + offset] and [ESP + offset] memory accesses. EBP/RBP can be also used with not stack data pointers, or even for holding plain data, so it's a bit difficult to use the same logic/methods here. Which is OK, because with 64 bit code it's RSP which is usually used for referencing stack data.So the stack engine should examine ALL memory instructions to see if they access stack? It should do all AGU calculations? What about indirect addressing? This can be very slow...
Yes, can be. But you still need to propagate the writes to L/S section, and updating the L1D too (when it's needed / forced to be).I think that checkpointing was done for this reason... If at retire stage i detect a conflict between a memory operation and a stack operation on the same physical address, this should be managed...
Exactly: that's an hazard.Let's make an example: suppose we PUSH (write) something on the stack and a subsequent instruction, with a complex addressing mode and not using SP, trying to load the same address, is directed to the normal path: if the L/S units are not connected with the memfile, the instruction could see an old value... So the memfile acts as an L0D cache... Obviously the opposite is true: the memfile should check also the L1D cache, with an already calculated address, without using the standard AGUs...
That's enough, for small pieces of code.
The analysis has a lot of limits, if you read the paper.
So, less AGUs are better? If they are rarely used, there's no need to put 3 AGUs. And not even 2 load + 1 store unit. Right? So you can save transistors, power, and have a simpler design, right?
In fact your code actually has just one "hot spot" for memory reads only on the innermost loop, while the rest of the time it makes a lot of integer/scalar operations:
Well, the code generated by Visual Studio 2015 doesn't seem to be so much optimized, since it's not even able to vectorize the code (it uses only scalar double FP operations). However it did a good work of recognizing the invariant parts, and pre-calculate some values.Code:for (x = -d_x; x <= d_x; x++) 00007FF7B640123B 45 3B C3 cmp r8d,r11d 00007FF7B640123E 7F 2D jg MeanVar+26Dh (07FF7B640126Dh) 00007FF7B6401240 42 8D 04 0B lea eax,[rbx+r9] 00007FF7B6401244 03 C1 add eax,ecx 00007FF7B6401246 0F AF C7 imul eax,edi 00007FF7B6401249 41 03 C0 add eax,r8d 00007FF7B640124C 03 C2 add eax,edx 00007FF7B640124E 48 98 cdqe 00007FF7B6401250 49 8D 0C C4 lea rcx,[r12+rax*8] 00007FF7B6401254 41 8B C3 mov eax,r11d 00007FF7B6401257 41 2B C0 sub eax,r8d 00007FF7B640125A FF C0 inc eax 00007FF7B640125C 48 63 D0 movsxd rdx,eax val += img[x + i + sx*(y + j + sy*(z + k + sz*m))]; 00007FF7B640125F F2 0F 58 01 addsd xmm0,mmword ptr [rcx] 00007FF7B6401263 48 83 C1 08 add rcx,8 00007FF7B6401267 48 83 EA 01 sub rdx,1 00007FF7B640126B 75 F2 jne MeanVar+25Fh (07FF7B640125Fh) for (y = -d_y; y <= d_y; y++) 00007FF7B640126D 8B 8C 24 B8 00 00 00 mov ecx,dword ptr [j] 00007FF7B6401274 41 FF C1 inc r9d 00007FF7B6401277 8B 94 24 C0 00 00 00 mov edx,dword ptr [i] 00007FF7B640127E 45 3B CE cmp r9d,r14d 00007FF7B6401281 0F 8E 0B FF FF FF jle MeanVar+192h (07FF7B6401192h)
One thing that you can easily verify is that in this part of code the stack variables are rarely used, compared to all memory accesses, and that happens also in the rest of the code.
For both of you I have an interesting link, providing up to 100m long traces incl. a small player, which can be used for counting specific uops:I'm sorry for not being clear before: I did the analysis of your code only to show how very low is the stack usage in this case (with x64 in particular, which has plenty of available registers).
Naturally, it's not limited by the lack of AGUs, and BTW I don't think that the memory bandwidth should be a bottleneck too, since the code isn't using at all vector instructions. And, a stack engine, whatever is the work that it does, doesn't help as well here.
That's it.
Wow, this is interesting. So what is the stimate of the performance of Zen?
If goes to Haswell levels on ST, I'll go with AMD, not for performance, but to maintain a competitor alive (just like the people who watched the Warcraft movie)
Thanks. I took a look at the same trace, but I've something to say something about the binary code and tool itself.For both of you I have an interesting link, providing up to 100m long traces incl. a small player, which can be used for counting specific uops:
http://www.cis.upenn.edu/~milom/cis501-Fall12/traces/trace-format.html
I once had a look at the small gcc trace. It contains (for 1000 instructions executed): 232 loads (incl. 35 POPs -> 13%) and 108 stores (incl. 29 PUSHs -> 32%).
Reg: Count
0: 211
1: 67
2: 118
3: 68
4: 299
5: 87
6: 61
7: 50
8: 23
9: 18
10: 10
11: 10
12: 51
13: 57
14: 23
15: 14
44: 319
45: 140Instruction Count %
MOV 227 30%
J 157 20%
CMP 111 14%
TEST 48 6%
PUSH 35 4%
POP 29 3%
ADD 22 2%
JMP 17 2%
MOVZX 15 1%
LEA 13 1%
XOR 11 1%
CALL 10 1%
RET 9 1%
SHL 9 1%
AND 9 1%
SUB 8 1%
NOP 8 1%
MOVSX 5 0%
SHR 4 0%
SET 3 0%
XCHG 2 0%
NOT 1 0%
OR 1 0%
TOTAL 754 100%Micro-op Count %
LOAD 232 23%
JMP_IMM 183 18%
SUB_IMM 113 11%
STORE 108 10%
ADD_IMM 67 6%
SAVE_PC 58 5%
ADD 58 5%
SUB 51 5%
AND 49 4%
LEA 16 1%
JMP_REG 10 1%
NOP 10 1%
ZEXT_BYTE_TO_DWORD 8 0%
AND_IMM 8 0%
ZEXT_WORD_TO_DWORD 7 0%
SHL_IMM 7 0%
SEXT_DWORD_TO_QWORD 5 0%
SHR_IMM 4 0%
XOR 2 0%
SHL 2 0%
NOT 1 0%
OR 1 0%
TOTAL 1000 100%1 48becc -1 -1 45 - - - 5887758 0 48bed2 0 CMP SAVE_PC
2 48becc -1 45 45 - - L 0 a295e0 48bed2 0 CMP LOAD
3 48becc 5 45 44 W - - 0 0 48bed2 0 CMP SUB1 48d248 -1 -1 44 - - - 0 0 48d24d 0 CALL SAVE_PC
2 48d248 4 -1 4 - - - 8 0 48d24d 0 CALL SUB_IMM
3 48d248 44 4 -1 - - S 0 7fffe7fefc8 48d24d 0 CALL STORE
4 48d248 -1 -1 -1 - T - -5149 0 48d24d 48be30 CALL JMP_IMMIMO a big scheduler is able to extract more ILP, because it can "instantly" have a view of the situation with the ports & dependencies & stalls, and take the proper decisions.There are a few "interesting points" that we can see with Zen for ST:
Does the 6 small integer schedulers have a impact on extractable ILP vs one big one, if so how much.
On top of this add also that 256-bit instructions basically might "halve" the throughput of the Decoder, since 2 macro-ops are generated. That's if Zen follows the same strategy of Steamroller.A lot more of the questions are actually around SIMD performance, this whole stack engine discusions is really about having enough load/store and address generation for very heavy sustained amounts of 3 operand operations (AVX, FMA).
A couple of things here. First, FPU instructions with memory operands need to pass through the "INT/AGU" section, and we don't know if/how much it hurts performances. Second, there are FPU instructions which use "integer" registers, so the execution has to split in some way, with a corresponding penalty.Larger FP register file:
More execution resources
lower execution latency ( except for FMA)
lower load to use latency
a buffer pre FPU scheduler so ops can still be sent to FPU even if FPU scheduler is full
The problem is that a unified scheduler has a huge complexity. Even simple heuristics, such as pick oldest instructions, are hard to implement with low latency. I wouldn't be surprised if Intel scheduler was the most complex and tuned block of their CPU.IMO a big scheduler is able to extract more ILP, because it can "instantly" have a view of the situation with the ports & dependencies & stalls, and take the proper decisions.
I have difficulties thinking how a system with multiple queues/schedulers can deal with the same things, while keeping an high ILP.
i would assume there is a scheduler of schedulers that has a high level view of what each sub schedules queue looks like. So i really have no idea how much that will hurt ILP if at all. A question i just thought of is would the scheduler of schedulers be FIFO or more complex?I have difficulties thinking how a system with multiple queues/schedulers can deal with the same things, while keeping an high ILP.
Im sure there was a link somewhere ( i think posted by Dresdenboy) that Michael clarke said that it leaves decode as one Mop and is split latter on, so to me that sounds more like 1 decoder. Intel prob shared AVX spec with AMD to late for them to accommodate it in this way for CON core, You would need to accommodate this both in the schema/format of the Mop's and also in decode/issue/etc.On top of this add also that 256-bit instructions basically might "halve" the throughput of the Decoder, since 2 macro-ops are generated. That's if Zen follows the same strategy of Steamroller.
This is the same for all AMD uarch, except it was worse for bulldozer as it had that 2 core/FPU LSU interconnect thing going on.A couple of things here. First, FPU instructions with memory operands need to pass through the "INT/AGU" section, and we don't know if/how much it hurts performances. Second, there are FPU instructions which use "integer" registers, so the execution has to split in some way, with a corresponding penalty.
Thanks for the statistics (also on your blog). These are always interesting and help in discussing uarch topics.Thanks. I took a look at the same trace, but I've something to say something about the binary code and tool itself.
I suppose that trace comes from a code which is compiled by GCC itself, however it doesn't look so much optimized. I saw some word (16-bit code) usage (with 64-bit code!), which usually is slow, and in general a more x86-like approach for function calls, with pushes and pops. In fact, I don't see a good usage of the available registers.
Regarding the tool, it's clearly outdated (last update was on 2011), and I think that it TRIES to simulate the behavior of an Intel processor (maybe Sandy Bridge).
For this reason, the data about uops and micro-ops are at least biased.
I also found some errors, like this:
which doesn't make sense for a CMP instruction. Specifically, CMP needs at most 2 uops to be executed on Sandy Bridge (according to Agner).Code:1 48becc -1 -1 45 - - - 5887758 0 48bed2 0 CMP SAVE_PC 2 48becc -1 45 45 - - L 0 a295e0 48bed2 0 CMP LOAD 3 48becc 5 45 44 W - - 0 0 48bed2 0 CMP SUB
A similar error is reported for the CALL:
A near call needs 3 uops, not 4. 4 are required only for call using a memory operand.Code:1 48d248 -1 -1 44 - - - 0 0 48d24d 0 CALL SAVE_PC 2 48d248 4 -1 4 - - - 8 0 48d24d 0 CALL SUB_IMM 3 48d248 44 4 -1 - - S 0 7fffe7fefc8 48d24d 0 CALL STORE 4 48d248 -1 -1 -1 - T - -5149 0 48d24d 48be30 CALL JMP_IMM
Finally, a text format might be good for small traces, but for big ones I greatly prefer a more compact binary format, which is also much easier to parse in parallel, using all available cores/threads (which is required for millions of traces).
Andrew Hilton said:The simulator executes the user-level portions of statically linked 64-bit x86 programs. It decodes x86 macro instructions and cracks them into a RISC-style μop ISA. The μop cracking used in Core i7 is proprietary, so there is no way to tell how similar the μop ISAs are.
There are patents which mention a method of putting uops, which depend on the output of older uops, into the same scheduler queue as the older ones. These could then be executed in order, as a small dependency chain, created by a small part of the code DAG. Such a scheduler doesn't need to track all other schedulers, as they all might broadcast the availability and source (PRF, bypass network, imm/disp storage, flag PRF) of results via tags.IMO a big scheduler is able to extract more ILP, because it can "instantly" have a view of the situation with the ports & dependencies & stalls, and take the proper decisions.
I have difficulties thinking how a system with multiple queues/schedulers can deal with the same things, while keeping an high ILP.
But that's a limit of mine.
On top of this add also that 256-bit instructions basically might "halve" the throughput of the Decoder, since 2 macro-ops are generated. That's if Zen follows the same strategy of Steamroller.
A couple of things here. First, FPU instructions with memory operands need to pass through the "INT/AGU" section, and we don't know if/how much it hurts performances. Second, there are FPU instructions which use "integer" registers, so the execution has to split in some way, with a corresponding penalty.
You might also see the term "Macro-op" to stand for the CISC op. Indeed, these terms have been used interchangeably in a way, that it might become difficult to tell the differences. For the source of the uops, see my answer to cdimauro above.The terms Macro-op and micro-op let me think that is an AMD CPU, mabye pre-Bulldozer...
I ever thought that INTEL has only simple uops...
I think that job you described here is that of the renamer. The individual schedulers still check the available sources in their arrays, which get updated by broadcasted tags.i would assume there is a scheduler of schedulers that has a high level view of what each sub schedules queue looks like. So i really have no idea how much that will hurt ILP if at all. A question i just thought of is would the scheduler of schedulers be FIFO or more complex?
Here's the link. I cited him over at S|A.Im sure there was a link somewhere ( i think posted by Dresdenboy) that Michael clarke said that it leaves decode as one Mop and is split latter on, so to me that sounds more like 1 decoder. Intel prob shared AVX spec with AMD to late for them to accommodate it in this way for CON core, You would need to accommodate this both in the schema/format of the Mop's and also in decode/issue/etc.
Agreed. I think the other way round.Can we talk about architecture in the other thread? Looking for benchmarks and see very little :*(