I think the long prevents a number of optimizations…. It certainly prevents invariant hoisting.
> On Dec 27, 2017, at 5:20 PM, Peter Veentjer <[email protected]> wrote: > > 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 >>> <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 >> <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] > <mailto:[email protected]>. > For more options, visit https://groups.google.com/d/optout > <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.
