Changeset 31b9d3c for doc/theses/thierry_delisle_PhD/thesis/text
- Timestamp:
- Aug 29, 2022, 4:32:35 PM (2 years ago)
- Branches:
- ADT, ast-experimental, master, pthread-emulation
- Children:
- a8dd247, e173d3c
- Parents:
- 507d48d
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
doc/theses/thierry_delisle_PhD/thesis/text/eval_micro.tex
r507d48d r31b9d3c 42 42 Each experiment is run 15 times varying the number of processors depending on the two different computers. 43 43 All experiments gather throughput data and secondary data for scalability or latency. 44 The data is graphed using a solid and two dashed linesrepresenting the median, maximum and minimum result respectively, where the minimum/maximum lines are referred to as the \emph{extremes}.\footnote{44 The data is graphed using a solid, a dashed and a dotted line, representing the median, maximum and minimum result respectively, where the minimum/maximum lines are referred to as the \emph{extremes}.\footnote{ 45 45 An alternative display is to use error bars with min/max as the bottom/top for the bar. 46 46 However, this approach is not truly an error bar around a mean value and I felt the connected lines are easier to read.} … … 51 51 In this representation, perfect scalability should appear as a horizontal line, \eg, if doubling the number of \procs doubles the throughput, then the relation stays the same. 52 52 53 The left column shows results for 100 cycles per \proc, enough cyclesto always keep every \proc busy.54 The right column shows results for 1 cycleper \proc, where the ready queues are expected to be near empty most of the time.55 The distinction between 100 and 1 cycles is meaningful because the idle sleep subsystem is expected to matter only in the right column, where spurious effects can cause a \proc to run out of work temporarily.53 The left column shows results for hundreds of \ats per \proc, enough to always keep every \proc busy. 54 The right column shows results for very few \ats per \proc, where the ready queues are expected to be near empty most of the time. 55 The distinction between many and few \ats is meaningful because the idle sleep subsystem is expected to matter only in the right column, where spurious effects can cause a \proc to run out of work temporarily. 56 56 57 57 \section{Cycle} … … 101 101 \caption[Cycle Benchmark : Pseudo Code]{Cycle Benchmark : Pseudo Code} 102 102 \label{fig:cycle:code} 103 %\end{figure} 104 105 \bigskip 103 %\end{figure}ll have a physical key so it's not urgent. 104 106 105 107 106 %\begin{figure} … … 131 130 \label{fig:cycle:jax:low:ns} 132 131 } 133 \caption[Cycle Benchmark on Intel]{Cycle Benchmark on Intel\smallskip\newline Throughput and scalability as a function of \proc count, 5 \ats per cycle, and different cycle count. For throughput, higher is better, for scalability, lower is better. Each series represent 15 independent runs, the dotted lines are maximums while the solid line is the medium.} 132 \caption[Cycle Benchmark on Intel]{Cycle Benchmark on Intel\smallskip\newline Throughput and scalability as a function of \proc count, 5 \ats per cycle, and different cycle count. 133 For throughput, higher is better, for scalability, lower is better. 134 Each series represent 15 independent runs, the dashed lines are maximums of each series while the solid lines are the median and the dotted lines are the mnimums.} 134 135 \label{fig:cycle:jax} 135 136 \end{figure} … … 161 162 \label{fig:cycle:nasus:low:ns} 162 163 } 163 \caption[Cycle Benchmark on AMD]{Cycle Benchmark on AMD\smallskip\newline Throughput and scalability as a function of \proc count, 5 \ats per cycle, and different cycle count. For throughput, higher is better, for scalability, lower is better. Each series represent 15 independent runs, the dotted lines are extremes while the solid line is the medium.} 164 \caption[Cycle Benchmark on AMD]{Cycle Benchmark on AMD\smallskip\newline Throughput and scalability as a function of \proc count, 5 \ats per cycle, and different cycle counts. 165 For throughput, higher is better, for scalability, lower is better. 166 Each series represent 15 independent runs, the dashed lines are maximums of each series while the solid lines are the median and the dotted lines are the mnimums.} 164 167 \label{fig:cycle:nasus} 165 168 \end{figure} … … 167 170 \subsection{Results} 168 171 169 For the Intel architecture, Figure~\ref{fig:cycle:jax}: 170 \begin{itemize} 171 \item 172 For 100 cycles per \proc (first column), \CFA, Go and Tokio all obtain effectively the same throughput performance. 172 Figure~\ref{fig:cycle:jax} and \ref{fig:cycle:nasus} show the results for the cycle experiment. 173 Looking at the left column on Intel first, Figure~\ref{fig:cycle:jax:ops} and \ref{fig:cycle:jax:ns}, which shows the results for many \ats, in this case 100 cycles of 5 \ats for each \proc. 174 \CFA, Go and Tokio all obtain effectively the same throughput performance. 173 175 Libfibre is slightly behind in this case but still scales decently. 174 As a result of the \gls{kthrd} placement, additional \procs from 25 to 48 offer less performance improvement (flatting of the line) for all runtimes. 176 As a result of the \gls{kthrd} placement, additional \procs from 25 to 48 offer less performance improvement for all runtimes, which can be seen as a flatting of the line. 177 This effect even causes a decrease in throughput in libfibre's case. 175 178 As expected, this pattern repeats again between \proc count 72 and 96. 176 \item 177 For 1 cycle per \proc, \CFA and Tokio obtain very similar results overall, but Tokio shows more variations in the results. 178 Go achieves slightly better performance. 179 180 Looking next at the right column on Intel, Figure~\ref{fig:cycle:jax:low:ops} and \ref{fig:cycle:jax:low:ns}, which shows the results for few threads, in this case 1 cycle of 5 \ats for each \proc. 181 \CFA and Tokio obtain very similar results overall, but Tokio shows more variations in the results. 182 Go achieves slightly better performance than \CFA and Tokio, but all three display significantly workst performance compared to the left column. 183 This decrease in performance is likely due to the additional overhead of the idle-sleep mechanism. 184 This can either be the result of \procs actually running out of work, or simply additional overhead from tracking whether or not there is work available. 185 Indeed, unlike the left column, it is likely that the ready-queue will be transiently empty, which likely triggers additional synchronization steps. 179 186 Interestingly, libfibre achieves better performance with 1 cycle. 180 \end{itemize} 181 182 For the AMD architecture, Figure~\ref{fig:cycle:nasus}, the results show the same story as on the Intel, with close to double the performance overall but with slightly increased variation. 187 188 Looking now at the results for the AMD architecture, Figure~\ref{fig:cycle:nasus}, the results show a story that is overall similar to the results on the Intel, with close to double the performance overall but with slightly increased variation and some differences in the details. 189 Note that the maximum of the Y-axis on Intel and AMD differ significantly. 190 Looking at the left column first, Figure~\ref{fig:cycle:nasus:ops} and \ref{fig:cycle:nasus:ns}, unlike Intel, on AMD all 4 runtimes achieve very similar throughput and scalability. 191 However, as the number of \procs grows higher, the results on AMD show notably more variability than on Intel. 183 192 The different performance improvements and plateaus are due to cache topology and appear at the expected \proc counts of 64, 128 and 192, for the same reasons as on Intel. 184 \begin{itemize} 185 \item 186 For 100 cycles per \proc, unlike Intel, all 4 runtimes achieve very similar throughput and scalability. 187 \item 188 For 1 cycle per \proc, unlike on Intel, Tokio and Go have the same throughput performance, while \CFA is slightly slower. 189 Again, the same performance increase for libfibre is visible. 190 \end{itemize} 193 Looking next at the right column, Figure~\ref{fig:cycle:nasus:low:ops} and \ref{fig:cycle:nasus:low:ns}, Tokio and Go have the same throughput performance, while \CFA is slightly slower. 194 This is different than on Intel, where Tokio behaved like \CFA rather than behaving like Go. 195 Again, the same performance increase for libfibre is visible when running fewer \ats. 191 196 Note, I did not investigate the libfibre performance boost for 1 cycle in this experiment. 192 197 193 198 The conclusion from both architectures is that all of the compared runtime have fairly equivalent performance for this micro-benchmark. 194 Clearly, the pathological case with 1 \at per \proc,can affect fairness algorithms managing mostly idle processors, \eg \CFA, but only at high core counts.199 Clearly, the pathological case with 1 cycle per \proc can affect fairness algorithms managing mostly idle processors, \eg \CFA, but only at high core counts. 195 200 For this case, \emph{any} helping is likely to cause a cascade of \procs running out of work and attempting to steal. 196 For this experiment, the \CFA scheduler has achieved the goal of obtaining equivalent performance to other less fair schedulers , except for very unusual workloads.201 For this experiment, the \CFA scheduler has achieved the goal of obtaining equivalent performance to other less fair schedulers. 197 202 198 203 \section{Yield} … … 246 251 \label{fig:yield:jax:low:ns} 247 252 } 248 \caption[Yield Benchmark on Intel]{Yield Benchmark on Intel\smallskip\newline Throughput and scalability as a function of \proc count, using 1 \ats per \proc. For throughput, higher is better, for scalability, lower is better. Each series represent 15 independent runs, the dotted lines are extremes while the solid line is the medium.} 253 \caption[Yield Benchmark on Intel]{Yield Benchmark on Intel\smallskip\newline Throughput and scalability as a function of \proc count. 254 For throughput, higher is better, for scalability, lower is better. 255 Each series represent 15 independent runs, the dashed lines are maximums of each series while the solid lines are the median and the dotted lines are the mnimums.} 249 256 \label{fig:yield:jax} 250 257 \end{figure} … … 252 259 \subsection{Results} 253 260 254 Figures~\ref{fig:yield:jax} and~\ref{fig:yield:nasus} show the same throughput graphs as @cycle@ on Intel and AMD, respectively. 255 Note, the Y-axis on the yield graph for Intel is twice as large as the Intel cycle-graph. 256 A visual glance between the cycle and yield graphs confirms my claim that the yield benchmark is unreliable. 257 258 For the Intel architecture, Figure~\ref{fig:yield:jax}: 259 \begin{itemize} 260 \item 261 Figures~\ref{fig:yield:jax} and~\ref{fig:yield:nasus} show the results for the yield experiment. 262 Looking at the left column on Intel first, Figure~\ref{fig:yield:jax:ops} and \ref{fig:yield:jax:ns}, which shows the results for many \ats, in this case 100 \ats for each \proc. 263 Note, the Y-axis on the graph is twice as large as the Intel cycle-graph. 264 A visual glance between the left columns of the cycle and yield graphs confirms my claim that the yield benchmark is unreliable. 261 265 \CFA has no special handling for @yield@, but this experiment requires less synchronization than the @cycle@ experiment. 262 Hence, the @yield@ throughput and scalability graphs for both 100 and 1 cycles/tasks per processorhave similar shapes to the corresponding @cycle@ graphs.266 Hence, the @yield@ throughput and scalability graphs have similar shapes to the corresponding @cycle@ graphs. 263 267 The only difference is sightly better performance for @yield@ because of less synchronization. 264 As for @cycle@, the cost of idle sleep also comes into play in a very significant way in Figure~\ref{fig:yield:jax:low:ns}, where the scaling is not flat. 265 \item 266 libfibre has special handling for @yield@ using the fact that the number of ready fibres does not change, and therefore, by-passing the idle-sleep mechanism entirely. 267 Additionally, when only running 1 \at per \proc, libfibre optimizes further, and forgoes the context-switch entirely. 268 Hence, libfibre behaves very differently in the cycle and yield benchmarks, with a 4 times increase in performance for 100 cycles/tasks and an 8 times increase for 1 cycle/task. 269 \item 268 Libfibre has special handling for @yield@ using the fact that the number of ready fibres does not change, and therefore, by-passing the idle-sleep mechanism entirely. 269 Hence, libfibre behaves very differently in the cycle and yield benchmarks, with a 4 times increase in performance on the left column. 270 270 Go has special handling for @yield@ by putting a yielding goroutine on a secondary global ready-queue, giving it lower priority. 271 271 The result is that multiple \glspl{hthrd} contend for the global queue and performance suffers drastically. 272 Hence, Go behaves very differently in the cycle and yield benchmarks, with a complete performance collapse in @yield@ for both 100 and 1 cycles/tasks. 273 \item 272 Hence, Go behaves very differently in the cycle and yield benchmarks, with a complete performance collapse in @yield@. 274 273 Tokio has a similar performance collapse after 16 processors, and therefore, its special @yield@ handling is probably related to a Go-like scheduler problem and/or a \CFA idle-sleep problem. 275 274 (I did not dig through the Rust code to ascertain the exact reason for the collapse.) 276 \end{itemize} 275 Note that since there is no communication among \ats, locality problems are much less likely than for the cycle benchmark. 276 This lack of communication is probably why the plateaus due to topology are not present. 277 278 Lookking next at the right column on Intel, Figure~\ref{fig:yield:jax:low:ops} and \ref{fig:yield:jax:low:ns}, which shows the results for few threads, in this case 1 \at for each \proc. 279 As for @cycle@, \CFA's cost of idle sleep comes into play in a very significant way in Figure~\ref{fig:yield:jax:low:ns}, where the scaling is not flat. 280 This is to be expected since fewet \ats means \procs are more likely to run out of work. 281 On the other hand, when only running 1 \at per \proc, libfibre optimizes further, and forgoes the context-switch entirely. 282 This results in libfibre outperforming other runtimes even more, achieving 8 times more throughput than for @cycle@. 283 Finally, Go and Tokio performance collapse is still the same with fewer \ats. 284 The only exception is Tokio running on 24 \proc, deepening the mystery of its yielding mechanism further. 277 285 278 286 \begin{figure} … … 302 310 \label{fig:yield:nasus:low:ns} 303 311 } 304 \caption[Yield Benchmark on AMD]{Yield Benchmark on AMD\smallskip\newline Throughput and scalability as a function of \proc count, using 1 \ats per \proc. For throughput, higher is better, for scalability, lower is better. Each series represent 15 independent runs, the dotted lines are extremes while the solid line is the medium.} 312 \caption[Yield Benchmark on AMD]{Yield Benchmark on AMD\smallskip\newline Throughput and scalability as a function of \proc count. 313 For throughput, higher is better, for scalability, lower is better. 314 Each series represent 15 independent runs, the dashed lines are maximums of each series while the solid lines are the median and the dotted lines are the mnimums.} 305 315 \label{fig:yield:nasus} 306 316 \end{figure} 307 317 308 For the AMD architecture, Figure~\ref{fig:yield:nasus}, the results show the same story as on the Intel, with slightly increased variations. 309 Also, some transition points on the X-axis differ because of the architectures, like at 16 versus 24 processors. 318 Looking now at the results for the AMD architecture, Figure~\ref{fig:yield:nasus}, the results again show a story that is overall similar to the results on the Intel, with increased variation and some differences in the details. 319 Note that the maximum of the Y-axis on Intel and AMD differ less in @yield@ than @cycle@. 320 Looking at the left column first, Figure~\ref{fig:yield:nasus:ops} and \ref{fig:yield:nasus:ns}, \CFA achieves very similar throughput and scaling. 321 Libfibre still outpaces all other runtimes, but it encounter a performance hit at 64 \procs. 322 This suggest some amount of communication between the \procs that the Intel machine was able to mask where the AMD is not once hyperthreading is needed. 323 Go and Tokio still display the same performance collapse than on Intel. 324 Looking next at the right column, Figure~\ref{fig:yield:nasus:low:ops} and \ref{fig:yield:nasus:low:ns}, all runtime effectively behave the same as they did on the Intel machine. 325 At high \ats count the only difference was Libfibre's scaling and this difference disappears on the right column. 326 This suggest that whatever communication benchmark it encountered on the left is completely circumvented on the right. 310 327 311 328 It is difficult to draw conclusions for this benchmark when runtime system treat @yield@ so differently. … … 321 338 With processor-specific ready-queues, when a \at is unblocked by a different \proc that means the unblocking \proc must either ``steal'' the \at from another processor or find it on a remote queue. 322 339 This dequeuing results in either contention on the remote queue and/or \glspl{rmr} on the \at data structure. 323 Hence, this benchmark has performance dominated by the cache traffic as \proc are constantly accessing theeach other's data.340 Hence, this benchmark has performance dominated by the cache traffic as \procs are constantly accessing each other's data. 324 341 In either case, this benchmark aims to measure how well a scheduler handles these cases, since both cases can lead to performance degradation if not handled correctly. 325 342 … … 364 381 } 365 382 366 \subfloat[][ Latency, 100 \ats per \proc]{383 \subfloat[][Scalability, 100 \ats per \proc]{ 367 384 \resizebox{0.5\linewidth}{!}{ 368 385 \input{result.churn.jax.ns.pstex_t} … … 370 387 \label{fig:churn:jax:ns} 371 388 } 372 \subfloat[][ Latency, 2 \ats per \proc]{389 \subfloat[][Scalability, 2 \ats per \proc]{ 373 390 \resizebox{0.5\linewidth}{!}{ 374 391 \input{result.churn.low.jax.ns.pstex_t} … … 376 393 \label{fig:churn:jax:low:ns} 377 394 } 378 \caption[Churn Benchmark on Intel]{\centering Churn Benchmark on Intel\smallskip\newline Throughput and latency of the Churn on the benchmark on the Intel machine. For throughput, higher is better, for scalability, lower is better. Each series represent 15 independent runs, the dotted lines are extremes while the solid line is the medium.} 395 \caption[Churn Benchmark on Intel]{\centering Churn Benchmark on Intel\smallskip\newline Throughput and scalability of the Churn on the benchmark on the Intel machine. 396 For throughput, higher is better, for scalability, lower is better. 397 Each series represent 15 independent runs, the dashed lines are maximums of each series while the solid lines are the median and the dotted lines are the mnimums.} 379 398 \label{fig:churn:jax} 380 399 \end{figure} … … 382 401 \subsection{Results} 383 402 384 Figures~\ref{fig:churn:jax} and Figure~\ref{fig:churn:nasus} show the throughput on Intel and AMD respectively. 385 386 The performance cost of crossing the cache boundaries is still visible at the same \proc count. 387 388 Scalability is notably worst than the previous benchmarks since there is inherently more communication between processors. 389 Indeed, once the number of \glspl{hthrd} goes beyond a single socket, performance ceases to improve. 403 Figures~\ref{fig:churn:jax} and Figure~\ref{fig:churn:nasus} show the results for the churn experiment. 404 Looking at the left column on Intel first, Figure~\ref{fig:churn:jax:ops} and \ref{fig:churn:jax:ns}, which shows the results for many \ats, in this case 100 \ats for each \proc, all runtime obtain fairly similar throughput for most \proc counts. 405 \CFA does very well on a single \proc but quickly loses its advantage over the other runtimes. 406 As expected it scales decently up to 48 \procs and then basically plateaus. 407 Tokio achieves very similar performance to \CFA until 48 \procs, after which it takes a significant hit but does keep scaling somewhat. 408 Libfibre obtains effectively the same results as Tokio with slightly less scaling, \ie the scaling curve is the same but with slightly higher values. 409 Finally Go gets the most peculiar results, scaling worst than other runtimes until 48 \procs. 410 At 72 \procs, the results of the Go runtime vary significantly, sometimes scaling sometimes plateauing. 411 However, beyond this point Go keeps this level of variation but does not scale in any of the runs. 412 413 Throughput and scalability is notably worst for all runtimes than the previous benchmarks since there is inherently more communication between processors. 414 Indeed, none of the runtime reach 40 million operations per second while in the cycle benchmark all but libfibre reached 400 million operations per second. 415 Figures~\ref{fig:churn:jax:ns} and \ref{fig:churn:jax:low:ns} show that for all \proc count, all runtime produce poor scaling. 416 However, once the number of \glspl{hthrd} goes beyond a single socket, at 48 \procs, scaling goes from bad to worst and performance completely ceases to improve. 417 At this point, the benchmark is dominated by inter-socket communication costs for all runtimes. 418 390 419 An interesting aspect to note here is that the runtimes differ in how they handle this situation. 391 420 Indeed, when a \proc unparks a \at that was last run on a different \proc, the \at could be appended to the ready-queue local \proc or to the ready-queue of the remote \proc, which previously ran the \at. … … 393 422 In this particular benchmark, the inherent chaos of the benchmark in addition to small memory footprint means neither approach wins over the other. 394 423 424 Looking next at the right column on Intel, Figure~\ref{fig:churn:jax:low:ops} and \ref{fig:churn:jax:low:ns}, which shows the results for few threads, in this case 1 \at for each \proc, many of the differences between the runtime disappear. 425 \CFA outperforms other runtimes by a minuscule margin. 426 Libfibre follows very closely behind with basically the same performance and scaling. 427 Tokio maintains effectively the same curve shapes as it did with many threads, but it incurs extra costs for all \proc count. 428 As a result it is slightly outperformed by \CFA and libfibre. 429 While Go maintains overall similar results to the others, it again encounters significant variation at high \proc counts. 430 Inexplicably resulting in super-linear scaling for some runs, \ie the scalability curves displays a negative slope. 431 432 Interestingly, unlike the cycle benchmark, running with fewer \ats does not produce drastically different results. 433 In fact, the overall throughput stays almost exactly the same on the left and right column. 434 395 435 \begin{figure} 396 436 \subfloat[][Throughput, 100 \ats per \proc]{ … … 407 447 } 408 448 409 \subfloat[][ Latency, 100 \ats per \proc]{449 \subfloat[][Scalability, 100 \ats per \proc]{ 410 450 \resizebox{0.5\linewidth}{!}{ 411 451 \input{result.churn.nasus.ns.pstex_t} … … 413 453 \label{fig:churn:nasus:ns} 414 454 } 415 \subfloat[][ Latency, 2 \ats per \proc]{455 \subfloat[][Scalability, 2 \ats per \proc]{ 416 456 \resizebox{0.5\linewidth}{!}{ 417 457 \input{result.churn.low.nasus.ns.pstex_t} … … 419 459 \label{fig:churn:nasus:low:ns} 420 460 } 421 \caption[Churn Benchmark on AMD]{\centering Churn Benchmark on AMD\smallskip\newline Throughput and latency of the Churn on the benchmark on the AMD machine. 422 For throughput, higher is better, for scalability, lower is better. Each series represent 15 independent runs, the dotted lines are extremes while the solid line is the medium.} 461 \caption[Churn Benchmark on AMD]{\centering Churn Benchmark on AMD\smallskip\newline Throughput and scalability of the Churn on the benchmark on the AMD machine. 462 For throughput, higher is better, for scalability, lower is better. 463 Each series represent 15 independent runs, the dashed lines are maximums of each series while the solid lines are the median and the dotted lines are the mnimums.} 423 464 \label{fig:churn:nasus} 424 465 \end{figure} 425 466 426 Like for the cycle benchmark, here all runtimes achieve fairly similar performance. 427 Performance improves as long as all \procs fit on a single socket. 428 Beyond that performance starts to suffer from increased caching costs. 429 430 Indeed on Figures~\ref{fig:churn:jax:ops} and \ref{fig:churn:jax:ns} show that with 1 and 100 \ats per \proc, \CFA, libfibre, Go and Tokio achieve effectively equivalent performance for most \proc count. 431 432 However, Figure~\ref{fig:churn:nasus} again shows a somewhat different story on AMD. 433 While \CFA, libfibre, and Tokio achieve effectively equivalent performance for most \proc count, Go starts with better scaling at very low \proc counts but then performance quickly plateaus, resulting in worse performance at higher \proc counts. 434 This performance difference is visible at both high and low \at counts. 467 468 Looking now at the results for the AMD architecture, Figure~\ref{fig:churn:nasus}, the results show a somewhat different story. 469 Looking at the left column first, Figure~\ref{fig:churn:nasus:ops} and \ref{fig:churn:nasus:ns}, \CFA, Libfibre and Tokio all produce decent scalability. 470 \CFA suffers particular from a larger variations at higher \proc counts, but almost all run still outperform the other runtimes. 471 Go still produces intriguing results in this case and even more intriguingly, the results have fairly low variation. 435 472 436 473 One possible explanation for this difference is that since Go has very few available concurrent primitives, a channel was used instead of a semaphore. … … 445 482 Depending on how the heap is structure, this could also lead to false sharing. 446 483 484 I did not further investigate what causes these unusual results. 485 486 Looking next at the right column, Figure~\ref{fig:churn:nasus:low:ops} and \ref{fig:churn:nasus:low:ns}, like for Intel all runtime obtain overall similar throughput between the left and right column. 487 \CFA, Libfibre and Tokio all have very close results. 488 Go still suffers from poor scalability but is now unusual in a different way. 489 While it obtains effectively constant performance regardless of \proc count, this ``sequential'' performance is higher than the other runtimes for low \proc count. 490 Up to 32 \procs, after which the other runtime manage to outscale Go. 491 447 492 The objective of this benchmark is to demonstrate that unparking \ats from remote \procs do not cause too much contention on the local queues. 448 Indeed, the fact all runtimes achieve some scaling at lower\proc count demonstrate that migrations do not need to be serialized.493 Indeed, the fact most runtimes achieve some scaling between various \proc count demonstrate that migrations do not need to be serialized. 449 494 Again these result demonstrate \CFA achieves satisfactory performance. 450 495
Note: See TracChangeset
for help on using the changeset viewer.