> From: Richard O'Keefe <o...@cs.otago.ac.nz> > Sent: Tuesday, May 22, 2012 7:59 PM
> But string processing and text I/O using the java.io.* classes aren't > brilliant. Wait just a moment - Are you comparing text I/O for C programs that process bytes against Java programs that process double-byte unicode? -snip- > Using System.in directly takes the time down from 15.07 seconds to 11.11 >seconds. -snip- > With both of these changes, we are moving away from recommended good practice; > the faster code is the kind of code people are not supposed to write any more. Says who? Is that on your own authority or some other source you can point us to? -snip- > As for Smalltalk, you must be thinking of free Smalltalk systems that lacked a > JIT. Commercial Smalltalks have excellent JITs (many HotSpot ideas were > copied > from them) ... As for Smalltalk, I earned my crust with commercial Smalltalks for a decade. > These particular measurements were made using my own Smalltalk compiler > which is an oddity amongst Smalltalks: a whole program compiler that compiles > via C. Yes, most of the good ideas came from INRIA, although ST/X does > something not entirely dissimilar. Wait just a moment - you wrote "I didn't _think_ I'd omitted anything important" and now it turns out that the measurements were made using your personal Smalltalk implementation! You have got to be joking. >> fwiw my expectation is that should be possible to make the Java program >> considerably faster. -snip- > Any reasonable person would expect ... I'm happy to hear what *you* would expect. -snip- > And it's not INTERESTING, and it's not about LANGUAGES. > There is NOTHING about the Java language that makes code like this > necessarily slow. It's the LIBRARY. The java.io library was > designed for flexibility, not speed. That's why there is a java.nio > library. Here's the gorilla in the room question - So why doesn't your program use java.nio? > And that's the point I was making with this example. Why does > Smalltalk come out in the middle of the Java results? A balance > between a language penalty (tagged integer arithmetic is a lot > slower than native integer arithmetic) and a library bonus (a > leaner meaner I/O design where there are wrappers if you want > them but you very seldom need them). It's the great advantage > of using libraries rather than syntax: libraries can be changed. No, that doesn't seem to be the case - if I'm misunderstanding what you've done then please correct me, but it seems that Smalltalk comes out in the middle of the Java results because you chose to use a Java library "designed for flexibility, not speed" and you chose to use that library in a way that slows the program down. -snip- > Neither. I am making the point that many benchmarks benchmark library > code rather than languages or compilers per se, and that the concept of > "same algorithm" is as a result very fuzzy. Thank you, for stating your point clearly. -snip- > How is "I have seen a lot of code" construed as "just speculating"? You seem to be generalizing from what you recollect without any way to control for the particularities of the situations you observed, or the particularities of your recollection. You don't seem to have data - just memories. -snip- > My evidence may be anecdotal, but it is better than arguing with NO evidence. imo It would be better to "show how much better programs using other data structures and algorithms perform those specific tasks" than brandish anecdotes from a past century. _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
