Тестирование браузеров в JS-бенчмарке «Octane»

Приветствую,

В августе корпорация Google в представила свой JavaScript-бенчмарк Octane, который …бла-бла-бла меряет производительность js-движка браузера в реально использующихся js-библиотеках. Ну что ж, глянем на показатели в Linux-браузерах по состоянию на март 2013 года:

Как видно, использовались как подготовленные бинарные сборки, так и самостоятельно скомпилированные (gentoo же). Опера, традиционно, в бинарниках. Использовался последний тестовый gcc 4.7.2-r1 с довольно безопасными опциями компиляции: CFLAGS=”-march=native -O2 -pipe -fomit-frame-pointer -flto”.  А вот Rekonq и QupZilla не смогли в полной мере пройти все тесты (результаты выделены красным). Бенчмарк честно предупреждает: “Warning This JavaScript engine does not support Typed Arrays.” и пропускает по два этапа. Жаль.

Какие же можно сделать выводы?

• самостоятельная компиляция браузера даст Вам 1-2% скорости;
• результат Opera на устаревшем движке Presto никуда не годится;
• Rekonq и QupZilla просто не готовы для постоянного использования, они не доделаны (ещё?).

 

P.S. Возможно Вам будет небезынтересен своеобразный бонус – результаты тестов на том же железе браузеров под Windows:

дропбокс для KDE — kde-misc/kfilebox

Вкратце:

• Существует kde-misc/kfilebox отличный dropbox-клиент для KDE.
• В дополнение к нему можно включить контекстное меню в Dolphin –> https://wiki.mageia.org/en/Dropbox
• Официальный мобильный dropbox-клиент не хранит файлы локально, устанавливайте dropsync с маркета и выбирайте папку для синхронизации.
• По умолчанию даётся 2 Гб в облаке.
• Там-же пройдя трёхминутное обучение (https://www.dropbox.com/gs) можно получить ещё 250 Мб навсегда.
• Ещё 500 Мб можно получить за https://www.dropbox.com/getspace (пиар-посты в ваш фейсбук и твиттер).
• Мобильный клиент может загружать ваше фото-видео в облако автоматически. За это даётся место, по 500Мб за раз. Не более 3Гб. Ваша задача снять несколько видео своих обоев (или потолка) общим размером в 2,6 Гб. После загрузки в облако удалить файлы, место освободится, а бонус останется.
• Плюс система рефералов, читерим 32 учётки и получаем за каждую постоянный бонус в 500 Мб.
• Вот такой квест) Любит наш человек халяву =)
• Чит: владельцы андроид-устройств могут попасть под акцию от Samsung (+48 гигов на два года бесплатно). Я так и сделал. Galaxy S II (Jelly Bean 4.1.2) Нужно просто установить мобильный dropbox и зайти в свой аккаунт.

Итого: 2+0,25+0,5+3+16+48 = 69,75 Гб. 

Включение LTO-оптимизации при сборке мира

LTO – Link Time Optimization, по-русски это сборка с использованием оптимизации во время динамического связывания. LTO-оптимизации отличаются учётом состояния всех файлов, участвующих в процессе сборки, в то время, как традиционные режимы оптимизации оптимизируют каждый файл по отдельности и не учитывают условия вызова функций, определённых в других файлах. Например, при LTO для функций из других файлов возможно inlinе-развёртывание, в исполняемый файл не включается неиспользуемый код, осуществляется проверка типов для всей программы, производится общая оптимизация на уровне проекта в целом.

В общем штука полезная, однако ещё не до конца доделанная, местами могут случаться эксцессы. Конечно с каждой новой версией gcc их всё меньше и меньше, и всё больше соблазн попробовать собрать мир с флагом -flto , приступим:
- собираем последний gcc (4.7.2)
- добаляем -flto в CFLAGS
- создаём /etc/portage/env/no-lto , в него пишем:

CFLAGS="${CFLAGS} -fno-lto"
CXXFLAGS="${CXXFLAGS} -fno-lto"
LDFLAGS="${LDFLAGS} -fno-lto"

- создаём /etc/portage/package.env , в него пишем:

app-text/rarian no-lto
app-text/sgml-common no-lto
dev-lang/perl no-lto
dev-libs/elfutils no-lto

#for gtk+
dev-libs/glib no-lto

dev-util/ragel no-lto
kde-base/kdelibs no-lto
kde-base/okteta no-lto
kde-base/okular no-lto
media-libs/alsa-lib no-lto
media-sound/clementine no-lto
media-sound/wavpack no-lto
=media-video/avidemux-2.5.6-r2 no-lto
media-video/mplayer no-lto
net-analyzer/mtr no-lto
x11-base/xorg-server no-lto
x11-libs/wxGTK no-lto

Это ничто иное, как список из названий пакетов, не собирающихся текущей версией компилятора в рабочий бинарник (с использованием-LTO оптимизации). Поэтому указываем системе portage собирать их без этой опции. Страшилки о увеличении времени сборки в разы и потребления памяти в десятки гигабайт ничто иное как страшилки, не будем повторять тут эти глупости).
Как видно, из 738 пакетов в моём мире лишь 17 потребовали сборки “по старому”, имхо gcc-4.7.3 или gcc-4.7.4 уже не будет hardmasked. И это хорошо)

Ext2fsd v0.51 портит данные

Не вздумайте использовать Ext2fsd v0.51 на ext4 разделах более 2Тб — портит данные. На разделах менее терабайта проблем не видно.

Загрузка десктопа, ч.2

Шаманю дальше, убрал nvidia видеокарту, настроил встроенную в процессор (Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller, Kernel driver in use: i915), получилось вот так:

Система грузится уже за 10,8 секунды, что ИМХО очень и очень неплохо. Да и DRM — вещь: теперь мало того что в консольке (ctrl+alt+f1) разрешение экрана 1920х1080 (против VESAFB, безальтернативно используемого с nvidia-driver, где 1280х800 самое больше широкоформатное разрешение), так ещё и переключение между режимами происходит за доли секунды (вместо единиц секунд с nvidia-driver). Ляпота!

P.S. xorg.conf

Section "Device"
        Identifier      "SandyBridge"
        Driver          "intel"
EndSection

Section "Monitor"
        Identifier      "Monitor0"
        VendorName      "Unknown"
        ModelName       "LG Electronics E2360"
        HorizSync       30.0 - 83.0
        VertRefresh     56.0 - 75.0
        Option          "DPMS"  "1"
EndSection

Section "Screen"
    Identifier     "Default Screen"
    Device         "Intel SB IGC"
    Monitor        "Monitor0"
    DefaultDepth    24
    SubSection     "Display"
        Depth       24
        Modes       "1920x1080"     "1280x800"
    EndSubSection
EndSection

загрузка десктопа

Система грузится за 18,0 секунд, из которых 11 “читых” (груб и далее). Из этих 11-ти драйвер nvidia тупит ещё секунды 2-3, может попробовать nouveau, что думаете?

Конфиг:
CPU – Intel Core i5-2500k (100×33@1,20v OC to 100×46@1,36v)
MB – AsRock Z68 Pro3 (Realtek ALC892, Realtek RTL8111E)
RAM – Kingston KHX1600C9D3K2/4GX (2×2 Gb DDR3-1600 9-9-9-27 1T 1.65v @ DDR3-1600 8-9-8-24 1T 1.60v)
GPU – GeForce GTX 260 (55nm) 216 SP 896 MB (448-bit GDDR III), 625/1350/2200@1,12v OC&UV 675/1350/2200@1,05v (зашил в биос)
SSD – 128Gb Crucial C300
HDD – 1000Gb Samsung HD103UJ
HDD – 750Gb WDC WD7500AAKS (умер не предупредив SMART)
ODD – none (ненужен)
PSU – ATX 600W Xilence SPS-XP600
Chassis – Deluxe DLC-SH496
CPU cooler – Cooler Master Hyper 212 Plus
Display – LG 2360V
Webcam – Logitech HD Webcam C310
ОС – Gentoo Linux + Windows 7 Home Premium 64-bit SP1

Корень на ext4, native-ACHI и проприетарный nvidia-driver. KDE SC 4.7.90 (4.8 Beta2)

твердотельный ssd-накопитель: немного шаманства, пару слов о TRIM и почему btrfs «не тру»

Приветствую (^_^)

Пожалуй как всякий гик, прикупив новый девайс (Crucial C300 на Marvell 88SS9174), я вплотную занялся изучением того, что, собственно, эта недешёвая железяка может. Перенеся систему на ssd и восхитившись шустрой загрузкой (17 секунд против 41-й на 7200rmp терабайтнике от самсунг) пришло время разобраться с такой мудрёной штукой как TRIM. Так вот, вопреки распространённому мнению “Да это ж Линукс! Там всё изаропки и как нада” не всё так радужно. Ядрышко то наше собстенно TRIM то и не поддерживает. Это, оказывается, задача файловой системы! (о как, сюрприз-сорприз). Причём по дефолту оно выключено везде. Ну не разгильдяйство ли? Не верите? А вот вам тру-статья для проверки своих ssd.

Проверка, а не включён ли trim уже сейчас

Пусть /dev/sdX – наш SSD диск

1. Меняем пользователя на root:
   sudo -i
2. Пишем файл 50Мб со случайными данными:
   dd if=/dev/urandom of=tempfile count=100 bs=512k oflag=direct
3. Ищем стартовый LBA адрес у файла
   hdparm --fibmap tempfile
4. Читаем данные со стартового LBA адреса файла, замените [ADDRESS] на свой Starting LBA address из вывода предыдущей команды:
   hdparm --read-sector [ADDRESS] /dev/sdX
5. Теперь удалим временный файл и синхронизируем ФС:
   rm tempfile
sync
6. Повторяем пункт 4:
   hdparm --read-sector [ADDRESS] /dev/sdX

Если TRIM включен, то в результате вывода должны быть одни нули, если же их нет TRIM выключен.

Вот так вот, подумал я и засел читать доки. Оказывается, опция монтирования discard (включающая TRIM для файловой системы) поддерживается далеко не всеми файловыми системами. К примеру ext4 и brtfs умеют, а вот reiserfs v3 грязно ругается в логи о том что такой опции знать не знает и не работает.

А теперь плавно переходим к тому, почему brtfs не тру. Дело в том, что пару лет назад я довольно плотно исследовал вопрос “как бы это разбить диск (hdd) так, чтобы всё работало пошустрее”. Ну /boot и /home отдельным разделом это классика. А дальше? Если отформатировать корень в reiserfs это положительно скажется на скорости работы портажа, тот-же eix-sync уж очень любит reiserfs, оно и понятно: работа с тувой хучей мелкий файлов это конёк reiserfs. Однако посмотрев на скорость работы с файлами среднего размера (1-10 МБ) выясняется что ext4 торт. Да и плюшки типа экстентов это тру. В результате сих, впрочем не особо сложных размышлений, было принято решение: корень в ext4; /usr/portage/ ,как отдельный раздел, в reiserfs размером 512 МиБ (это важно, дальше всплывёт), и из /usr/portage симлинком вынести distfiles на другой раздел (файлопомойку). В результате получилось просто и элегантно: система на ext4 шустро крутится, portage работает с разделом на 512 МиБ (заполненным на 400 МиБ) в reiserfs и делает это реально быстро, да и distfiles на файлопомойке никому не мешают.

Сия идиллия продолжалась до появления ssd: раз reiserfs не умеет монтироваться с опцией discard было принято стратегическое решение “ну и фиг с тобой, сделаю раздел на гиг в ext4, делов то”. Не тут то было — знаете сколько инодов на разделе такого размера? Нет? А я знаю: явно меньше чем файлов в /usr/portage xD Он туда просто не влез. Не хватило inodes. И это несмотря на то, что размер был увеличен в 2 раза по сравнению с reiserfs где всё каком-то чудом умещалось. Почесав тыковку, вспомнил что была ещё какая-то fs без инодов (точнее с бесконечным количеством оных), уж не btrfs ли? en.wikipedia.org — она самая! уря-уря. Сношу гиговый ext4, форматирую в btrfs (зараза, пришлось ядро пересобирать), и вот оно счастье? Как бы не так. На ядре 3.0.1 оно к сожалению сыпет call stack-ами в логи тупо при чтении содержимого раздела. Ну да, experemental в ядре, но не при чтении только что созданного раздела же!!! Поимейте совесть, записав 600Мб я смог назад отчитать только 300. И получил 1,2 Гб (!!) мусора в dmesg. Ну её, такую бяку. К тому же размер тома штатно менять нельзя.

В конце концов просто перенёс /usr/portage/ на “родину”, в корневой раздел, и на этом всё. Надеюсь шустрый ssd нивелирует не шуструю ext4 при чтении туевой кучи мелких файлов. Спасибо за внимание :)

P.S. Не делайте для ext2/3/4 tune2fs -o journal_data_writeback /dev/sdaX , это хоть и выключит журнал для метаданных, но с ним выключится и TRIM.

P.P.S Чтобы прикинуть сколько данных и кто пишет на диск можно использовать что-то типа iotop -a (оставьте в фоне на пару часов), там будут строки вида [jbd2/sda2-8] — это метаданные. Так-же можно посмотреть объём записанного на ext командой tune2fs -l /dev/sda4 | grep eti