[DFW.pm] contest optimization strategy clarifications - BRING IT

[Tommy Butler]

Hi,

With all the recent list sign-ups we've had some questions raised
off-list.  I'd like to address these one time, for the group, instead of
one-by-one.  The questions:

 1. I want to write to a *destroyed-on-exit* in-memory database (SQLite)
    or *destroyed-on-exit *tied hash (BDB) = THIS IS OK
 2. My code depends on modules that write temp files that persist
    between executions = THIS IS BENT*
 3. My code requires a C compiler on the system = THIS IS BENT**

If your code/design looks like item number 1 in the list above, we're
not so concerned about your tied hash writing to the filesystem or
/dev/shm because we've decided to completely roll back the server before
every code execution that happens.  Yup.  It will take mere seconds to
roll back the server to its state before any code ran.  Because of this,
we still discourage other kinds of disk-writes; we'd rather not deviate
from rules around which existing code has already been designed.  We're
just going to make darn sure that any sneaky disk writes are completely
non-existent between your test runs.  Fairness must be assured.

**Now if your code falls into a "THIS IS BENT" category, you're still
welcome to compete, and even win, but _you'll be doing so in a separate
competition category_, simply called "rule benders".

Why allow rule benders?  Because we still want to see how fast things
can go.  We asked for a Pure Perl solution, with the only exception
being that your code could depend on XS-based (that means compiled C
extensions) modules from the CPAN that were released /prior/ to the
beginning of the hackathon.  Strangely enough, those rules get blurry
when you start using CPAN modules that depend on Inline::C or that
otherwise need access to a C compiler on the system at the time when the
code runs.

To John and I, this is a type of code optimization that isn't based on
Perl, but instead based on C.  You can argue how much of it is Perl and
how much of it is C in terms of lines of code in one language or the
other, but you can't really easily prove how much of the performance
gains were Perl-based and how much of them were XS-based) and we aren't
going to NYTprof your code just to find out.

What it comes down to in terms of fairness is that Perl code which might
have lost the competition on its own will then have won by virtue of the
inclusion of low-level optimizations that just aren't in keeping with
the spirit of the contest as it was intended -- but which are still
awesome!  We'd like to see what can be achieved through this kind of
go-baby-go, nitrous-oxide-injected, turbocharged Perl, but in your own
category of competition.

So go for it.  If you want to be a bender, let's see what you've got. 
Bring it, benders.

--Tommy Butler, John Fields


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.pm.org/pipermail/dfw-pm/attachments/20131223/380b4d22/attachment.html>