Traditional compilers, computer programs that translate computer code written in one programming language (the source language) into another language, are not designed to generate efficient machine code for heterogeneous ensembles of central processing units (CPUs), graphics processing units (GPUs), and other application accelerators.
Instead, software developers must write unique code and libraries to take advantage of specialized hardware, thereby encouraging vendor lock-in and losing much of the potential benefit of these hardware components. Extending compilers to handle new computational elements is currently a manual task performed by compiler experts. Adapting current compilers is time-consuming and error-prone, does not address the challenge of taking advantage of a heterogeneous ensemble of hardware accelerators, and limits our ability to upgrade mission-critical systems in a timely manner.
Machine learning and Optimization-guided Compilers for Heterogeneous Architectures (MOCHA) aims to usher in a new era of compiler technology that could unleash the performance potential of systems with multiple heterogeneous computational elements. DARPA hypothesizes that by leveraging data-driven methods, machine learning (ML), and advanced optimization techniques, one can rapidly adapt compilers to new hardware components with minimal human intervention.
Additionally, MOCHA will develop new internal representations and programming languages that empower compilers to determine the optimal use of available hardware, eliminating the need for human intervention in this process. This transformative approach could liberate the Department of Defense and the commercial world from the constraints of current compiler technologies, enabling them to fully and rapidly capitalize on emerging and custom specialized hardware.
One key insight motivating the MOCHA program is that performance models of the target computational elements and communication fabric drive each step of the compilation process. Building these models by hand is a bottleneck MOCHA intends to address by enabling rapid adaptation of compilers to novel CEs and novel ensembles of existing components.
The MOCHA program's premise is that these models can be generated using data-driven and ML techniques and that these techniques will be relatively inexpensive in terms of the time it takes a person to collect and curate data. Instead of a human-driven process, the MOCHA approach would generate code and measure its performance on the target computational elements or to mine architectural documents for the relevant performance information.
A Broad Agency Announcement solicitation with comprehensive program details is available on SAM.gov.
FAQs
As of September 12, 2024
30. Q: Is it possible to include support letters with the proposal submission without it counting against the maximum proposal page count?
A: Additional information not explicitly called for in the Technical and Management Volume must not be submitted with the proposal but may be included as links in the bibliography. Such materials will be considered for the reviewers’ convenience only and not evaluated as part of the proposal. The bibliography has a 5-page limit, but this is in addition to and does not count against the 25-page limit for the Technical and Management Volume.
29. Q: For the 3-year program schedule, how should costs be budgeted in the cost spreadsheet?
A: Costs for the entire 3-year schedule should be entered into the base period worksheet. Costs for any additional proposed effort outside of the 3-year base should be included in the options worksheet. The Cost Model spreadsheet is a template not specific to any one program, so hide any rows and columns in the spreadsheet that are not applicable.
28. Q: The BAA references three "performance figures of merit." Are these metrics considered equally important, and are performers expected to address all of them?
A: Yes, to both questions.
27. Q: Should all subaward information be put into one budget excel and volume II justification or have only the total numbers in the prime budget information and submit separate forms for the subawards?
A: The Volume II (Cost) proposal submitted by the prime contractor should include all costs for the proposed effort. If needed, unsanitized, detailed sub-awardee costs can be submitted to MOCHA@darpa.mil, but include the sanitized subcontractor proposal with the prime’s proposal submission.
26. Q: Should the Statement of Work (SOW) tasks and Schedule of Milestones be broken down by Contractor Fiscal Year or Program Execution Year?
A: SOW tasks and the Schedule of Milestone tasks should be broken down by Program Execution Year. Budget (cost) proposals can note what day/month annual escalations are applied by contractor fiscal year.
25. Q: Given the delay in providing feedback on the Abstracts, will additional time be given for submitting proposals?
A: Yes. An Amended BAA with revised due dates has been posted to sam.gov and grants.gov.
As of August 19, 2024
24. Q: Is compiling for nodes with multiple accelerators in scope for the program (e.g., a box with 4 or 8 GPUs in additions to CPUs), or is the focus on compilation only for single accelerators?
A: Compute elements containing multiple accelerators are in scope. Keep in mind that the government team will decide which processors, accelerators, and compute elements will be added to the program over time.
23. Q: The BAA lists memory footprint as one of the performance criteria that will be used in assessments. Does memory footprint refer to code size, data size, or some other aspect of MOCHA compiler output?
A: There are applications for which ROM and RAM are strictly limited and this metric is intended to measure a compiler’s ability to make best use of a static, fixed amount of memory available to a targeted system. The specifics of how this will be measured have not yet been defined and could involve a mixture of both.
As of August 9, 2024
22. Q: The Program Structure slide from the Proposers Day briefing includes several “parts” bullets under ML-based generators. Can you provide a brief definition of those parts?
A: The bullets are intended to be suggestive of distinct components of a compiler toolchain. See Technical Area discussion beginning on p. 6 of the BAA for more discussion.
21. Q: Can a proposer be in two different proposals if the PI works on different aspects?
A: As long as the same work would not be duplicative and funded multiple times, there is nothing to prevent an individual or institution from being named in multiple proposals or performing under multiple awards.
20. Q: The BAA states that there are two metrics, human effort reduction and performance. Performance is further specified to encompass throughput, power, and memory. How will these be weighted by the program?
A: Refer to Figure 5 in the BAA. How the different dimensions of performance will be combined in years 2 and 3 of the program has not been determined.
19. Q: In what languages will the program challenge problems be written? A: This has not yet been determined.
18. Q: Is C or python considered a hardware-agnostic language? A: These can be hardware-agnostic languages when programs are appropriately written.
17. Q: Will hardware-agnostic languages be developed by performers or comprise some set of existing languages? A: Both are possible. Proposals that address language development are in scope.
16. Q: How important is stability of compiler output given small changes in input programs? A: It would be valuable for people developing code, but it is not a program evaluation criterion.
15. Q: Is verification/validation of optimizations and/or compiler output a priority? A: It is highly desirable that optimizations be validated.
14. Q: Is formal verification of compiler correctness in scope? A: Yes.
13. Q: Are there specific application domains and benchmarks that will be driving this program? Will proposers have this information before the abstract deadline? A: This will be addressed within the program. No choices will be made before the abstract deadline. If your solution is dependent on specific application domains, identify this in your proposal.
12. Q: Is the development of novel ML a primary goal of MOCHA? A: It is in scope, if clearly relevant to the MOCHA challenges, but application of existing tools and techniques to the MOCHA challenges is also in scope.
11. Q: Is MOCHA strictly looking for machine learning (ML) solutions or are other optimizations in scope? A: While ML is applicable, it is not the only approach. Other optimization approaches are anticipated to be applicable to some of the MOCHA challenges.
10. Q: Conventional languages typically build on some assumptions about architecture. What programming language considerations are in scope for this program? A: Proposals for new languages are in scope. Proposals to use or extend existing languages are also in scope and interactions between teams will be handled when the program is underway.
9. Q: What does compiler annotation mean to MOCHA? A: Anything a human has to write, in addition to a given input program to get the desired output from the system.
8. Q: Is using feedback from the compiler, for example when adapting an application to run on an accelerator, in scope? A: Yes. Code changes made in response to compiler feedback would be part of what’s measured as human effort.
7. Q: Evaluation criteria are speed, power, and code size; what if compile time is very long? A: Compile time is not one of the factors being evaluated by MOCHA.
6. Q: Are any computational elements or communication fabrics out of scope? A: No. However, the government – in collaboration with performers – will determine what computational elements (CEs) and communication pathways are employed by the program.
5. Q: Who is responsible for ensuring compatibility across teams for evaluations? A: This will be determined by performers and the government team. One reason the Associate Contractors Agreement is required is to facilitate this sort of collaboration.
4. Q: What is the expected budget? A: Propose what you believe is necessary.
3. Q: Are there any constraints on the resources needed to develop a compiler toolchain (e.g., training time or cost)? A: No. Proposals should include all resources you believe will be needed.
2. Q: How long between abstract submission and feedback? A: DARPA’s objective is to provide feedback within 2 weeks of the submission deadline.
1. Q: Are FFRDCs allowed to participate as performers? A: See Section IV: Special Considerations of the BAA.