With the recent surge of golf posts, i was interested in the tricks that would come up. So i decided to copy/paste the solutions to a few different golfs into a file and set up a run or two. The first time i tried this, i was disturbed that nothing happened. After further searching i found that some of the algorithms provided in golf are so slow that they can cause machine-grinding halting for any large problem space.

My general inquiry then is: Would people be interested in a golf problem that asked for a reduction of time to solve the problem? There would be no need for a formal proof of shortness, just a listing of the benchmark or some such. i've seen merlyn and others stating sometimes one solution is better than another because it uses fewer instructions. This type of golf would be the extreme of that type of thinking, and best solutions would usually not include recursion and extraneous loops.

Methinks it's an interesting idea and worth consideration since often it's more worthwhile to optimize code than it is to shrink it's size. As a tag for the posts' title i thought of maybe [frisbee golf], but that's subject to change...

Benchmarking is a good way to understand how Perl works and how to distinguish good code from bad code. However the sole requirement of Perl Golf is to achieve the desired effect in the least number of characters. Efficiency doesn't come into it. If anything that sport would be sprinting.

This is not to say that I wouldn't like to see benchmark comparisons of code, just that it isn't Golf. Call it Perl 100m or something else. :-)

I like 'Perl 100m dash', but I think it's too specific. Perl Track and Field is too general--maybe Perl Track? Or just Sprints (as has been elsewhere suggested). Judging it might be tough, but whereas some things are faster on some systems than others, a lot of what gets golfed is more system-independent anyway (recursion is slower than iteration no matter where you are).

I kinda like the idea of a more general Perl Track and Field, actually--what would the Javelin be like?

If God had meant us to fly, he would *never* have give us the railroads.
--Michael Flanders

It's a good idea. Some of the stuff that happens in golf
solutions is just Wrong from any reasonable point of view.
Only problem is, different machines do different things
at different speeds, so what's fast on a Sparc may not be
the fastest thing on an Intel box. Even with the same family
of processor, a slow machine might be CPU bound while a fast
one is memory bound. There's no such thing as the fastest
script overall, you can only say which is the fastest on
each particular machine.

Sounds good to me!
I think that code that saves me keystrokes and runs fast is the most valuable there is.
Unless we want to have: fewest keystrokes, runs quickly, and is understandable. Of course being understandable is
open to interpertation.

Great idea! I'd love to pick up more techniques on optimising my code. This would be really valuable to me, and a lot of others here I'm sure, and a lot of the techniques would be immediately applicable to work.

I'm not so interested in the obfuscated perl as, although it is cool, I have to write maintainable code and my co-workers aren't experts (basically I don't want to get into 'bad' habits).

Judging it will be hard as machines/os's will vary in speed, floating point efficiency etc. Shortest version means it currently is pretty easy to work out the winner, does it work and how long is it?

Maybe some use of benchmarking contrasting the versions on your own PC?

A variant of the Test:Harness should be able to do this. If submitteers just provide the snippet of code, then the harness can do all the timing, generate statistics and ensure common test files, etc.
There are also some subtleties between improvements in speed derived from better algorithms and those derived from implementing the same algorithm better.

For example one race could be "Write a fast quicksort routine", vs. "write a fast sort routine". In the first case, the winner will be the one who programs the algorithm best, in the latter case it will be the one who comes up with the algorithm best suited to the data.

In some cases, whether the test data is given with the challenge will be important to the outcome.

Re: machine variations: I wouldn't expect the machine variation to matter as much as the algorithm / coding variation. I.e. the fastest algorithm one one machine is likely to be the fastest on any machine.
--Brovnik.

One would also have to be clear as to how many iterations the 'challenge' was for. For example, a linked list may be faster for some applications, but the time involved in setting it up would take it out of the running for one iteration (while a hash that is much slower, might win).

Oh, and I like the idea of perl sprints. Especialy regex sprints and prime number sprints.

I like the idea, since I sometimes wonder which construct is better at some specific task. Using Perl's high-level stuff is the way to get speed out of it, since that would be needed anyway in C++ and the overhead of the call is insignificant.