Хтось робить апаратні орієнтири щодо компіляції коду? [зачинено]

21

Я бачив купу сайтів, які орієнтують нову техніку на продуктивність ігор, накопичують деякі файли, кодують фільм тощо. Чи є те, що перевіряють вплив нового обладнання (наприклад, SSD, нових процесорів, швидкості оперативної пам’яті тощо) на швидкість компіляції та зв’язку, будь то Linux або Windows?

Було б дуже добре дізнатися, що найбільше має значення для швидкості компіляції, і мати можливість зосередитись на цьому, а не просто екстраполювати з інших орієнтирів.

benchmarking 
— Колен
джерело
Я думаю, що це належить до SuperUser.
— Махмуд Хоссам
2
@Mahmoud Hossam: Сортування змішаної теми - компіляція - це інтенсивно лише програмістська діяльність, тоді як апаратні орієнтири, безумовно, інша територія.
— Орблінг
@ Досить добре, він не запитує, чи слід він збирати X чи Y, він запитує, чи люди взагалі використовують компіляцію, щоб робити орієнтири.
— Махмуд Хоссам
1
я зробив якісь kokizzu.blogspot.co.id/2015/02/…
— Kokizzu
1
Тут є тест на процесор, який базується на часах компіляції ядра Linux: openbenchmarking.org/showdown/pts/build-linux-kernel
— sjakobi

Відповіді:

4

Я робив це деякий час - дивіться тут і тут .

У той час я працював над хаками GTK + і X11 для дистрибутива стільникового телефону Linux, і кожен раз, коли я торкався чогось на такому низькому рівні, це викликало перебудову всіляких речей. Один з моїх колег ніколи не робив завершення складання, тому що на комп'ютері, який компанія постачала зі стандартними параметрами компіляції, потрібно було п’ять годин.

У мене вдома сиділи всілякі шалені апаратури, тож я на деяких машинах базував орієнтири, а на інших кодував, а результати можна побачити за посиланнями.

Для того, що ми робили на Ubuntu, після того, як я зафіксував використання процесора - що ви можете зробити дуже легко за допомогою аргументу -j - це вузьким місцем виявився диск.

Але тоді компанія мала великі звільнення, тож я вийшов із дверей, і не закінчив це все вибирати. У мене було багато даних та тлумачень, які я також не публікував у цьому блозі.

— Боб Мерфі
джерело
Соромно створити це з двома детальними повідомленнями, і вони зупиняться. Ви все ще маєте всі ці дані? У будь-якому випадку було б дуже цікаво побачити деякі дописи / відповіді в блозі з деякими висновками того, що ви знайшли.
— Гюго
@Hugo: Ні, боюсь, що ні - необроблені дані давно минули. Але в основному те, що я придумав, це те, що для систем (1-8 ядер процесора) та вихідного коду (ядро Linux) я тестував, найшвидші часи збірки були, коли параметр -j був у 1,5 раза число ядер, причому -j = 2 найкраще для одного ядра. Нижче, системи були пов'язані з процесором, і вище, вони були пов'язані I / O. Це цікаве питання - можливо, я мушу колись знову взятися за це.
— Боб Мерфі
0

Першим у моєму списку побажань є твердотільний накопичувач. Це не матиме величезного впливу на час компіляції, але відкриття додатків стає різко швидшим (IDE, PhotoShop, ETC). http://joelonsoftware.com/items/2009/03/27.html

Найбільшим фактором часу компіляції буде процесор. Ви досить безпечно використовуєте це для еталону http://www.cpubenchmark.net/ .

— Еван
джерело
1
Тоді знову багато що залежить від вашої побудови ланцюга. Якщо ваш ланцюжок збирання використовує лише один потік для компіляції в багатопроцесорний процесор, багатоядерний або навіть багатопотоковий процесор, ви витрачаєте можливість для масових вигод. Простий бенчмарк процесора не показує, що, а контрольний показник компіляції буде корисним лише для заданої ланцюжка інструментів.
— asoundmove
2
Власне, експериментом я виявив, що коли ви робите паралельну компіляцію, вузьким місцем стає саме ваш диск. З причини, вам краще з повільнішим процесором і більш швидким диском, ніж навпаки.
— Боб Мерфі
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.