Архив категории: programming

javascript programming web

Используем Leaflet JS для географических данных

Итак, задача на сегодня:

  1. Отобразить некий уголок земного шара на карте
  2. Выделить интересную область карты
  3. Пометить ключевые объекты
  4. Добавить описания
  5. Реагировать на зум карты, отображая только нужную информацию

Для всего этого воспользуемся открытыми картами — Open Street Map и библиотекой JavaScript — Leaflet JS.

Читать далее »

DSL java perl programming

Не нравится язык? Напиши его себе сам.

Во время поиска документации по незнакомым функциям стандартной библиотеки, наткнулся на удивительную фичу Perl’а — source filters. Она позволяет выполнять препроцессинг исходного кода перед выполнением. Обработка может производится как кодом на C, так и кодом на самом Perl’е, что является наиболее переносимым вариантом.
Так чего же он нам позволяет добиться?
Многого! Например можно добавить возможность использовать прототипы функций с именованными аргументами, которые появятся только в Perl6.

Или изменить синтаксис чуть сильнее:

Читать далее »

java programming web

Встраиваем Jetty

Про встраивание веб-сервера Jetty написано много руководств, где чаще всего приводят такой код:

И тут нас ждёт разочарование — мы должны запускать Jetty с ресурсами из файловой системы:

  • «/WEB-INF/web.xml»
  • «../src/main/webapp»

Появляется ощущение, что нас кто-то обманул, и на душе горько.
Меня не остановил этот провал, и я пошёл до конца.

Читать далее »

perl programming

Лексер для Perl

Меня всегда интересовал вопрос: «В чём основная сложность разработки плагинов для IDE для динамических языков?». Посмотрев код плагина поддержки Perl для Eclipse и почитав форумы, я обнаружил что порой программа может быть правильно разобрана на лексемы только самим интерпретатором, например в случае, когда порядок разбора зависит от уже произведённых действий при разборе. Наглядный пример:

В котором последняя строка может содержать как регэксп так и деление в зависимости от прототипа загруженной функции. Читать далее »

javascript parallel computing programming

Жуткий матан на javascript

Не отпускает меня эта[1][2] вычислительная задачка. Нафигачил её теперь на js. С блэкджеком и шлюхами Web workers. В итоге получилось около 40 секунд(в Chrome) — быстрее чем нативный код (сгенерированный gcc-4.4 с -O3) в один поток! Выложена на GitHub Pages. Файл с исходными данными.
Screenshot-nazarov-yuriy.github.io-Poincare-web- - Google Chrome Читать далее »

performance programming

Погрешность вычислений с числами с плавающей запятой

В ходе всех этих развлечений с оптимизациями обнаружился интересный, но очень неприятный эффект. Результат вычислений для разных компиляторов и разных флагов оптимизации порой значительно менялся.
Для более удобного наблюдения этого эффекта был выбран простой пример(полный код на github):

В этом маленьком тесте изменение результата от изменения флагов обнаружить не удалось, но всё равно обилие результатов удивляет — 5 различных, с 13 совпадающими знаками из 15-17 возможных для double.

Исходник и компилятор Результат Время выполнения, с
Assembler 1.53436944477410652787 3.81
gcc long 1.53436944477462278158 4.4
gcc double 1.53436944477389380914 4.4
icc long 1.53436944477397574360 6.88
icc double 1.53436944477334602510 1.50

*результаты по одному измерению, по этому совсем серьёзно воспринимать их не стоит. Время указано для процессора FX-8120
p.s. ну и обнаружилось, что написание кода на ассемблере пока ещё не абсолютно потеряло смысл — получился до 15% быстрее, чем на C.

performance programming

CUDA мы катимся?

Сразу извиняюсь за название — взято с потолка.
Неудержался и нафигачил вычислительную задачу, которую уже упоминал в прошлых топиках на CUDA. Ничего хитрого не делал — просто расставил директивы __device__.
В итоге получилось даже медленнее чем на CPU раз в 5 :’-(
Сей ужас можно увидеть здесь.

performance programming

Хватит использовать устаревший софт!

Каким бы тёплым и ламповым старый софт не был, но рано или поздно от него приходится отказываться, и сейчас я покажу это на примере компиляторов.
Допустим у нас есть приложение, которое выполняет некоторые вычисления.
Попробуем скомпилировать его различными версиями gcc и icc. И измерим время выполнения. Опции компиляции следующие:

Версия компилятора Время выполнения,c Во сколько раз медленнее лидера
gcc-4.1 70.0 3.68
gcc-4.3 45.3 2.38
gcc-4.4 45.9 2.42
gcc-4.5 34.9 1.84
gcc-4.6 34.7 1.83
gcc-4.7 34.9 1.84
icc-13.1.1 19.0 1.0

Читать далее »

perl

Исключения в Perl

Одним из возможных вариантов мне видится:

Читать далее »

build linux performance programming

Операционные системы и фарс с производительностью

Закончился простой тест производительности двух ОС: Windows 7 и Linux (Xubuntu 12.10)

Эксперимент:

  1. Выбирается проект на Java, с большим числом модулей, проектных файлов, зависимостей и этапов сборки
  2. Собирается начисто без замеров времени
  3. Собирается повторно, время замеряется, этот этап повторяется несколько раз, вычисляется среднее время

Использовались: система сборки Gradle (режим --daemon), JDK 1.7_13 (x64).
Файловые системы: Windows — NTFS, Linux — ext4.
Все ОС в тесте 64-битные, файлы проекта и файлы системы (а также приложений) расположены на разных физических дисках.
Для виртуальной машины использовался Oracle Virtual Box (4.1), в качестве хоста Windows 7, без дополнительного дискового кэша на стороне VM.

Итого:

Операционная система Время сборки, сек (PC 1) Время сборки, сек (PC 2) Время сборки, сек (PC 3)
Windows 7 20.5 22.0 21.2
VM Xubuntu 12.10 14.6
Xubuntu 12.10 9.4 9.6

Приведённые результаты для машины, на которой пробовались все варианты ОС, получены без специальных настроек производительности.

Результаты плачевны. И можно сколь угодно спорить о настройках, тюнинге, особенностях. Интегральная производительность вот такая.
Ну а я уже перешёл на правильную ОС.