|
|
@@ -1132,11 +1132,12 @@ problem size is quadratic with the number of tasks and thus the time to solve it
|
|
|
will be very long, it could be minutes for just a few dozen tasks. You should
|
|
|
probably use @code{lp_solve} to convert the problem to MPS format and then
|
|
|
use a better solver, @code{glpsol} might be better than @code{lp_solve} for
|
|
|
-instance (the @code{--pcost} option may be useful), but sometimes doesn't manage to converge. Be sure to try all the @code{-B} options of @code{lp_solve}. Setting @code{deps}
|
|
|
-to 0 will only take into account the actual computations on processing
|
|
|
-units. It however still properly takes into account the varying performances of
|
|
|
-kernels and processing units, which is quite more accurate than just comparing
|
|
|
-StarPU performances with the fastest of the kernels being used.
|
|
|
+instance (the @code{--pcost} option may be useful), but sometimes doesn't manage to converge. Be sure to try all the @code{-B} options of @code{lp_solve}. For instance, we often just use @code{lp_solve -cc -B1 -Bb -Bg -Bp -Bf -Br -BG -Bd -Bs -BB -Bo -Bc -Bi}.
|
|
|
+
|
|
|
+Setting @code{deps} to 0 will only take into account the actual computations
|
|
|
+on processing units. It however still properly takes into account the varying
|
|
|
+performances of kernels and processing units, which is quite more accurate than
|
|
|
+just comparing StarPU performances with the fastest of the kernels being used.
|
|
|
|
|
|
Note that all this however doesn't take into account data transfer, which is
|
|
|
assumed to be completely overlapped.
|
