Разработка
Подписаться на эту рубрику по RSS
Сборка Firefox для Windows работает быстрее сборки для Linux
Рубрика: Windows | Разработка | LinuxДата: 17/06/2009 00:24:26
Недавно прочитал новость на о том что даже под Wine Firefox работает быстрее родного варианта. Решил проверить: всё таки у меня Firefox собран "своими руками" можно сказать, а под Windows сборка рассчитана на совместимость с i586.
В использовались тесты , и . От использования я отказался ввиду того, что раз от раза он выдаёт разные результаты, т.е. по хорошему если его использовать, то надо запускать его несколько раз и усреднять результаты, а я - человек ленивый....
Тестирование проводилось в условиях: одноядерный Athlon64 3000+, 1GB RAM, Gentoo x86_64 (kernel 2.6.28).
Ниже результаты тестов.
:
| Тест | Firefox/3.0.6 (Native) | Firefox/3.0.6 (Wine) |
| Total Score: | 22.15runs/s ±5.30% | 28.24runs/s ±4.15% |
| ▶ 3D Mesh Transformation | 15.32runs/s ±11.28% | 26.22runs/s ±40.89% |
| ▶ 3D Raytrace | 30.60runs/s ±22.65% | 31.18runs/s ±13.33% |
| ▶ AES Encryption/Decryption | 14.01runs/s ±42.71% | 13.12runs/s ±7.45% |
| ▶ Arrays | 57.80runs/s ±4.57% | 64.22runs/s ±3.76% |
| ▶ Base 64 Encoding and Decoding | 22.07runs/s ±18.07% | 21.11runs/s ±23.14% |
| ▶ Bitwise And | 55.75runs/s ±1.40% | 45.64runs/s ±1.20% |
| ▶ Code Evaluation | 81.20runs/s ±33.84% | 85.26runs/s ±30.02% |
| ▶ Compute Bits in Byte | 17.06runs/s ±1.16% | 13.66runs/s ±1.24% |
| ▶ Compute Bits in Byte (2) | 21.84runs/s ±1.27% | 15.80runs/s ±1.34% |
| ▶ DNA Sequence Alignment | 39.26runs/s ±17.93% | 41.48runs/s ±9.06% |
| ▶ DNA Sequence Counting | 18.27runs/s ±2.63% | 19.66runs/s ±2.35% |
| ▶ DOM Attributes | 28.12runs/s ±8.26% | 37.57runs/s ±10.72% |
| ▶ DOM Attributes (Prototype) | 41.12runs/s ±8.19% | 61.07runs/s ±5.24% |
| ▶ DOM Attributes (jQuery) | 36.02runs/s ±5.52% | 46.58runs/s ±17.75% |
| ▶ DOM Events (Prototype) | 28.83runs/s ±32.56% | 36.07runs/s ±14.34% |
| ▶ DOM Events (jQuery) | 21.43runs/s ±15.26% | 26.56runs/s ±6.37% |
| ▶ DOM Modification | 10.11runs/s ±11.71% | 46.05runs/s ±7.59% |
| ▶ DOM Modification (Prototype) | 11.08runs/s ±7.34% | 15.06runs/s ±2.97% |
| ▶ DOM Modification (jQuery) | 19.58runs/s ±9.36% | 37.27runs/s ±6.47% |
| ▶ DOM Query | 112.18runs/s ±1.07% | 160.51runs/s ±2.25% |
| ▶ DOM Style (Prototype) | 30.43runs/s ±8.99% | 43.00runs/s ±5.74% |
| ▶ DOM Style (jQuery) | 20.10runs/s ±20.31% | 28.92runs/s ±9.31% |
| ▶ DOM Traversal | 6.32runs/s ±1.58% | 9.30runs/s ±1.13% |
| ▶ DOM Traversal (Prototype) | 26.84runs/s ±8.38% | 36.74runs/s ±6.26% |
| ▶ DOM Traversal (jQuery) | 12.17runs/s ±2.23% | 16.79runs/s ±2.23% |
| ▶ Date Formatting | 54.91runs/s ±25.13% | 72.39runs/s ±1.56% |
| ▶ Date Formatting (2) | 33.11runs/s ±39.51% | 38.37runs/s ±34.54% |
| ▶ DeltaBlue Constraint Solving | 19.29runs/s ±1.40% | 20.52runs/s ±1.34% |
| ▶ Fannkuch | 25.99runs/s ±0.94% | 21.75runs/s ±1.13% |
| ▶ MD5 Hashing | 39.50runs/s ±30.34% | 37.60runs/s ±1.03% |
| ▶ N-Body Rotation and Gravity | 12.98runs/s ±62.57% | 19.06runs/s ±1.68% |
| ▶ Partial Sum Calculation | 23.55runs/s ±57.08% | 47.93runs/s ±56.54% |
| ▶ Prime Number Computation | 12.77runs/s ±46.26% | 12.40runs/s ±30.19% |
| ▶ Prime Number Computation (2) | 10.18runs/s ±32.18% | 15.00runs/s ±4.04% |
| ▶ RSA Encryption/Decryption | 3.53runs/s ±16.88% | 3.50runs/s ±0.98% |
| ▶ RayTracer | 0.94runs/s ±27.14% | 1.55runs/s ±14.28% |
| ▶ Recursive Number Calculation | 49.20runs/s ±1.08% | 38.64runs/s ±2.50% |
| ▶ Regular Expressions | 10.17runs/s ±1.32% | 12.12runs/s ±1.41% |
| ▶ Richards Benchmarks | 36.57runs/s ±0.62% | 34.82runs/s ±1.13% |
| ▶ Rotating 3D Cube | 32.17runs/s ±40.61% | 30.39runs/s ±17.13% |
| ▶ SHA1 Hashing | 42.99runs/s ±2.53% | 35.34runs/s ±2.07% |
| ▶ Script Unpacking | 5.13runs/s ±11.92% | 5.48runs/s ±4.49% |
| ▶ Spectral Norm of a Matrix | 5.85runs/s ±180.44% | 28.99runs/s ±2.84% |
| ▶ String Parsing and Searching | 1.41runs/s ±34.47% | 2.41runs/s ±25.62% |
| ▶ Strings | 67.45runs/s ±6.29% | 62.34runs/s ±3.89% |
| ▶ Tag Cloud Creation | 23.29runs/s ±13.53% | 31.59runs/s ±18.38% |
| ▶ Traversing Binary Trees | 22.11runs/s ±1.84% | 28.03runs/s ±15.72% |
| ▶ Trigonometric Calculation | 45.32runs/s ±1.37% | 31.77runs/s ±1.69% |
| ▶ Validate User Input | 26.56runs/s ±34.56% | 27.43runs/s ±44.77% |
| Total Score: | 22.15runs/s ±5.30% | 28.24runs/s ±4.15% |
Первый тест подтвердил результаты из оригинальной статьи.
Идём дальше...
:
| Тест | Сравнение | Firefox/3.0.6 (Wine) | Firefox/3.0.6 (Native) |
| ИТОГ | 1.14x as fast | 11327.2ms +/- 2.3% | 9914.6ms +/- 1.4% |
| 3d | 1.23x as fast | 1456.8ms +/- 16.7% | 1182.4ms +/- 3.7% |
| access | 1.25x as fast | 1954.8ms +/- 2.3% | 1569.6ms +/- 2.1% |
| bitops | 1.32x as fast | 1725.6ms +/- 2.4% | 1304.8ms +/- 2.5% |
| controlflow | 1.26x as fast | 157.2ms +/- 0.7% | 124.4ms +/- 0.9% |
| crypto | 1.21x as fast | 730.4ms +/- 2.7% | 605.6ms +/- 3.7% |
| date | 1.16x as slow | 769.6ms +/- 5.6% | 889.2ms +/- 6.4% |
| math | 1.27x as fast | 1352.8ms +/- 1.6% | 1069.0ms +/- 3.7% |
| regexp | 1.09x as slow | 722.4ms +/- 3.9% | 789.6ms +/- 9.5% |
| string | - | 2457.6ms +/- 12.1% | 2380.0ms +/- 2.8% |
А вот тут получили диаметрально противоложный результат. Так что, не всё так однозначно...
Наконец собрались у меня KDE-4.2.1 и Qt-4.5. Уже устал ждать. Но ожидание моё оправдалось - пофиксили надоедливый баг в akregator'е(не запоминалась ширина столбцов). И у kwin с отрисовкой лучше стало - не затираются части окон магическим образом (раньше всплывающая подсказка в taskbar'е при исчезновении могла стереть часть активного окна...). Такими темпами KDE-4.3 будет очень даже юзабелен :)
Недавно умерла материнка (Gigabyte K8NS под s754). Самое интересное: видимых следов смерти на ней я не обнаружил... Ну да ладно.
В итоге, пришлось почти полностью обновить систему: материнку, процессор и память (видео встроенное). Одно обидно - выгоды от этого я особой не получил, разве что упеличение вдвое объёма оперетивной памяти, но это можно было бы и на старой системе сделать гораздо меньшими средствами.
А так: ну сократилось время сборки раза в полтора-два, и что? Не критично, это было. Зато вместо 5 PCI слотов (3 были задействованы) стало всего 2. Правда к ним добавились PCI express слоты...
Пришлось ещё перейти на проприетарный AMD'шный драйвер (RS780 aka HD3200)... Раньше у меня видео на резких изменения в кадре не мерцало - теперь мерцает. В mplayer'е вывод через opengl помог, а вот в xine (kaffeine) - нет.
Только что обнаружил для себя, что движок xrender для эффектов рабочего стола стал нормально работать. Последний раз, когда я его пробовал - это было, наверное, ещё при KDE версии 4.0 - им нельзя было пользоваться. Если мне не изменяет память, то он просто падал. А сейчас работает, и если отключить различные анимационные плавные переходы и полупрозрачность в эффектах, то вполне даже ничего. Правда с kaffine'ом из KDE 3, так же не всё гладко, как и вслучае использования в качестве движка opengl - левая панель наезжает на видео. Но главное, то что при перемещении окон, они двигаются плавнее, чем при использовании opengl. Это меня всегда раздражало, поэтому эффекты рабочего стола у меня всегда были отключены. Но теперь, если в дальнейшем не обнаружится проблем, буду их использовать с xrender.
Проблемы с удалением шаблонов в openSUSE
Рубрика: Linux | Windows | РазработкаДата: 17/06/2009 00:24:26
Вчера прочитал о том, что вышла бета KDE 4.3, и что вроде как есть бинарная сборка для openSUSE. У меня как раз она стоит в качестве попытки перехода на бинарный дистрибутив. В gentoo с kde-testing заморачиваться не хочется, тем более на рабочей системе.
Для начала решил почистить openSUSE, чтобы не качать обновления для всего попала. Обнаражил для себя шаблоны в zypper'е. Отлично! Нашёл шаблон kde4_games - будем сносить. Почитав man'ы, ввожу:
zypper rm -t pattern kde4_games
И что он мне пишет?
Удаление шаблона не определено и не реализовано.
Это ж надо. Так обломать. Погуглил и нашёл вот . По моему, стоило бы реализовать и другие предложенные варианты с возможностью выбора для пользователя, вместо того, чтобы заставлять пользователей писать вот такие вот вещи:
zypper rm `zypper if -t pattern kde4_games | grep 'i | '|gawk '{ print $3 }'`
Первый этап в переходе на раскладку Colemak.
Рубрика: Linux | Windows | РазработкаДата: 17/06/2009 00:24:26
Прошло три недели как я себя "насилую" переходом с раскладки QWERTY на раскладку . Этот рубеж ознаменовался тем, что я прошёл все упражнения в посвящённые этой раскладке. Правда результаты пока не впечатляют: я по прежнему не могу набирать не задумываясь, на автомате, а самое интересное, что при этом, я разучился набирать на QWERTY.
Через два часа поезд... Как бы хотелось, где-нибудь наконец обосноваться. Но текущий перезд не предвещает конца перездам. Еду в Москву, еду с желанием работать и развиваться, но без желания там с концами оставаться... Когда же у нас в стране появится уютный, стабильный центр разработки ПО.
Казалось бы восстановление утраченных фотографий окончено, но при беглом осмотре обнаружились повреждённые фотографии, которые бы неплохо отсеить. Фотографий много, поэтому вручную каждую просматривать не вариант. В поиках вариантов обратил внимание на модуль для работы с изображениями . Путём экспериметов обнаружилась закономерность: на всех проверенных повреждённых фотографиях функция histogram выбрасывала исключение. Эта особенность и была положена в основу приведённого ниже скрипта. Он (скрипт) принимает два аргумента: исходную директорию и результирующую директорию. Скрипт проходит исходную директорию, включая поддиректории, и переносит повреждённые изображения в результирующую директорию. Так же переносимые файлы переименовываются по следующиему шаблону: [имя_директории]_[имя_фала]. В ситуации с вложенностью, описанной в предыдущей статье, это обеспечивает несовпадение имён.
Вот собственно текст скрипта:
import os
import sys
import Image
import shutil
def check_file(file, output_dir):
print 'Processing file ' + file + ': ',
im = Image.open(file)
try:
im.histogram()
print 'Fine'
except IOError:
print 'Broken. Moving...'
dir, file_name = os.path.split(file)
file_name = os.path.split(dir)[1] + '_' + file_name
shutil.move(file, os.path.join(output_dir, file_name))
except KeyboardInterrupt:
print 'Exiting...'
sys.exit(1)
except:
print 'Unexpexted exception'
for root, dirs, files in os.walk(sys.argv[1]):
[check_file(os.path.join(root, f), sys.argv[2]) for f in files if f.endswith('.jpg')]
Вчера обнаружил в портежах обновление Qt. Обновился он до Qt 4.5.0 RC1. Надавно как раз прочитал, что (упоминание об этом в последнем обзаце). Решил проверить. И о чудо - действительно работает быстрее. Конечно это всё по ощущениям, но кажется что время отклика действительно уменьшилось. А вот насчёт стабильности пока ничего не могу сказать - надо поработать, а там будет видно.
Только что запостил свой первый bug, точнее feature request в Постепенно превращаюсь в нормального пользователя свободного ПО :)
Теперь ещё исходники поправить самому и патч им отправить, что собственно они и рекомендуют.