Home > Uncategorized > Is your interesting project on hold because of lack of sufficient cpu time?

Is your interesting project on hold because of lack of sufficient cpu time?

Do you have an interesting project that is stalled because of lack of cloud compute resources? If so I know some guys who may be able to help.

One of the prizes at a recent hackathon was around $8k of cloud computing per month for a year. The guys who won it have not been using the monthly allowance and would like to put it to good use.

What counts as an “interesting project”? You are dealing with hackers who enjoy working at the edge of things and want to be involved in a project that impresses other hackers (here ‘involved’ means telling other people they are involved, not actually helping you with the project in any way). While it is obviously a project that uses computers it does not have to be about computing. Helping your me-to-startup is very unlikely to be interesting.

Hackers are fans of open data, so you will have to have a very good reason not to make any data you produce public.

Send me an email briefly describing your project, why it needs this cloud computing resource and show that you will not fritter it away because you don’t know what you are doing.

The clock is ticking.

  1. Vasileios
    June 10th, 2015 at 23:42 | #1

    Hi Derek! We could use this for running the LLVM test-suite for different targets/opt-levels under Qemu. If you need more information send me an email. I’m one of the main LLVM developers for MIPS.

  2. June 11th, 2015 at 00:06 | #2

    Does this testing require that much cpu? Previous compiler tests suites I’ve used have taken hours to run, but I have never run the LLVM suite. This task would be useful, but does not sound that interesting. But you never know, if nothing interesting comes along, useful is always useful.

  3. Vasileios
    June 11th, 2015 at 09:53 | #3

    @Derek Jones

    > Does this testing require that much cpu?

    Given that my experience is on the MIPS back-end, consider this: 3 ABIs (O32/N32/N64), 2 ISAs (R2/R6), 32/64 bit, 6 optimization levels, little/big endianness = 144 different configurations that test significantly different code paths. Ideally, we would like to achieve per commit granularity in the runs of the LLVM test-suite. Currently, there are about 60 commits/day and bisecting nightly failures requires too much time.

    If we don’t run out of CPUs then we can always use multiple libfuzzer, csmith & llvm-stress instances to help us towards this goal! :)

  1. No trackbacks yet.

A question to answer *