Problems
Handbook - Execution mode

There are two different modes in which the Sphere Engine Problems module can execute a submission:

• isolated mode - ensures complete independence of test case execution and provides the utmost flexibility in selecting problem components,
• fast mode – a more efficient alternative for cases where execution independence is not a critical requirement.

The following sections explain how to set the execution mode, the differences between the modes, and the limitations of fast mode that do not apply to isolated mode.

Setting the execution mode

The primary method of setting the execution mode is through the problem scope. This can be done in two ways:

• in the Sphere Engine Problems Editor:
  • navigate to Problems -> Editor in the left-hand menu,
  • locate "Common settings" under Edit -> Test cases for a specific problem,
• via API requests using the executionMode parameter:
  • POST /problems ,
  • UPDATE /problems/:id .

The secondary method for defining the execution mode is at the submission level, overriding the problem settings. You can specify the execution mode using the executionMode parameter in the POST /submissions API request.

Isolation mode

Submissions executed in isolation mode go through a series of independent stages. For each stage, a dedicated, isolated sandbox environment is created.

Every Sphere Engine Problems submission undergoes the following stages:

• (for compiled languages) submission compilation,
• for each test case:
  • submission execution,
  • (for compiled languages, if not yet cached) test case judge compilation,
  • test case judge execution,
• (for compiled languages, if not yet cached) master judge compilation
• master judge execution,

For a programming problem with six test cases, where all components (test case judge, master judge) do not require compilation, a Rust submission undergoes the following stages:

• submission compilation
• submission execution for test case #1
• test case judge execution for test case #1
• submission execution for test case #2
• test case judge execution for test case #2
• submission execution for test case #3
• test case judge execution for test case #3
• submission execution for test case #4
• test case judge execution for test case #4
• submission execution for test case #5
• test case judge execution for test case #5
• submission execution for test case #6
• test case judge execution for test case #6
• master judge execution

Each of these 14 stages occurs in a separate sandbox, ensuring secure, reliable, and independent execution.

Independent execution of stages provides:

• high repeatability of submissions,
• precise execution time and memory consumption measurements,
• flexibility in combining components using different programming languages and versions,
• full resource allocation (CPU, RAM, disk) for a submission.

This approach introduces a time overhead, as each stage requires a separate sandbox environment.

Fast mode

The fast mode is designed to reduce submission execution time by running all stages within a single sandbox environment.

In this mode, sandbox-related overhead is minimized, making it particularly beneficial for problems with numerous test cases. However, this comes with trade-offs:

• slightly lower execution repeatability,
• moderate precision of execution time and memory consumption measurements,
• limited ability to mix components written in different programming languages or versions,
• shared resource allocation (CPU, RAM, disk),
• reduced output data size limit.

Fast mode limitations

• maximum submission output size per test case: 10MB,
• programming language requirements:
  • submission language version 5 or later (e.g., Python 3.12, language ID 116 in version 8),
  • test case judges and master judges languages must be present in the same version as submission's language,
  • judges' code must be compatible with the submission's language version.

Comparison

The table below summarizes the differences between the two execution modes: