No and no :(
On Thursday, April 17, 2014 10:09 PM, ymo <ymol...@gmail.com> wrote:
I would not mind if this was on x86 only !!!--
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 mechanical-sympathy+unsub...@googlegroups.com.
I would not mind if this was on x86 only !!!
--
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 mechanical-symp...@googlegroups.com.
On Thu, Apr 17, 2014 at 3:09 PM, ymo <ymol...@gmail.com> wrote:
I would not mind if this was on x86 only !!!
--
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 mechanical-sympathy+unsub...@googlegroups.com.
Not for long:
http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-March/026031.html
To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-symp...@googlegroups.com.
On Apr 25, 2014 12:32 PM, "ymo" <ymol...@gmail.com> wrote:
Can you confirm since which jdk this christmas present was put in ?
The real test now is to see if this is going to make a difference .. but still thanks a lot for the link )))
On Thursday, April 24, 2014 10:52:48 PM UTC-4, Daniel Eloff wrote:
On Thu, Apr 17, 2014 at 3:09 PM, ymo <ymol...@gmail.com> wrote:
I would not mind if this was on x86 only !!!
--
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 mechanical-sympathy+unsubscribe...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
On Apr 25, 2014 12:32 PM, "ymo" <ymol...@gmail.com> wrote:
Can you confirm since which jdk this christmas present was put in ?
The real test now is to see if this is going to make a difference .. but still thanks a lot for the link )))
On Thursday, April 24, 2014 10:52:48 PM UTC-4, Daniel Eloff wrote:
On Thu, Apr 17, 2014 at 3:09 PM, ymo <ymol...@gmail.com> wrote:
I would not mind if this was on x86 only !!!
--
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 mechanical-sympathy+unsubscribe...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Just curious - what is your usecase where you want to do software prefetch?
Sent from my phone
To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-symp...@googlegroups.com.
And hardware prefetcher isn't picking up on this automatically? Not saying the prefetch in c++ is useless but what you describe sounds like hardware should handle well (I'm assuming the running through the array is done linearly).
Sent from my phone
To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-symp...@googlegroups.com.
--
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 mechanical-symp...@googlegroups.com.
--
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 mechanical-symp...@googlegroups.com.
To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-sympathy+unsub...@googlegroups.com.
To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-sympathy+unsub...@googlegroups.com.
To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-symp...@googlegroups.com.
I see what you are getting at. If you have no data dependency then it could be reordered. On x86 load and stores are not reordered given its memory model. Only loads are reordered with older stores to different locations.
That being said the compiler could reorder. I tend to check if I get the results I expect but have not used this on a large scale. Prefetch can be considered a hint. It is probably worth checking if prefetch is an ordered instruction like CPUID is. Does anyone know? Because it would have the same issue.
On 25 April 2014 21:56, Ariel Weisberg <arielw...@gmail.com> wrote:
Hi,I guess what I am getting at is that a blind store would have no dependencies. What would be the right way to introduce a dependency so that it would execute at the beginning of the loop body and not at the middle/end, or possibly be moved out of the loop body entirely.It seems like the CPU could choose to reorder execution as well although maybe at that granularity it isn't a concern for a pre-fetch optimization?
Ariel
On Friday, April 25, 2014 4:42:53 PM UTC-4, Martin Thompson wrote:
Experiment and make sure it works for your algorithm. Prefetching can be tricky as other things can happen that you don't expect. Linux ended up removing the prefetch on linked lists as it hurt more than it helped.
For ordering on the same thread you need to have data dependencies. A compiler will ensure program order within a thread.
On 25 April 2014 21:29, Ariel Weisberg <arielw...@gmail.com> wrote:
Hi,--How do you avoid having the store reordered or optimized in some unexpected way? Is it a non-issue?Ariel
On Friday, April 25, 2014 4:13:19 PM UTC-4, Martin Thompson wrote:Have you considered implementing the queue as sparse and then doing a write/read ahead to an unused address next to what you need on the next iteration? With this technique you can even effectively prefetch for write which you cannot with "explicit" prefetching.
Martin...On 25 April 2014 21:06, ymo <ymol...@gmail.com> wrote:
I am doing tight loops running on dedicated hardware that could benefit from pre fetching the data that is stored in queues. All the data is stored as an array that the cpu runs through as fast as possible. When i I say dedicated i mean that no other process is accessing the shared caches.
All of this is done in c++ since that is now impossible to do it in java. .. unfortunately so i cant move this code over to java ((
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 mechanical-sympathy+unsubscribe...@googlegroups.com.
Prefetch is unordered (it's just a hint anyway). I wonder if ymo's c++ code that's doing prefetch is some old relic to help on older hardware; modern cpus are pretty good at prefetching on their own; putting in manual hints may hurt as it may impede "normal" prefetch. Either way, I'd bench this before asking for its inclusion in java :).
Sent from my phone
1) you know how you are using your data better than the hw prefetch guessing game. That is why they have these instructions in the first place !
To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-sympathy+unsub...@googlegroups.com.
PREFETCH/PREFETCHW – Prefetch at least a 32-byte line into L1 data cache| PREFETCH0 | Prefetch Data from Address | Prefetch into all cache levels |
| PREFETCH1 | Prefetch Data from Address | Prefetch into all cache levels EXCEPT L1 |
| PREFETCH2 | Prefetch Data from Address | Prefetch into all cache levels EXCEPT L1 and L2 |
| PREFETCHNTA | Prefetch Data from Address | Prefetch into all cache levels to non-temporal cache structure |