Почему код на С ++ работает на одном компьютере значительно дольше, чем на другом?

513
Stershic

Код точно такой же - я скопировал его с одного компьютера на другой. Код скомпилирован с g ++ - 4 (4.9.1), полученным из fink на OSX на обеих машинах, и не запускается параллельно.

Параметры компилятора - «-O2», и компьютеры в основном ничего не делают (низкое использование процессора и памяти). Код представляет собой ссылку на код исследования в 2400 строк .

Машина 1:

  • MacBook Pro Retina в конце 2013 года,
  • 2,8 ГГц i7-4558U,
  • 16 ГБ 1600 МГц DDR3,
  • 500 ГБ флэш-памяти

Машина 2:

  • Рабочая станция MacPro в конце 2013 года,
  • 3,5-ГГц 6-ядерный Intel Xeon E5-1650,
  • 32 ГБ 1867 МГц DDR3
  • 251 ГБ флэш-памяти,
  • Внешний накопитель SATA емкостью 3 ТБ

Время работы:
Машина 1: с выходной мощностью 200 сек., Без 18 сек.
Машина 2: (/ каталог - должна быть флешка): с 2230 сек., Без 2075 сек.
Машина 2: (~ каталог - должен быть внешний диск): с 2262 сек., Без 2080 сек.

Есть идеи, как улучшить время выполнения на MacPro?

0
@ Ramhound Мне сказали, что это будет более актуально, чем StackOverflow. Stershic 9 лет назад 0
Этот вопрос кажется чрезвычайно широким. Чтобы понять разницу, вам нужно сделать следующее. Определите, какая часть кода занимает больше всего времени. Затем вы можете изменить этот код так быстро на обеих машинах. Если вы застряли, делая это, вы можете задать вопрос на правильном веб-сайте. Ramhound 9 лет назад 2
@Ramhound Было предложено, чтобы я использовал Instruments для профилирования своего кода, и я смог это сделать, но мне не ясно, если / как это показывает, какая часть кода занимает больше всего времени. Я не спрашиваю, потому что я эксперт - я спрашиваю, потому что я нет, и я хочу учиться. Stershic 9 лет назад 0
** Я даже не могу исследовать различия между i7 и E5, поскольку у меня нет конкретных номеров моделей. ** Полагаю, ваш код однопоточный. Поскольку скорость серийной съемки у i7 составляет около 3,0 ГГц, это означает, что маловероятно, что частота процессора приводит к увеличению производительности на 115%. Ramhound 9 лет назад 1
Вы смогли сделать это. Но вы не предоставляете эту информацию. Вы знаете, сколько времени занимает код. Какая именно функция вызывает задержку? ** Конечно, этот вопрос - вопрос Stackoverflow. ** Я в основном пытаюсь сказать, что вы задаете неправильный вопрос. Я должен добавить, что следующее. Вам не сказали, что это был вопрос суперпользователя. Непосредственная причина указала, что это может быть связано с темой здесь, это не так, вам дали лучший совет в комментариях. Ramhound 9 лет назад 0
Запустите код на компьютере 2 с инструментарием и узнайте, что занимает так много времени. Это должно быть совершенно очевидно. David Schwartz 9 лет назад 0
@ZippityBrosnan - как использовать инструменты профилирования, безусловно, кажется подходящим вопросом SO user2813274 9 лет назад 0
Спасибо за вашу помощь @Ramhound & David. Требуется некоторое копание, но инструменты действительно показывают процент времени, затраченного на методы, и между ними была явная разница. Теперь, когда дело доходит до одного метода, я уверен, что смогу понять это отсюда. Спасибо! Stershic 9 лет назад 0
@ user2813274 - я бы согласился. Причина, по которой первоначальный вопрос был закрыт, заключалась в том, что он был очень широким и в основном предлагал людям просмотреть 2 тыс. Строк кода. Вопрос не был обновлен, все было в комментариях, и деталей было мало. ** Я не шок, это было закрыто, если честно ** Ramhound 9 лет назад 0
@ Ramhound Я абсолютно не ожидал, что кто-нибудь пересмотрит код. Я хотел, чтобы предложения о том, как может выполняться код разности порядка «Это не должно» + правильное использование инструментов профилирования - правильный ответ. Полегче на новичка Stershic 9 лет назад 0
@ZippityBrosnan - я ожидаю, что люди будут задавать вопросы по теме. ** Я не понимаю, как спрашивать, как профилировать код, является вопросом суперпользователя. ** Ramhound 9 лет назад 0
@ Ramhound Я не знал, что вы _could_ код профиля. Это по теме? Если нет, пожалуйста, дайте мне предварительно утвержденный список тем для SU. Stershic 9 лет назад 0

2 ответа на вопрос

1
user2813274

This is a speculative guess, but your code works with the disk and disk I/O, and I am going to assume that this is your bottleneck - you mentioned that it runs faster on the machine with 500GB flash storage than on the one with 250 GB flash storage - this makes sense, logically, because of how flash storage is essentially a raid-0 of smaller (32/64gb) flash storage chips, and more chips/disks in a raid-0 array will greatly increase performance. I do not know the particular make/model/firmware/controller of the storage, however I suspect that if you were to do a disk I/O test, you would find a similar discrepancy in performance on the two machines. Such a performance test can best be done using XBench.

@Ramhound: почему бы вам не вернуть мою ссылку на XBench. Как следует из этого ответа, разница в производительности, вероятно, вызвана скоростью жесткого диска. Предлагается измерить эту скорость, и я добавил ссылку на инструмент, чтобы проверить это. Зачем удалять это? agtoever 9 лет назад 0
@agtoever - Это сложно. Виноват Ramhound 9 лет назад 0
0
a CVn

The proper way to approach the question "why does this code take so long to run", whether "long" is in absolute or relative terms, is to use a tool called a profiler.

Basically, you run the program through the profiler or with the profiler attached, and the profiler records how much time the program spends in various functions. This information is then presented to you in a form that allows you to pinpoint the parts of the program that took the longest to run during that execution. Often it will also be possible to get additional information from that report, such as which parts of the program are called the largest number of times, and things like that, which can also point toward areas that could use some scrutiny.

Based on that data, it's usually easy to tell which parts need to be optimized such that the program runs faster, without employing the guessing game known as "premature optimization" or relying on the particulars of some specific piece of hardware.