[Melbourne-pm] Timer::HiRes and alarms? (Was: AI Contest)

[Scott Penrose]

On 12/11/2010, at 9:08 AM, Sam Watkins wrote:

> On Thu, Nov 11, 2010 at 11:04:49PM +1100, Mathew Robertson wrote:
>> complete and utter hogwash.
>> 
>> The algorithm is the important part, not the programming language.
> 
> Yes, the algorithm is most important, but given a C program with a good algorithm and a perl program with the same good algorithm, my money is on the C program, as it will have time to explore perhaps 100 times more possibilities in the game tree.

We used to run an informal competition at myinternet each year to see if someone could write a faster performing C program than a real world Perl application we had. Eg. FTP server, Memory cache, Database lookup, apache auth module ...

In every single case, the perl application was shorter, faster to write, and executed faster.

Now that said, technically, given unlimited time I am sure the C program could have been technically made to be faster - but it is just not a real world example, and the code ended up being larger, harder to maintain .... You can always optimise a case for a language though.

Some places there is just no argument. E.g. I would not like to write Perl for embedded CPUs. But I would not like to write C for web applications. But that is also my own personal bent.

I don't have any personal experience with Go, but my understanding is that it is very good at applications which work well as automatic threaded.

I have been reading performance testing across DB recently - specifically RDBMS vs SimpleDB - and all the performance testing is based on either very large tables (where SimpleDB slows down) or time for a query. None do the real testing I want which is to run 100 servers, each with at least a dozen concurrent instances all doing different requests. 

Scott