91–97 of 97 posts
Earlier quoted context omitted.
> Development time is a one off (for a given feature set) Indeed. With a feature set dynamic enough, the lead will mount up.
Or the lead may just shrink more slowly.
Earlier quoted context omitted.
Or the lead may just shrink more slowly.
Time running the app is both irrelevant compared to the time it takes to develop it. Also, as long as the app offers the answer quickly enough from the user's perspective, fast enough is fast enough and being able to iterate twice as fast as your competition is the ultimate advantage.
All I'm saying is that at some point it becomes way more expensive than paying developers to optimize or rewrite in a faster language, which is exactly why Google and Facebook are doing so much work in C++, not exactly a language known for developer productivity.
And obviously there are many places where you can't scale your way out of a response time or battery usage issue because you're not the one buying the machine.
So I totally disagree with your assumption that developer productivity always trumps runtime efficiency. It is also my experience that the productivity advantages usually ascribed to some (mostly dynamic) languages is way overblown. But that's another debate.
Earlier quoted context omitted.
> Don't make "unfair" accusations -- say why you think that Because there seems to be a bias in selecting the problems solved in the benchmark games: to be "fair" they should be randomly selected from a pool of all possible problems solved with computer programs. Or, maybe, the frequency of these problems in the real world should be taken into account? Of course, they're not actually unfair since they hide nothing. T…
1) "they're not actually unfair" So don't say that they are! 2) "The nice link you posted sums it up well" I agree - but then I wrote those words. 3) "there seems to be a bias in selecting the problems solved in the benchmark games" You still haven't said anything that suggests they are "targeted at low-level languages".
Earlier quoted context omitted.
1) "they're not actually unfair" So don't say that they are! 2) "The nice link you posted sums it up well" I agree - but then I wrote those words. 3) "there seems to be a bias in selecting the problems solved in the benchmark games" You still haven't said anything that suggests they are "targeted at low-level languages".
1) I didn't .. 3) I did in GP
3) GP? Your opining about "selecting the problems" doesn't support the claim "targeted at low-level languages" anymore than it supports the claim targeted at high-level languages :-)
As you noted the important thing to remember is that timing measurements are not promises, and they aren't general answers to the question - Will my program be faster if I write it in language X?
Earlier quoted context omitted.
Time running the app is both irrelevant compared to the time it takes to develop it. Also, as long as the app offers the answer quickly enough from the user's perspective, fast enough is fast enough and being able to iterate twice as fast as your competition is the ultimate advantage.
Making it fast enough from a user's perspective comes at a cost though (where it is possible at all). If you have many users and you have to pay that price for each one, it becomes very expensive. All I'm saying is that at some point it becomes way more expensive than paying developers to optimize or rewrite in a faster language, which is exactly why Google and Facebook are doing so much work in C++, not exactly a la…
I agree there are cases where only the leanest and meanest code will do, but my point is that those cases are very rare.
I remember seeing somewhere that someone looked into tackling the problem of the startup time by stripping the clojure core libs of unessential metadata like docstrings etc I'm not sure if they went through with it though
Earlier quoted context omitted.
if you mean clojure AOT, it precompiles clojure to jvm bytecode. Usually the term JIT in this context is used to describe the native code generated by the VM on the flight, not the on the flight VM bytecode generation performed by a higher level language like clojure. EDIT: sorry, probably your referred to http://publib.boulder.ibm.com/infocenter/java7sdk/v7r0/topic...
According to this link precompilation with AOT produces worse results than normal JIT execution. If so, what is AOT useful for? "Da AOT-Code über verschiedene Programmausführungen hinweg bestehen bleiben muss, ist die Leistung von mit AOT generiertem Code nicht so gut wie die von mit JIT generiertem Code."