I too suspect that eventually Intel and like will find a solution to the write bandwidth problem but until then.... Kirk On Jun 17, 2011, at 4:45 PM, Kevin Wright wrote:
> While we're travelling down this line of thought... let me throw Jonathan > Edwards' "Coherent Reaction" approach into the mix. > http://dspace.mit.edu/bitstream/handle/1721.1/45563/MIT-CSAIL-TR-2009-024.pdf?sequence=1 > > (yes, the same guy who wrote "switching to plan J") > > As Kirk points out, CPU write bandwidth can be a problem for performance, and > immutability puts extra pressure on this. Hardware can help, and I believe > we *will* get this support as future core counts continue to grow. After > all, the pressure here is coming from LINQ in .NET, F#, fortress, clojure, > etc. in addition to Scala, so it's going to be of value to the HPC crowd, as > well as IBM, Oracle, Microsoft and other groups who are highly persuasive > when it comes to requesting hardware features. > > So sure, there are valid reasons for sacrificing immutability; but the > problem is that we're talking about performance, and therefore optimisation. > > As we all know, premature optimisation is the root of all evil, and I don't > think you can get much more premature than giving up on the concept after > reading a mailing list long before you've written even a single line of code. > > > > On 17 June 2011 15:16, Josh Berry <tae...@gmail.com> wrote: > On Fri, Jun 17, 2011 at 10:05 AM, Kirk <kirk.pepperd...@gmail.com> wrote: > > If you don't want something to change the internal state, don't export it. > > > > Hmm... sounds like you are talking more about complex datastructures. > I'm typically more concerned with immutability in value types. And, I > ultimately wouldn't even care if the actual representation of the > String I'm using is mutated behind me. Interned for example. What I > care about is the value that I get when I use it stays the same. This > is similar to the GC argument. I don't care if my object stays put in > memory after I construct it. Only that I always get back to the same > object when I reference it. > > Now, I know there are "persistent" datastructures. My understanding > is the majority of those actually use mutations behind the scenes. > (At least the complex ones. I confess I have not read all of > Functional Datastructures. Much less understood it.) > > -- > 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. > > > > > -- > Kevin Wright > > gtalk / msn : kev.lee.wri...@gmail.com > mail: kevin.wri...@scalatechnology.com > vibe / skype: kev.lee.wright > quora: http://www.quora.com/Kevin-Wright > twitter: @thecoda > > "My point today is that, if we wish to count lines of code, we should not > regard them as "lines produced" but as "lines spent": the current > conventional wisdom is so foolish as to book that count on the wrong side of > the ledger" ~ Dijkstra > > > -- > 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.
