FreeBSD: ефекта на удвояване бита

Така ли нещо се преместят в 64-битова гледна точка на изпълнението? Този въпрос ме измъчваше от момента имам колата за AMD64. И в опита си да му отговорите, прекарах малко разследване.

Както е известно, съществува FreeBSD ток клон (тъй като тя все още е на 6-тия бета) в изпълнението на двете платформи - и i386, 32-битова, а за AMD64 машини, 64-битова версия по подразбиране (разбира се, е неговата версия и още други платформи но предмет на изследването не е от значение). Това не е просто съвкупност със съответните процесори специфични флагове, а именно независими клонове в изходния дървото. И така, какво би могло да бъде по-просто - сложи на 64-битова машина за пари на, и той и другият вариант е да се операционни системи, както и извършване на всякакви тестове на скоростта на процесора.

Каза - извършва: инсталиране в конфигурацията, описана в един от предишните бележки, и двете версии на FreeBSD 6.0 бета 1, токът по това време - в базовата инсталация, без да се извършват каквито и оптимизация мерки като възстановяване на ядрото и света.

Тъй като не се сетя за нищо по-добро представяне тест от ядрото построен GENERIC - процес, по време на която се определя предимно от скоростта на "камък". За да се сведе до минимум въздействието на диск подсистема (и съответната бележка, видяхме, че такава може да бъде значителен) в директорията / ЮЕсАр / OBJ, предназначена за междинни продукти за съставяне монтирани MFS на - на файловата система в RAM (памет File System):
$ Mdmfs -s 1024m MD / ЮЕсАр / OBJ

Ограничението за размера на MFS (1024MB) се приема с много голям марж, всъщност е основната събрание ще включва малко повече от 200 MB. И - да предаде Харков:
$ CD / ЮЕсАр / SRC
$ Направи buildkrnel

с оттеглянето на командата дата, преди и след монтажа на файл за резултатите. За да се определи времето, може да се използва времето и екипа - но така исторически, че досега в тази, както аз съм го използват дата.

И в двете системи, процедурата се повтаря три пъти, с демонтиране директорията / ЮЕсАр / OBJ след всяко време, в съответствие с резултатите, изчислени от средната аритметична стойност, която се поставя в таблицата.

Таблица. Средно време монтаж ядрото GENERICAMD64 i386 AMD64-неучастие
678905642

Резултатите, трябва да кажа, за мен се оказа малко по-неочакван: във версията за i386 ядрото ще са средно с 15 минути, в система за AMD64 - около 11. Това означава, че печалбата в производителността при преместване в 64-битова операционна система е в размер на почти 30% (което ясно се вижда на фигурата)

Фигура. Сравнителна производителност 32-битови и 64-битови варианти на FreeBSD ядро ​​по време на компилация

Това повдига въпроса - възможно ли е за по-нататъшно подобряване на ефективността на изпълнението се дължи на допълнителна оптимизация? След по подразбиране в FreeBSD система за база ще -O1 флаг. Докато сега, с преход към GCC версия 3.4.x, можете да използвате по-строги знамена (според някои източници, до -O3). Проверка: ядрото и "мир" 64-битова версия е възстановено с
с изключение на ненужните (I) опции на ядрото: SCSI, RAID-контролер, излишни мрежови адаптери, неизползвани файлови системи;
С изключение на "света" от допълнителни компоненти, като Kerberos;
флагове за оптимизация
CPUTYPE = Athlon64
CFLAGS = -O2 -pipe
COPTFLAGS = -O2 -pipe

След три повторения, повторете GENERIC ядрото сглобяване. Резултатът не е впечатляващ - средно време на натрупване се намалява до 10 минути с малък (Таблица фиг ..), т.е. печалбата, получена не достига дори 10%. Какво, обаче, може да се очаква: всичките ми предишни измервания показват, че най-голямото увеличение на скоростта се постига чрез преместване от -O0 (т.е. липса на оптимизация), за да -O1. Освен това, някои парчета могат да бъдат притиснати -O2 флаг, но -O3 на знамето в някои случаи може да доведе до процент намаление.

Независимо от това, на изхода за късметлиите собствениците на превозни средства с AMD64 процесора е ясно: използването на родния 64-битова версия на FreeBSD осигурява значително увеличение на производителността (въпреки че, разбира се, на реални проблеми на потребителите, че е до 30% не го правят).