111–120 of 127 posts
There might be a third option though - code generation in a HLL. Coconut is a nice example of this:
http://www.youtube.com/watch?gl=GB&hl=en-GB&v=yHd0u6...
Instead the compiler being a black box, Coconut is structured as a set of libraries for code generation, analysis and optimisation. They report outperforming c SIMD by up to 4x on the cell architecture.
Please remember that "char x[N];" and "char x = malloc(N);" are NOT the same. (Not sure if this is news to anyone, but when I was learning C reading that would have made me think otherwise).
Earlier quoted context omitted.
Rewrite only those pieces that are consuming a lot of time or memory, leave the rest in Python, which is particularly good at integration with C/C++. Many programs are a lot of setup, error handling, and edge cases where performance is not an issue. but LOC is.
I thought about including the idea of only rewriting the hotspots, but left it out as detracting from the main point and it seemed tedious to iterate the details. But then there are 3 replies pointing this out, and which seem to be more valued than mine by the community (according to their votes.) Ask HN: Does this mean that HN would prefer I wrote comments that do cover all the cases, instead of just sticking to the…
I didn't mean anything personal, and I don't read any of the other comments that way.
The other comments may have just been voted up by people who also like Lua or Mercurial, or something. I thought it was worth noting that Lua was explicitly designed for that style of development. (Lua's also my favorite language.)
This argument is as old as the hills. It's probably true in a lot of niche situations. But the fact is, most C code is faster than higher-level language code, because: * C programmers have more freedom to arrange data in memory to exploit locality * C data structures need less bookkeeping * C programs manage memory manually, and so lack GC overhead * C programs can easily swap in different allocators for different wo…
A competent C programmer can clearly make a good, performant program in 10klines. A genius programmer, maybe 100klines. There's something beyond those figures, though. And it gets worse when a team is involved. The higher the level of the language rises, the less it allows making bad programs, however big the program is.
I think it's more complicated than that. Ruby is higher level than Java, but I would argue that Java makes it harder to write bad programs, especially in a team setting.
Earlier quoted context omitted.
I'm not saying Smalltalk is slow, but I've worked with rsaref since the mid-90s, and I don't remember a block cipher routine in it that was horribly slow due to allocation.
So instead of Highly Optimized Smalltalk (with VM implementor help) = Horrible C, we have Highly Optimized Smalltalk (with VM implementor help) = Average C. I can live with that.
Earlier quoted context omitted.
The paper you're citing doesn't contain the evidence you claim it has, and in GC vs. "manual" studies, you have to make sure they're not comparing GC to malloc(). Malloc has design goals other than speed. Performant code very often replaces malloc.
You're right - I made a stupid copy&paste mistake with both documents open :/ This is the link I was thinking about: http://www.cs.ucsb.edu/~grze/papers/gc/appel87garbage.pdf
* Garbage collection is faster than manual frees when you provide processes with so much memory that collection happens so rarely that its cost is lost in the noise, and
* Garbage collection is faster than manual frees when you ignore all the constant factors in both collection and manually freeing, for instance the cost of taking page faults?
Earlier quoted context omitted.
I thought about including the idea of only rewriting the hotspots, but left it out as detracting from the main point and it seemed tedious to iterate the details. But then there are 3 replies pointing this out, and which seem to be more valued than mine by the community (according to their votes.) Ask HN: Does this mean that HN would prefer I wrote comments that do cover all the cases, instead of just sticking to the…
> I just feel kind of annoyed that the replies seem to suggest I was stupid in not mentioning the hotspot idea. I didn't mean anything personal, and I don't read any of the other comments that way. The other comments may have just been voted up by people who also like Lua or Mercurial, or something. I thought it was worth noting that Lua was explicitly designed for that style of development. (Lua's also my favorite l…
Earlier quoted context omitted.
You're both making a pretty odd assumption here, which is that a program typically runs exactly once and that I am the only user of my own program. Users' time is also much more expensive than the computer's. That's why we write software in the first place.
No, I expect my scripts to run for a long time with many users. This doesn't preclude optimization; some of it is automatic (new hardware, interpreter library improvements), some of it is well established (using SWIG and C to replace only a tiny piece of the program that must be faster). In some respects, having long-lived software with lots of users makes speed the least of my concerns, because they're always asking…
The comparison of development times and running times simply makes no sense if you assume the script is going to run a 1000 times. I agree that this relationship isn't linear. That's exactly why it's pointless to compare the the two numbers as if it were. The only number that is comparable is probably the profit you make in each case.
Earlier quoted context omitted.
Java communities typically favor portability (and easy deployment) over what you can gain in terms of speed. A lot of libraries/frameworks actually even advertise themselves as "100% pure java", whereas one might expect "expensive bits optimized in C" as attractive as well (but you rarely see it).
> whereas one might expect "expensive bits optimized in C" There is no important difference in performance between C and Java according to http://shootout.alioth.debian.org/
Read the comments: turns out the author was ignorant of C++ templates (including Blitz++ scientific computing library) and he was lumping C and C++ together in his "benchmarks". It always annoys me when clueless people judge a language they don't even understand. Repeat after me: there is no such thing as C/C++.
I believe you actually meant 'ignorant of C++ template metaprogramming techniques'. The author seems well aware of C++ templates and even says:
>> the thing I coded immediately before the Stellation experiments was a very hairy template analysis for a C++ compiler
>he was lumping C and C++ together in his "benchmarks".
I couldn't see where, could you point out which comment leads to that inference?