I haven't followed this very well but can you explain how inheritance makes F/J not cause cache flushes? Sent from my BlackBerry® wireless device
-----Original Message----- From: Kirk <kirk.pepperd...@gmail.com> Sender: javaposse@googlegroups.com Date: Fri, 21 Oct 2011 10:41:51 To: Ray Hindman<javaposse@googlegroups.com> Reply-To: javaposse@googlegroups.com Subject: Re: [The Java Posse] Re: Fork/Join criticism Hi, I can only comment on the use of Unsafe and inheritance and performance. There are cases, and F/J is most likely one of them, where inheritance could be a win. Getting separation putting memory distance between shared an non-shared variables can result in them being place in difference cache lines. That can have the effect of prevent multi-thread access from causes each thread to cause the other threads to continuously flush their cache. Cache flushing can be a huge drain on performance. Until we get a normalized path to CAS that is baked into the JMM or Java Language Specification, we're stuck with unsafe. Regards, Kirk On Oct 21, 2011, at 7:49 AM, Reinier Zwitserloot wrote: > I can retort a few of these, but certainly not all of it. > > --Exceedingly Complex-- > > Yes, but, complaining that F/J (ab)uses com.sun.misc.Unsafe is just stupid, > in my opinion. The whole point of F/J is that _it_ abstracts away the > considerable complexity inherent in aggressively efficient multicore usage so > that the code written using the F/J framework is simple. Also, a framework > like F/J is one of the few times you actually get to adopt the maxim > "Micro-optimize this stuff to pieces, I don't care if the code becomes far > more difficult to manage going forward". That's what core frameworks have to > do to get the job done. For example, quite a few code in Math is very, lets > be nice and say 'uniquely' written, i.e, complete gobbledygook with a comment > 9x as large as the method explaining the arcane voodoo magicks going on, but, > nobody should be complaining about this. Math is complex so your code doesn't > have to be. > > Why is F/J such as a mess of inheritance? Yeah, well, I kinda agree with the > ranter on that one. inheritance isn't, as far as I know, a clear win for > performance (the opposite, usually), and I doubt it makes the API any cleaner > either. > > --Unstable-- > > We have but the word of our ranter. The fact that F/J has a long history of > tickets, assuming they've all been fixed, doesn't really say much about how > unstable this piece of software is. All software has bugs, a project that > carefully maintains a list and is open to 3rd party tickets shouldn't be > punished for that. Let's flip it around: If F/J did not have an extensive bug > list, would that mean it IS stable? That's clearly a silly argument. > > Multicore is inherently complicated, though outsiders usually think "Geez, > this has got to be much, much simpler than these supposed rocket scientists > are making it!". Guess what? Only outsiders hold that view. Once you tussle > with trying to write efficient multi-core code that works on all platforms > and acts consistently, you start to agree that it's just that complicated, > period. > > --Lack of attributes-- > > A lot of these I just don't follow at all. What does this mean?: "There is no > error detection/recovery/reporting (other then thrown exceptions)"? What kind > of detection/recovery/reporting should F/J be doing? It's core CPU work, > errors at this level are invariably unrecoverable and highly unexpected (your > CPU or OS is buggy, or the framework is), unless the cause is a bug in hosted > code, but propagating exceptions back out of the fork/join workers is exactly > how a library is supposed to handle this, so.... what's the complaint again? > I don't understand. > > Stall detection, anomaly detection, and performance monitoring is nice, but, > I'm kind of at a loss in regards to the flow of the rant. First the argument > is that this should be simpler, then the argument turns into: But it's > missing all these possible but quite complicated features. Which way is it? > > --Academic exercise-- > > This stuff is beyond my comprehension, unfortunately. > > --Inadequate in scope-- > > F/J working on either J2ME or an EE virtual server buit around RMIing calls > around the server park? Come on, that's a preposterous idea. It would be > nice, but, so are unicorns. > > > Didn't feel like going further into it today. > > > -- > You received this message because you are subscribed to the Google Groups > "The Java Posse" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/javaposse/-/J22idazMQUEJ. > To post to this group, send email to javaposse@googlegroups.com. > To unsubscribe from this group, send email to > javaposse+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/javaposse?hl=en. -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to javaposse@googlegroups.com. To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en. -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to javaposse@googlegroups.com. To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
