[concurrency-interest] Numerical Stream code

Stanimir Simeonoff stanimir at riflexo.com
Thu Feb 14 12:48:38 EST 2013


> > Do element sizes matter (byte vs. short vs. int  vs. long)?
>
> I don't think so.  All of this assumes that the proper instruction is
> used.  For example, if 2 threads are writing to adjacent bytes, then the
> "mov" instruction has to only write the byte.  If the compiler, decides to
> read 32-bits, mask in the 8-bits and write 32-bits then the data will be
> corrupted.
>
JLS mandates no corruption for neighbor writes.


> I believe that HotSpot will only generate the write byte mov instruction.
>
> That would be the correct one. The case affects only
boolean[]/byte[]/short[]/char[]  as simple primitive fields are always at
least 32bits.

Stanimir



> Nathan Reynolds<http://psr.us.oracle.com/wiki/index.php/User:Nathan_Reynolds>| Architect |
> 602.333.9091
> Oracle PSR Engineering <http://psr.us.oracle.com/> | Server Technology
>  On 2/14/2013 8:56 AM, Peter Levart wrote:
>
> On 02/14/2013 03:45 PM, Brian Goetz wrote:
>
> The parallel version is almost certainly suffering false cache line
> sharing when adjacent tasks are writing to the shared arrays u0, etc.
> Nothing to do with streams, just a standard parallelism gotcha.
>
> Cure: don't write to shared arrays from parallel tasks.
>
>
>  Hi,
>
> I would like to discuss this a little bit (hence the cc:
> concurrency-interest - the conversation can continue on this list only).
>
> Is it really important to avoid writing to shared arrays from multiple
> threads (of course without synchronization, not even volatile writes/reads)
> when indexes are not shared (each thread writes/reads it's own disjunct
> subset).
>
> Do element sizes matter (byte vs. short vs. int  vs. long)?
>
> I had a (false?) feeling that cache lines are not invalidated when writes
> are performed without fences.
>
> Also I don't know how short (byte, char) writes are combined into memory
> words on the hardware when they come from different cores and whether this
> is connected to any performance issues.
>
> Thanks,
>
> Peter
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20130214/be5d1db0/attachment-0001.html>


More information about the Concurrency-interest mailing list