powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Java [игнор отключен] [закрыт для гостей] / responsiveness vs throughput
6 сообщений из 31, страница 2 из 2
responsiveness vs throughput
    #39416336
questioner
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
В concurency in practice есть такой код:

http://jcip.net/listings/TimedPutTakeTest.java
Код: java
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
public class TimedPutTakeTest extends PutTakeTest {
    private BarrierTimer timer = new BarrierTimer();

    public TimedPutTakeTest(int cap, int pairs, int trials) {
        super(cap, pairs, trials);
        barrier = new CyclicBarrier(nPairs * 2 + 1, timer);
    }

    public void test() {
        try {
            timer.clear();
            for (int i = 0; i < nPairs; i++) {
                pool.execute(new PutTakeTest.Producer());
                pool.execute(new PutTakeTest.Consumer());
            }
            barrier.await();
            barrier.await();
            long nsPerItem = timer.getTime() / (nPairs * (long) nTrials);
            System.out.print("Throughput: " + nsPerItem + " ns/item");
            assertEquals(putSum.get(), takeSum.get());
        } catch (Exception e) {
            throw new RuntimeException(e);
        }
    }

    public static void main(String[] args) throws Exception {
        int tpt = 100000; // trials per thread
        for (int cap = 1; cap <= 1000; cap *= 10) {
            System.out.println("Capacity: " + cap);
            for (int pairs = 1; pairs <= 128; pairs *= 2) {
                TimedPutTakeTest t = new TimedPutTakeTest(cap, pairs, tpt);
                System.out.print("Pairs: " + pairs + "\t");
                t.test();
                System.out.print("\t");
                Thread.sleep(1000);
                t.test();
                System.out.println();
                Thread.sleep(1000);
            }
        }
        PutTakeTest.pool.shutdown();
    }
}



и представлены результаты в виде графика:



Как может такое случиться, что пропускная способность упала при увеличении тредов?

Скажем на 1 потоке 8.5 op/sec

а на двух потоках 4 op/sec

я ожидал, что как минимум ухудшиться не должно. Из-за переключений контекста такое поведение может случиться?
...
Рейтинг: 0 / 0
responsiveness vs throughput
    #39416357
questioner
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Как я себе это представляю.

Пусть у нас есть один воркер и он делает работу за 0.5 sec



latency -0.5 sec
throughput - 2 op/sec

добавляем ещё один поток(ядер >=2 и кроме jvm ничего не выполняется на компутере)


latency -0.5 sec
throughput - 4 op/sec

Ну и так далее. Чем больше потоков, тем больше throughput.

Или тут идёт речь про то, что исполнение сваливается на сплошное переключении контекста ?
...
Рейтинг: 0 / 0
responsiveness vs throughput
    #39416384
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Была вполне реальная ситуация.
Некая задача считалась на одном пень-четыре более двадцати часов. Купили другой пень-четыре из какой-то экстрим-эдишен и время счёта упало до трёх с половиной часов.
Основная разница между двумя процами - размер L2-кэша. Задаче повезло и она влезла в кэш экстремальной редакции проца.
А ещё есть прикол lock-free алгоритмов, которые сначала оптимистично пытаются лезть без очереди и только если совсем не пролазит - дисциплинированно встают в очередь.
В результате, при низкой конкуренции всё работает быстрее synchronised, но при высокой - может оказаться медленнее.

P.S. "... а в очко - думать надо, шанс считать" (ц) "Две сорванные башни".
...
Рейтинг: 0 / 0
responsiveness vs throughput
    #39416437
questioner
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Basil A. SidorovБыла вполне реальная ситуация.
Некая задача считалась на одном пень-четыре более двадцати часов. Купили другой пень-четыре из какой-то экстрим-эдишен и время счёта упало до трёх с половиной часов.
Основная разница между двумя процами - размер L2-кэша. Задаче повезло и она влезла в кэш экстремальной редакции проца.
А ещё есть прикол lock-free алгоритмов, которые сначала оптимистично пытаются лезть без очереди и только если совсем не пролазит - дисциплинированно встают в очередь.
В результате, при низкой конкуренции всё работает быстрее synchronised, но при высокой - может оказаться медленнее.

P.S. "... а в очко - думать надо, шанс считать" (ц) "Две сорванные башни".

А в случае как на моём графике это значит, что затраты на шедулинг и создание тредов дороже чем исполнение самой задачи?
...
Рейтинг: 0 / 0
responsiveness vs throughput
    #39416822
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Нет, это означает, что условиях авторов замеров получились "вот такие результаты".
...
Рейтинг: 0 / 0
responsiveness vs throughput
    #39416958
questioner
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Basil A. SidorovНет, это означает, что условиях авторов замеров получились "вот такие результаты".
Да, но резкльтаты же надо как-то трактовать
...
Рейтинг: 0 / 0
6 сообщений из 31, страница 2 из 2
Форумы / Java [игнор отключен] [закрыт для гостей] / responsiveness vs throughput
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]