commit bac7f922aa350e98d9c28d18cd45a93b7ba6259a
Author: Rodolphe Bréard <v.code.ngyvz7vf@what.tf>
Date:   Sun Oct 27 18:41:19 2024 +0100

    First commit

diff --git a/.gitignore b/.gitignore
new file mode 100644
index 0000000..2e2fef1
--- /dev/null
+++ b/.gitignore
@@ -0,0 +1,11 @@
+# Rust files
+/.cargo
+/target
+**/*.rs.bk
+Cargo.lock
+
+# Backup files
+*~
+\#*
+.\#*
+*.swp
diff --git a/Cargo.toml b/Cargo.toml
new file mode 100644
index 0000000..3ba7f96
--- /dev/null
+++ b/Cargo.toml
@@ -0,0 +1,10 @@
+[package]
+name = "rust_job_scheduling"
+version = "0.1.0"
+authors = ["Rodolphe Breard <rodolphe@what.tf>"]
+edition = "2021"
+description = "Benchmark of several job scheduling algorithms implemented in Rust."
+license = "MIT OR Apache-2.0"
+publish = false
+
+[dependencies]
diff --git a/README.md b/README.md
new file mode 100644
index 0000000..cf38213
--- /dev/null
+++ b/README.md
@@ -0,0 +1,51 @@
+# Job scheduling. Using Rust.
+
+Benchmark of several job scheduling algorithms implemented in Rust.
+
+
+## The problem
+
+We have a list of independent tasks that we want to execute as fast as
+possible. In order to achieve this, we want to run then in parallel. However,
+those tasks have different execution times that can vary from several orders of
+magnitude. Fortunately, it is possible to estimate the execution time of each
+task before running it.
+
+The goal is therefore to schedule the execution of the tasks on all available
+threads in such a way that minimizes the total running time. This is known as
+the [optimal job scheduling problem][ojs problem] and can often be seen as a
+[partition problem][part problem], which is known to be
+[NP-complete][NP-complete].
+
+[ojs problem]: https://en.wikipedia.org/wiki/Optimal_job_scheduling
+[part problem]: https://en.wikipedia.org/wiki/Partition_problem
+[NP-complete]: https://en.wikipedia.org/wiki/NP-completeness
+
+### Example
+
+If we have 4 tasks tasks to execute. Three of then takes 1 second each to
+execute and the last one takes 3 seconds. We have 2 processing units of equal
+power.
+
+If each processing unit starts by executing one of the 1s tasks, they will both
+finis this job after one second. Then, one of those processing unit will
+execute the remaining 1s task while the other will execute the 3s task. At the
+end, one processing unit would have ran 2 seconds and the other one 4 seconds.
+The total time is therefore 4 seconds.
+
+Instead, we could start having one processing unit to execute the 3s task and
+the other one execute the three 1s task. At the end, both processing units
+would have ran 3 seconds. The total time is therefore 3 seconds.
+
+The second job scheduling was clearly better than the first one, resulting in
+zero idling processing unit and therefore the shortest total execution time.
+
+
+## Goal
+
+Talking about job scheduling algorithms and all the cool stuff you can use to
+implement them in an efficient way is one thing. Actually implementing them and
+gathering data on how it actually went in a real situation is another.
+
+This project choses the later and therefore aims to implement several of those
+algorithms in Rust and benchmark them. Let the battle begin.
diff --git a/rustfmt.toml b/rustfmt.toml
new file mode 100644
index 0000000..218e203
--- /dev/null
+++ b/rustfmt.toml
@@ -0,0 +1 @@
+hard_tabs = true
diff --git a/src/lib.rs b/src/lib.rs
new file mode 100644
index 0000000..e69de29