Key Information

Register
Submit
The challenge is finished.

Challenge Overview

We are looking for clear and cogent ideas for how to achieve the most optimal marathon match contest given the criteria below.

Currently, we plan on using a [topcoder] marathon match to develop software that runs very fast on a board with an ARM chip and running the Quadros Real-time OS. The specifics of the runtime and build environment are detailed in the software guidlines.

You should keep in mind code optimization contests designed for the following example problem:

Jalapenos can be very irritating when present in pizza slices. Busy programmers don’t see it and unwittingly bite into it only to regret it later. Our client wants to develop an app that can detect the presence of this ingredient quickly before a programmer takes the first bite. So we need an algorithm to very rapidly (in a few ms) and accurately detect the presence of a jalapeno in the picture of a pizza slice - 1000 images are available for this contest with some withheld for provisional and system testing. We need an algorithm that is fast and accurate. 

Your submission should be an assessment of the following criteria:

  • how closely the results from the marathon contest match what’s needed for the ARM environment.

  • how low-risk the entire process is. We need an algorithm that works fast and is reasonably accurate on the target ARM environment described above.

One tentative strategy is to run a marathon contest where:

  • the language is restricted to C/C++

  • memory allocation is disallowed - a static memory buffer is provided. We currently don't have a method to automatically disallow memory allocation, this will be a manual verification process on the best marathon match solutions.

  • one of more bug-races to convert the code to run on the target ARM environment

The ideal strategy we would be able to enforce:

  • no intrinsics and no SSE (since it appears SSE may not be easily portable into ARM)

  • re-entrant code

  • no dynamic memory allocation (all memory allocation must be done with 2MB of memory buffer provided to the contestants)

  • limited stack memory

  • portability to the ARM platform

  • limit only to the following library includes: string.h, ctype.h, math.h

What to submit

Please submit a document containing one or more strategies. (How and what should we do to make the marathon match solutions runable on the ARM platform as best as possible? How risky would this be ?) 

Any widely supported document format will be accepted, such as OpenDocument, RTF, HTML

You may explain your decisions, offer alternate choices, and suggest further ways to improve our strategy.



Final Submission Guidelines

Our Targeted Execution Platform:

  • ARM Cortex A9 with 32KB of L1 instruction cache, 32KB of L1 data cache, 512KB of L2 cache. (Please note that only one core is available to run the Algorithm.) http://www.xilinx.com/publications/prod_mktg/zynq7000/Zynq-7000-combined-product-table.pdf
  • NEON, SIMD etc. - The Cortex-A9 NEON MPE extends the Cortex-A9 functionality to provide support for the ARM v7 Advanced SIMD and Vector Floating-Point v3 (VFPv3) instruction sets. The Cortex-A9 NEON MPE supports all addressing modes and data-processing operations described in the ARM Architecture Reference Manual.

  • Quadros Real-Time OS

Our Targeted Build Environment:

  • We use the ARM DS-5 IDE – current version is 5.17, “armcc” is the compiler – current version is 5.04

  • NEON SIMD intrinsics are available to application code through  #include <arm_neon.h> library.

Marathon contest Environment:

  • Linux on Intel
  • Physical hardware is 8-way 2.3 GHz Intel Xeon E5345.

 

REVIEW STYLE:

Final Review:

Community Review Board

Approval:

User Sign-Off

SHARE:

ID: 30042874