Почему многопоточная Java-программа не ускоряется на "супер" Linux-сервере и ноутбуке Win7?

Введение

До сих пор я работал над частью программного обеспечения, которое я сейчас тестирую, чтобы увидеть преимущества concurrency. Я тестирую одно и то же программное обеспечение, используя две разные системы:

  • Система 1: 2 x Intel (R) Xeon (R) CPU E5-2665 @2.40 ГГц с всего 16 ядер, 64 ГБ оперативной памяти Научные LINUX 6.1 и JAVA SE Runtime Enviroment (постройте 1.7.0_11-b21).
  • Система 2 Lenovo Thinkpad T410 с Intel i5 процессор с частотой 2,67 ГГц с 4 ядрами, 4 ГБ операционных окон 7 64-бит и JAVA SE Runtime Enviroment (сборка 1.7.0_11-b21).

Детали: Программа имитирует пациентов с диабетом типа 1. Он выполняет некоторый импорт (чтение из csv), некоторые численные вычисления (Dopri54 + newton) и некоторые экспортные (Write to csv).

У меня есть эксклюзивные права на сервер, поэтому вообще не должно быть шума.

Результаты Это мои результаты:

Теперь, как вы видите, система 1 работает так же быстро, как и система 2, несмотря на то, что это довольно мощная машина. Я понятия не имею, почему это так - и я уверен, что система такая же. Количество потоков идет от 10-100.

Вопрос:

Почему два этапа имеют одинаковое время выполнения, несмотря на то, что система 1 значительно более мощная, чем система 2?

UPDATE!

Теперь я просто немного подумал о том, что вы, ребята, сказали об этом, это проблема памяти ввода-вывода. Итак, я подумал, что если бы я мог уменьшить размер файла, это ускорило бы программу, верно? Мне удалось уменьшить размер файла импорта с коэффициентом 5, однако никакого улучшения производительности вообще. Вы, ребята, все еще думаете, что это та же проблема?

2 ответа

Когда вы пишете файлы .csv, возможно, что узким местом является не ваша способность к вычислению, а скорость записи на вашем жестком диске.


Почти наверняка это означает, что либо процессорное время не является узким местом для этого приложения, либо что-то в нем делает его устойчивым к эффективной параллелизации, или и то, и другое.

Например, если чтение данных с диска на самом деле является ограничивающим фактором, то важны более быстрые диски, а не более быстрые процессоры.

Если у него заканчивается память, тогда это будет большая бутылочка.

Если для каждого потока требуется больше времени, чем фактическая обработка внутри потока.

и др.

В этом типе оптимизации показатели работы - это король. Вам нужны реальные твердые цифры о том, сколько времени нужно делать, и где в вашей программе вы теряете это время. Только тогда вы сможете увидеть, где сосредоточить свои усилия и посмотреть, эффективны ли они.

licensed under cc by-sa 3.0 with attribution.