2013-10-09 16:12:23 +00:00
|
|
|
/*
|
|
|
|
* Copyright 2013 Google Inc.
|
|
|
|
*
|
|
|
|
* Use of this source code is governed by a BSD-style license that can be
|
|
|
|
* found in the LICENSE file.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include "SkOnce.h"
|
Revert of SkThreadPool ~~> SkTaskGroup (patchset #4 id:60001 of https://codereview.chromium.org/531653002/)
Reason for revert:
Leaks, leaks, leaks.
Original issue's description:
> SkThreadPool ~~> SkTaskGroup
>
> SkTaskGroup is like SkThreadPool except the threads stay in
> one global pool. Each SkTaskGroup itself is tiny (4 bytes)
> and its wait() method applies only to tasks add()ed to that
> instance, not the whole thread pool.
>
> This means we don't need to bring up new thread pools when
> tests themselves want to use multithreading (e.g. pathops,
> quilt). We just create a new SkTaskGroup and wait for that
> to complete. This should be more efficient, and allow us
> to expand where we use threads to really latency sensitive
> places. E.g. we can probably now use these in nanobench
> for CPU .skp rendering.
>
> Now that all threads are sharing the same pool, I think we
> can remove most of the custom mechanism pathops tests use
> to control threading. They'll just ride on the global pool
> with all other tests now.
>
> This (temporarily?) removes the GPU multithreading feature
> from DM, which we don't use.
>
> On my desktop, DM runs a little faster (57s -> 55s) in
> Debug, and a lot faster in Release (36s -> 24s). The bots
> show speedups of similar proportions, cutting more than a
> minute off the N4/Release and Win7/Debug runtimes.
>
> BUG=skia:
>
> Committed: https://skia.googlesource.com/skia/+/9c7207b5dc71dc5a96a2eb107d401133333d5b6f
R=caryclark@google.com, bsalomon@google.com, bungeman@google.com, reed@google.com, mtklein@chromium.org
TBR=bsalomon@google.com, bungeman@google.com, caryclark@google.com, mtklein@chromium.org, reed@google.com
NOTREECHECKS=true
NOTRY=true
BUG=skia:
Author: mtklein@google.com
Review URL: https://codereview.chromium.org/533393002
2014-09-03 21:17:48 +00:00
|
|
|
#include "SkThreadPool.h"
|
2013-10-09 16:12:23 +00:00
|
|
|
#include "Test.h"
|
|
|
|
|
2013-10-23 14:44:08 +00:00
|
|
|
static void add_five(int* x) {
|
2013-10-09 16:12:23 +00:00
|
|
|
*x += 5;
|
|
|
|
}
|
|
|
|
|
|
|
|
DEF_TEST(SkOnce_Singlethreaded, r) {
|
|
|
|
int x = 0;
|
|
|
|
|
2013-10-23 14:44:08 +00:00
|
|
|
SK_DECLARE_STATIC_ONCE(once);
|
2013-10-09 16:12:23 +00:00
|
|
|
// No matter how many times we do this, x will be 5.
|
2013-10-23 14:44:08 +00:00
|
|
|
SkOnce(&once, add_five, &x);
|
|
|
|
SkOnce(&once, add_five, &x);
|
|
|
|
SkOnce(&once, add_five, &x);
|
|
|
|
SkOnce(&once, add_five, &x);
|
|
|
|
SkOnce(&once, add_five, &x);
|
2013-10-09 16:12:23 +00:00
|
|
|
|
|
|
|
REPORTER_ASSERT(r, 5 == x);
|
|
|
|
}
|
|
|
|
|
2013-10-23 14:44:08 +00:00
|
|
|
static void add_six(int* x) {
|
2013-10-09 16:12:23 +00:00
|
|
|
*x += 6;
|
|
|
|
}
|
|
|
|
|
|
|
|
class Racer : public SkRunnable {
|
|
|
|
public:
|
2013-10-23 14:44:08 +00:00
|
|
|
SkOnceFlag* once;
|
2013-10-09 16:12:23 +00:00
|
|
|
int* ptr;
|
2013-10-23 14:44:08 +00:00
|
|
|
|
2013-10-09 16:12:23 +00:00
|
|
|
virtual void run() SK_OVERRIDE {
|
2013-10-23 14:44:08 +00:00
|
|
|
SkOnce(once, add_six, ptr);
|
2013-10-09 16:12:23 +00:00
|
|
|
}
|
|
|
|
};
|
|
|
|
|
|
|
|
DEF_TEST(SkOnce_Multithreaded, r) {
|
Revert of SkThreadPool ~~> SkTaskGroup (patchset #4 id:60001 of https://codereview.chromium.org/531653002/)
Reason for revert:
Leaks, leaks, leaks.
Original issue's description:
> SkThreadPool ~~> SkTaskGroup
>
> SkTaskGroup is like SkThreadPool except the threads stay in
> one global pool. Each SkTaskGroup itself is tiny (4 bytes)
> and its wait() method applies only to tasks add()ed to that
> instance, not the whole thread pool.
>
> This means we don't need to bring up new thread pools when
> tests themselves want to use multithreading (e.g. pathops,
> quilt). We just create a new SkTaskGroup and wait for that
> to complete. This should be more efficient, and allow us
> to expand where we use threads to really latency sensitive
> places. E.g. we can probably now use these in nanobench
> for CPU .skp rendering.
>
> Now that all threads are sharing the same pool, I think we
> can remove most of the custom mechanism pathops tests use
> to control threading. They'll just ride on the global pool
> with all other tests now.
>
> This (temporarily?) removes the GPU multithreading feature
> from DM, which we don't use.
>
> On my desktop, DM runs a little faster (57s -> 55s) in
> Debug, and a lot faster in Release (36s -> 24s). The bots
> show speedups of similar proportions, cutting more than a
> minute off the N4/Release and Win7/Debug runtimes.
>
> BUG=skia:
>
> Committed: https://skia.googlesource.com/skia/+/9c7207b5dc71dc5a96a2eb107d401133333d5b6f
R=caryclark@google.com, bsalomon@google.com, bungeman@google.com, reed@google.com, mtklein@chromium.org
TBR=bsalomon@google.com, bungeman@google.com, caryclark@google.com, mtklein@chromium.org, reed@google.com
NOTREECHECKS=true
NOTRY=true
BUG=skia:
Author: mtklein@google.com
Review URL: https://codereview.chromium.org/533393002
2014-09-03 21:17:48 +00:00
|
|
|
const int kTasks = 16, kThreads = 4;
|
2013-10-09 16:12:23 +00:00
|
|
|
|
|
|
|
// Make a bunch of tasks that will race to be the first to add six to x.
|
|
|
|
Racer racers[kTasks];
|
2013-10-23 14:44:08 +00:00
|
|
|
SK_DECLARE_STATIC_ONCE(once);
|
2013-10-09 16:12:23 +00:00
|
|
|
int x = 0;
|
|
|
|
for (int i = 0; i < kTasks; i++) {
|
2013-10-23 14:44:08 +00:00
|
|
|
racers[i].once = &once;
|
2013-10-09 16:12:23 +00:00
|
|
|
racers[i].ptr = &x;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Let them race.
|
Revert of SkThreadPool ~~> SkTaskGroup (patchset #4 id:60001 of https://codereview.chromium.org/531653002/)
Reason for revert:
Leaks, leaks, leaks.
Original issue's description:
> SkThreadPool ~~> SkTaskGroup
>
> SkTaskGroup is like SkThreadPool except the threads stay in
> one global pool. Each SkTaskGroup itself is tiny (4 bytes)
> and its wait() method applies only to tasks add()ed to that
> instance, not the whole thread pool.
>
> This means we don't need to bring up new thread pools when
> tests themselves want to use multithreading (e.g. pathops,
> quilt). We just create a new SkTaskGroup and wait for that
> to complete. This should be more efficient, and allow us
> to expand where we use threads to really latency sensitive
> places. E.g. we can probably now use these in nanobench
> for CPU .skp rendering.
>
> Now that all threads are sharing the same pool, I think we
> can remove most of the custom mechanism pathops tests use
> to control threading. They'll just ride on the global pool
> with all other tests now.
>
> This (temporarily?) removes the GPU multithreading feature
> from DM, which we don't use.
>
> On my desktop, DM runs a little faster (57s -> 55s) in
> Debug, and a lot faster in Release (36s -> 24s). The bots
> show speedups of similar proportions, cutting more than a
> minute off the N4/Release and Win7/Debug runtimes.
>
> BUG=skia:
>
> Committed: https://skia.googlesource.com/skia/+/9c7207b5dc71dc5a96a2eb107d401133333d5b6f
R=caryclark@google.com, bsalomon@google.com, bungeman@google.com, reed@google.com, mtklein@chromium.org
TBR=bsalomon@google.com, bungeman@google.com, caryclark@google.com, mtklein@chromium.org, reed@google.com
NOTREECHECKS=true
NOTRY=true
BUG=skia:
Author: mtklein@google.com
Review URL: https://codereview.chromium.org/533393002
2014-09-03 21:17:48 +00:00
|
|
|
SkThreadPool pool(kThreads);
|
2013-10-09 16:12:23 +00:00
|
|
|
for (int i = 0; i < kTasks; i++) {
|
Revert of SkThreadPool ~~> SkTaskGroup (patchset #4 id:60001 of https://codereview.chromium.org/531653002/)
Reason for revert:
Leaks, leaks, leaks.
Original issue's description:
> SkThreadPool ~~> SkTaskGroup
>
> SkTaskGroup is like SkThreadPool except the threads stay in
> one global pool. Each SkTaskGroup itself is tiny (4 bytes)
> and its wait() method applies only to tasks add()ed to that
> instance, not the whole thread pool.
>
> This means we don't need to bring up new thread pools when
> tests themselves want to use multithreading (e.g. pathops,
> quilt). We just create a new SkTaskGroup and wait for that
> to complete. This should be more efficient, and allow us
> to expand where we use threads to really latency sensitive
> places. E.g. we can probably now use these in nanobench
> for CPU .skp rendering.
>
> Now that all threads are sharing the same pool, I think we
> can remove most of the custom mechanism pathops tests use
> to control threading. They'll just ride on the global pool
> with all other tests now.
>
> This (temporarily?) removes the GPU multithreading feature
> from DM, which we don't use.
>
> On my desktop, DM runs a little faster (57s -> 55s) in
> Debug, and a lot faster in Release (36s -> 24s). The bots
> show speedups of similar proportions, cutting more than a
> minute off the N4/Release and Win7/Debug runtimes.
>
> BUG=skia:
>
> Committed: https://skia.googlesource.com/skia/+/9c7207b5dc71dc5a96a2eb107d401133333d5b6f
R=caryclark@google.com, bsalomon@google.com, bungeman@google.com, reed@google.com, mtklein@chromium.org
TBR=bsalomon@google.com, bungeman@google.com, caryclark@google.com, mtklein@chromium.org, reed@google.com
NOTREECHECKS=true
NOTRY=true
BUG=skia:
Author: mtklein@google.com
Review URL: https://codereview.chromium.org/533393002
2014-09-03 21:17:48 +00:00
|
|
|
pool.add(&racers[i]);
|
2013-10-09 16:12:23 +00:00
|
|
|
}
|
Revert of SkThreadPool ~~> SkTaskGroup (patchset #4 id:60001 of https://codereview.chromium.org/531653002/)
Reason for revert:
Leaks, leaks, leaks.
Original issue's description:
> SkThreadPool ~~> SkTaskGroup
>
> SkTaskGroup is like SkThreadPool except the threads stay in
> one global pool. Each SkTaskGroup itself is tiny (4 bytes)
> and its wait() method applies only to tasks add()ed to that
> instance, not the whole thread pool.
>
> This means we don't need to bring up new thread pools when
> tests themselves want to use multithreading (e.g. pathops,
> quilt). We just create a new SkTaskGroup and wait for that
> to complete. This should be more efficient, and allow us
> to expand where we use threads to really latency sensitive
> places. E.g. we can probably now use these in nanobench
> for CPU .skp rendering.
>
> Now that all threads are sharing the same pool, I think we
> can remove most of the custom mechanism pathops tests use
> to control threading. They'll just ride on the global pool
> with all other tests now.
>
> This (temporarily?) removes the GPU multithreading feature
> from DM, which we don't use.
>
> On my desktop, DM runs a little faster (57s -> 55s) in
> Debug, and a lot faster in Release (36s -> 24s). The bots
> show speedups of similar proportions, cutting more than a
> minute off the N4/Release and Win7/Debug runtimes.
>
> BUG=skia:
>
> Committed: https://skia.googlesource.com/skia/+/9c7207b5dc71dc5a96a2eb107d401133333d5b6f
R=caryclark@google.com, bsalomon@google.com, bungeman@google.com, reed@google.com, mtklein@chromium.org
TBR=bsalomon@google.com, bungeman@google.com, caryclark@google.com, mtklein@chromium.org, reed@google.com
NOTREECHECKS=true
NOTRY=true
BUG=skia:
Author: mtklein@google.com
Review URL: https://codereview.chromium.org/533393002
2014-09-03 21:17:48 +00:00
|
|
|
pool.wait();
|
2013-10-09 16:12:23 +00:00
|
|
|
|
|
|
|
// Only one should have done the +=.
|
|
|
|
REPORTER_ASSERT(r, 6 == x);
|
|
|
|
}
|
2014-01-24 22:38:39 +00:00
|
|
|
|
2014-06-02 18:26:59 +00:00
|
|
|
static int gX = 0;
|
|
|
|
static void inc_gX() { gX++; }
|
2014-01-24 22:38:39 +00:00
|
|
|
|
2014-06-02 18:26:59 +00:00
|
|
|
DEF_TEST(SkOnce_NoArg, r) {
|
2014-01-24 22:38:39 +00:00
|
|
|
SK_DECLARE_STATIC_ONCE(once);
|
2014-06-02 18:26:59 +00:00
|
|
|
SkOnce(&once, inc_gX);
|
|
|
|
SkOnce(&once, inc_gX);
|
|
|
|
SkOnce(&once, inc_gX);
|
|
|
|
REPORTER_ASSERT(r, 1 == gX);
|
2014-01-24 22:38:39 +00:00
|
|
|
}
|