Is it me or does Hardy run like a pig?

Ignazio Palmisano ignazio_io at yahoo.it
Thu Oct 16 14:12:00 UTC 2008


Knapp wrote:
>> "Then there are all the new languages. They make coding faster and less
>> buggy but they don't make it more efficient or smaller."
>>
>> Faster is not more efficient? Smaller as in memory size, I agree, that's
>> important, but less buggy, from my point of view, is the jackpot.
> 
> Faster CODING (as in writing the program not running it) is great, if
> you need to get something done,  less buggy more so, but when I say
> efficient and smaller, I am talking about the final code that the
> computer runs being smaller and more efficient.

Sorry but that wasn't obvious from the original post :)

> 
> There are at least two kinds of optimizations. There is the sort, like
> unrolling loops and such that lead to really bad to read but fast code
> and then there are they really important kind that comes WITH the
> design. A good example of this would be list sorting. You can use a
> bubble sort and it is easy to understand, it is easy to sell to your
> boss and it will be bug free most times. It is a good sort. BUT, then
> there is the quick sort. I still think it is magick! How does that
> really work?? Yes, I know how to write it but still, who ever invented
> it was a GREAT programmer! This is the sort of programming that we
> would really like to have for everything we write. Alas most
> programmers are not great programmers and most programs written by
> poor programmers will have bubble sort sort of code in them and no one
> will ever fix it.

Unrolling loops, making sure you don't write outside array bounds, 
making sure your strings are safe etc etc... that's the kind of 
optimizations that work great in the compiler or in the interpreter. 
Developer time and ability would be wasted there, where the compiler can 
do a better job in a split second time (and those are some of the 
optimizations Java does :P that's the language I love, sorry...)

> I think that if someone can ever write a python compiler that known
> when to treat the code like C and when to just let it be, we will have
> the best of both worlds. I looks like this is an AI nightmare at this
> point.

:D why so? optimizing compilers is quite a matter of knowing what costs 
a lot and how to circumvent around it. No need for AI (where stuff as 
inefficient as bubble sort is regarded as blazing fast :) trust me, some 
theoretical AI professors won't flinch if their algorithms turn out to 
be exponential. They have more complexity classes above exponential than 
below)

Long story short, Derek says a gig of ram costs less than one day work. 
That's true in most places, not everywhere, but the general advice is: 
make it nice and pretty and efficient, but don't obsess about that. The 
real cost is likely somewhere else.
I.




More information about the kubuntu-users mailing list