On Friday, May 1, 2015 at 12:42:57 PM UTC-4, Steven G. Johnson wrote: > > > > On Thursday, April 30, 2015 at 6:10:58 PM UTC-4, Scott Jones wrote: >> >> Yes... Python will win on string processing... esp. with Python 3... I >> quickly ran into things that were > 800x faster in Python... >> (I hope to help change that though!) >> > > The "800x" faster example that you've referred to several times, if I > recall correctly, is one where you repeatedly concatenate strings. In > CPython, under certain circumstances, this is optimized to mutating one of > the strings in-place and is consequently O(n) where n is the final length, > although this is not guaranteed by the language itself. In Julia, Ruby, > Java, Go, and many other languages, concatenation allocates a new string > and hence building a string by repeated concatenation is O(n^2). That > doesn't mean that those other languages "lose" on string processing to > Python, it just means that you have to do things slightly differently (e.g. > write to an IOBuffer in Julia). >
I just don't think that IOBuffers are a very good way to do that... what I really need are mutable strings... and I know there is a package, and I need to investigate that further... it's something that would be nice to have as part of the core of the language, instead of having to use either Vectors or IOBuffers... As a new users, I would think, if I'm not doing IO, why should be using an IOBuffer... > You can't always expect the *same code* (translated as literally as > possible) to be the optimal approach in different languages, and it is > inflammatory to compare languages according to this standard. > I was not intending to be inflammatory, just relating what my first experience was, which let me to investigate much more deeply, into the good and bad issues in Julia wrt performance (more good than bad, by a long shot). > A fairer question is whether it is *much harder* to get good performance > in one language vs. another for a certain task. There will certainly be > tasks where Python is still superior in this sense simply because there are > many cases where Python calls highly tuned C libraries for operations that > have not been as optimized in Julia. Julia will tend to shine the further > you stray from "built-in" operations in your performance-critical code. > Yes, that is true... and that is why I'm betting on Julia in the long run (the other option for a lot of the code would have been Python or C++11, and I've already found Julia easier to deal with than either of them, even in it's pre 1.0 state)
