FreeBSD: ефект подвоєння розрядності
Так чи дає що-небудь перехід до 64-розрядності в плані швидкодії? Це питання мучило мене з того самого моменту, як я обзавівся машиною на AMD64. І в спробі відповіді на нього я провів таке невелике розслідування.
Як відомо, FreeBSD поточної гілки (а нею поки залишається 6-я, бета) існує в реалізації для обох платформ - і i386, 32-бітної, і AMD64, 64-бітної за визначенням (звичайно, є її версії і для більш інших платформ , але до предмету дослідження це відношення не має). Причому це не просто складання з відповідними процесорної-залежними прапорами, а саме самостійні гілки в дереві початкових кодів. Так що чого простіше - поставити на готівкову 64-бітну машину і той, і інший варіант це операційки, і виконати будь-якої тест на процесорний швидкодію.
Сказано - зроблено: встановлюю на конфігурацію, описану в одній з попередніх заміток, обидва варіанти FreeBSD 6.0 beta 1, поточної на той момент часу - в базовій установці, не виконуючи ніяких оптимізаційних заходів типу пересборки ядра і світу.
Як тест швидкодії не придумав нічого кращого, ніж складання ядра GENERIC - процес, тривалість якого переважно визначається швидкодією "каменю". Для мінімізації впливу дискової підсистеми (а у відповідній замітці ми бачили, що таке може бути значним) в каталог / usr / obj, призначений для проміжних продуктів компіляції, монтую mfs - файлову систему в оперативній пам'яті (Memory File System):
$ Mdmfs -s 1024m md / usr / obj
Ліміт на обсяг mfs (1024 Мбайт) узятий з дуже великим запасом, реально під збірку ядра буде задіяно трохи більше 200 Мбайт. І - вперед, на Харків:
$ Cd / usr / src
$ Make buildkrnel
з висновком команди date до і після складання в файл для результатів. Для фіксування часу можна було б скористатися і командою time - але так вже історично склалося, що до сих пір в цій якості я використовував саме date.
В обох системах процедура виконується тричі, з размонтированием каталогу / usr / obj після кожного разу, за результатами обчислюється середнє арифметичне, яке поміщається в таблицю.
Таблиця. Середній час збирання ядра GENERICAMD64 i386 AMD64-opt
678 905 642
Результати, повинен сказати, виявилися для мене дещо несподіваними: у варіанті для i386 ядро збиралося в середньому за 15 хвилин, в системі для AMD64 - приблизно за 11. Тобто виграш у швидкодії при переході на 64-розрядну ОС склав майже 30% (що наочно видно на діаграмі)
Малюнок. Порівняльне швидкодію 32- і 64-розрядних варіантів FreeBSD при компіляції ядра
Виникає питання - а чи не можна ще поліпшити показники швидкодії за рахунок додаткової оптимізації? Адже за замовчуванням базова система під FreeBSD збирається з прапором -O1. Тоді як нині, з переходом на gcc версії 3.4.X, можна використовувати і більш жорсткі прапори (за деякими відомостями, аж до -O3). Перевіряю: ядро і "світ" 64-бітової версії збирати заново з
винятком непотрібних (мені) опцій ядра: SCSI- і RAID-контролерів, зайвих мережевих адаптерів, невикористовуваних файлових систем;
винятком з "світу" зайвих компонентів, подібних Kerberos;
прапорами оптимізації
CPUTYPE = athlon64
CFLAGS = -O2 -pipe
COPTFLAGS = -O2 -pipe
Після чого триразово повторюю збірку ядра GENERIC. Результат не вражає - середній час компіляції знижується до 10 хвилин з невеликим (табл. Рис.), Тобто отриманий виграш не досягає навіть 10%. Чого, втім, і слід було очікувати: всі мої попередні виміри показували, що найбільший приріст швидкодії досягається при переході від -O0 (тобто відсутність будь-якої оптимізації) до -O1. Далі деякі крихти можна вичавити прапором -O2, а ось прапор -O3 в деяких випадках може привести до зниження швидкості.
Проте, висновок для щасливих володарів машин з процесором AMD64 очевидний: використання рідної 64-бітової версії FreeBSD дає значний приріст продуктивності (хоча, звичайно, на реальних користувальницьких завданнях він до 30% не дотягне).