Тестируем Potlatch 2

лет холи вор бегин

Это про что?

видимо про языки высокого уровня

  • тему можно закрывать :slight_smile:

Ban Potlatch!! постепенно трансформируется в Ban Flash!!!

Я просто не понял где у нас в обработке больших объемов данных применяются интерпретируемые ЯВУ.

Ну лично я бы и про potlatch что-нибудь сказал, если бы он хотя бы как-то работал.

Java - язык интерпретируемый. Откуда, собственно, тормознутость josm’а и происходит.

как же так???

А иначе с какой бы стати ему нужна была виртуальная машина?

Ни в коем разе, там JIT. В современных javascript и флеш движках, кстати, тоже.

интерпретируемый != тормознутость
Josm != Potlatch

  1. Potlatch (тормозит)
  2. Merkaartor (практически не тормозит)
  3. Josm (не тормозит)
    Все зависит от кодера…

Вообще-то для переносимости между платформами.

Я бы расставил акценты несколько иначе. На мой взгляд, josm тормозит больше, чем poltach. Возможно, это из-за того, что обычно я работаю на Atom. Но именно на процессорах низкой производительности и проявляется тормознутость в наибольшей степени.

А от кодера - да, зависит. Причем в гораздо большей степени, чем от того, компилируемый язык или интерпретируемый. Но факт остается фактом: на процессорах типа Atom JOSM тормозит нещадно. Я, например, не могу с ним работать.

На С тоже пишут переносимый код. Но виртуальная машина для него не нужна.
В том то и дело, что текст java компилируется не в native код, а в байт-код, который процессор выполнять не способен. Может только интерпретировать.
Правда, уже после появления java были разработаны процессоры, способные выполнять байт-код, но x86 к ним не относится.

Для переносимости между платформами там байткод, а VM - чтобы его исполнять. Это можно делать прямой интерпретацией, либо предкомпилированием в нативный код, что она и делает. Это и есть JIT.

JOSM не так чтобы особо тормозной, но java жрет память, причем совершенно бесполезным образом - вот это самая гадость. Система лезет в своп - начинаются тормоза. Я не спец по java, но могу предположить что она в целом медленнее работает потому что, во-первых, у JIT не особо много времени на оптимизацию под целевую платформу, ибо нативный код надо скорее начать исполнять, во-вторых, gc, а лишний indirection, всякие счетчики ссылок, и собственно реальная трата циклов когда он работает, и в-третьих, тот факт, что добавляется дополнительная прослойка для вызова библиотечных функций, тех же X11 и GL. В общем то, что когда домиков очень много он действительно рисует их не очень быстро - скорее всего не шибко эффективная работа с GL, что от языка не зависит.

А байт-код - в нативный. Но таки да - “преимущество” жавы в плане бинарной переносимости в FOSS мире скорее недостаток.

К слову, я лулзов ради за ночь написал на C парсер .osm - пока он в 6-8 раз быстрее expat и libxml2 (SAX обертка над ним в 1.5 раза медленее). Интересно было бы его сравнить с тем, что используется в osmosis. А вообще как раз большие-то объемы данных можно обрабатывать и интерпретируемыми языками, гораздо более высокие требования - у интерактивных приложений.

Кстати, может быть. На мой взгляд, 1 Гбайт памяти на 5 Мбайтную карту - вполне достаточно. Но JVM может считать иначе.

По моему опыту, чтобы GL начал тормозить, нужно скормить ему не менее 100000 объектов. Я сильно сомневаюсь, что “много домиков” дотягивают до таких цифр.

Ява не разу не интерпретируемый язык. Сначала компиляция до байт-кода, а потом исполнение в виртуальной машине. И тормознутость как раз из-за ВМ.
Интерпретируемыми ЯВУ являются python, perl, rexx и пр. Где нет другого представления программы, кроме как в исходном коде.

Ну, я неспособен написать парсер OSM за ночь - у меня это занимает примерно на порядок больше времени (неделя-две). Но скорость обработки почти не отличается от времени простого копирования. Т.е. основное время уходит на операции с диском, чем на собственно обработку процессором.
Интерактивные приложения - да: один кадр должен строиться не дольше 30-50 мс на среднем компьютере и не дольше 150 мс - на мобильной архитектуре.
Ну а для пакетной обработки приемлемыми временем считаю от единиц секунд (правда, для 4 Гб файла это нереально) до единиц минут (что для указанного объема вполне достижимо).

А что процессор делает с байт-кодом?
Он его ин-тер-пре-ти-ру-ет!