Changes between Version 21 and Version 22 of AppMultiThread

Timestamp:

Dec 30, 2008, 3:31:43 PM (15 years ago)

Author:

davea

Comment:

--

AppMultiThread

@@ -13 +13 @@
  * You want to reduce the turnaround time of your jobs (either because of human factors, or to reduce server occupancy).
 
-Writing and debugging a multi-threaded app is hard.
-You may be able to use languages like Titanium or Cilk,
-or libraries of multi-threaded numerical "kernels".
+You may be able to use CUDA, or languages like Titanium or Cilk,
+or libraries of multi-threaded numerical "kernels", to develop a multi-threaded app.
 
 == Deploying a multi-threaded app version ==
@@ -31 +30 @@
 {{{
 bool app_plan(SCHEDULER_REQUEST& sreq, const char* plan_class, HOST_USAGE& hu) {
-    // clients before 6.1.11 don't understand plan_class
-    //
-    int v = sreq.core_client_major_version*10000
-        + sreq.core_client_minor_version*100
-        + sreq.core_client_release;
-    if (v < 60111) return false;
-
     if (!strcmp(plan_class, "par64")) {
         int ncpus, nthreads;
@@ -55 +47 @@
 }
 }}}
-
-== Client scheduling policy ==
-
-Suppose an app A uses NT(A) threads.
-Ideally, on a host with N CPUs, we want
-NT(A), summed over running apps, to be at least N;
-otherwise CPU time is wasted.
-However, if it's much more than N,
-we increase latency without increasing throughput,
-we may increase synchronization overhead,
-and we may use more RAM than needed.
-
-Given a list of runnable applications (ordered by priority or deadline),
-the CPU scheduler runs applications until the number of threads reaches a limit.
-If the user has specified a limit N on the number of CPUs to use,
-the number of threads cannot exceed N.
-Otherwise, the scheduler stop when the number of threads is >= NCPUS.
-