There is a larger infrastructure where this fits into, but not all parts are in place yet (returning results for example). So I needed a quick deadcode elimination prevention in place, hence the System.out. The main goal is to demonstrate, on our hackathon, how fast full table scans can be done when applying some mechanical sympathy.
On Wednesday, December 27, 2017 at 1:29:28 PM UTC+2, Kirk Pepperdine wrote: > > Ha, you tricked me.. I was looking at the println and thinking.. you don’t > really want those there.. do you???? But I assumed you had that covered… > so.. stupid makes two…. ;-) > > — Kirk > > On Dec 27, 2017, at 11:23 AM, Peter Veentjer <[email protected] > <javascript:>> wrote: > > Hi Kirk, > > thanks for your reply. > > Unfortunately I'm made a very shameful mistake. The println at the end of > the loop always gets called; even if nothing is found. And I made the > content so that the query would not find anything since I'm currently not > yet able to return a result. So the initial loop never has a println and > the second loop always has a println. > > After I added a guard to the println in the second loop, the performance > of both loops is exactly the same. So it wasn't a JIT issue after all, but > just plain stupidity. > > On Wednesday, December 27, 2017 at 11:21:05 AM UTC+2, Kirk Pepperdine > wrote: >> >> Hi, >> >> >> Can you make count a field and rerun? Not sure the for loop is being >> unrolled in either case as the index is a long. I’ve not checked unrolling >> but using a long can cause the JIT to miss optimizations that it would >> normally apply if an int was used instead. You might want to see what >> JITWatch can tell you. >> >> — Kirk >> >> On Dec 27, 2017, at 10:09 AM, Peter Veentjer <[email protected]> wrote: >> >> As part of an experiment, I'm working on querying large volumes of data >> which is stored offheap. >> >> The content of each record is stored in a chunk of offheap memory. So >> instead of having an array of object references, it is an array of records >> (no pointer chasing). >> >> My confusion is about some code I'm generating based on the query >> content. There are 2 flavors; one flavor where I'm printing if I found >> something and the other flavor increments a local long variable and print >> this at the end of the loop. >> >> The strange thing is that the first one (printing when the correct entry >> is found), is 15x faster than the one where I'm increasing the local >> counter. >> >> So this is the first: >> >> import java.util.*; >> public class FullTableScan_e872b2bd8f274cc18b37ac2a0e3df2ed extends >> com.hazelcast.simplemap.impl.FullTableScan{ >> public void run(){ >> long offset=slabPointer; >> for(long l=0;l<recordIndex;l++){ >> if((unsafe.getInt(offset+12)==10000) && >> (unsafe.getBoolean(null,offset+16)==true)){ >> System.out.println("found"); >> } >> offset+=recordDataSize; >> } >> >> } >> public void init(Map<String, Object> binding){ >> } >> } >> >> >> And this is the second: >> import java.util.*; >> public class FullTableScan_e872b2bd8f274cc18b37ac2a0e3df2ed extends >> com.hazelcast.simplemap.impl.FullTableScan{ >> public void run(){ >> long offset=slabPointer; >> long count = 0; >> for(long l=0;l<recordIndex;l++){ >> if((unsafe.getInt(offset+12)==10000) && >> (unsafe.getBoolean(null,offset+16)==true)){ >> count++; >> } >> offset+=recordDataSize; >> } >> System.out.println("count:"+count); >> } >> public void init(Map<String, Object> binding){ >> } >> } >> >> What could be the reason of this huge performance difference? It isn't a >> warmup problem since it was running for 5 minutes. Could there be some data >> dependency with the second loop that prevents the loop to be unrolled? I >> should analyze the assembler; perhaps this will shed some light on the >> situation. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "mechanical-sympathy" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> For more options, visit https://groups.google.com/d/optout. >> >> >> > -- > You received this message because you are subscribed to the Google Groups > "mechanical-sympathy" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected] <javascript:>. > For more options, visit https://groups.google.com/d/optout. > > > -- You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
