Здравствуйте, Pavel Dvorkin, Вы писали:


PD>Спасибо за приглашение . Остается подождать, когда это ПО будет по функциональности обеспечивать хотя бы 20% от того, что делают серьезные пакеты , написанные на нативном коде. Когда появится нечто похожее на Фотошоп, Автокад, Ворд и т.д. Вот тогда я готов буду принять, что подобное ПО можно писать не на нативных языках.
Там уже больше 20%:

Здравствуйте, Sinclair, Вы писали:

PD>>Спасибо за приглашение . Остается подождать, когда это ПО будет по функциональности обеспечивать хотя бы 20% от того, что делают серьезные пакеты , написанные на нативном коде. Когда появится нечто похожее на Фотошоп, Автокад, Ворд и т.д. Вот тогда я готов буду принять, что подобное ПО можно писать не на нативных языках.
S>Там уже больше 20%:
WordPad-а разве что.

Здравствуйте, monax, Вы писали:

M>Новые языки программирования растут как грибы после дождя. Старые набирают комьюнити. На вскидку популярные языки, которые на слуху: C, C++, C#, Java, VisualBasic, PHP, Python, Perl, JavaScript, lisp, scala, Deplhi, erlang, D, Dart, ObjectiveC, ActionScript, Lua, Ruby — какие-то из них мало используются (D), но всё равно на слуху. Так вот, большинство из этих языков интерпретируемые или компилятся в свой байт-код, нативный код из коробки дают C, C++, ObjC, Delphi, D и всё. Почему так мало языков, которые компилятся в нативный код?

Нативный код дискредетировал себя проблемами со стабильностью и безопасностью. Единственное на чем он сейчас держится это низкоуровневый контроль ресурсов.

Здравствуйте, Sinclair, Вы писали:

S>Там уже больше 20%:

Ты серьезно ?

Вот сейчас простой эксперимент сделал. Открыд LibreOffice Writer (у меня нет Word), в нем открыл некий pdf, из него вырезал первую страницу и вставил в новый документ. После этого просто запустил некий jpg, он открылся в Photo Editor, там я сделал Copy и вставил эту картинку в новый документ. После этого документ сохранил и открыл заново. Все нормально, заняло секунд 20.

Делаем то же в этом самом Word Web App.

Загружаю файл. Он отправляется, жду секунд 15. Появился.
Открываю его. Появляется окно с pdf viewer (а это, между прочим, нативный плагин) и загружается. Тоже секунд 15
Вырезаю страницу и копирую.
Черт возьми! Я этот pdf открыл просто щелчком, поэтому в том же окне. Ладно, Back
Открываю документ. Хочу вставить. нет, сначала надо "Редактировать в броузере" (а я где, спрашивается?). Ладно, жму
Вставляю из Clipboard. Почему-то не та кодировка, так что прочитать ничего нельзя. Ладно, простим.
Хочу добавить фотографию. Добавляю. Отсылается на сервер, еще секунд 10. Наконец появляется и встает по месту курсора. А я не там хочу! Пытаюсь сдвинуть мышью. Черта с два. Пытаюсь сжать по горизонтали (в офисе без проблем). Тоже черта с два.
Нажимаю в офисе правую кнопку на фотографии. Тут впору горькими слезами заплакать. И Flip там, и Crop, и поля задать, и Alignment, и Bring To Front / Send To Back и чего там только нет. А в Web все, что есть — это "Вырезать" , "Копировать" и "Вставить".

Я уж не говорю про VBA приложения для Office.

Так что извини. До standalone редактора тут очень далеко. Я не спорю, это несколько лучше, чем какой-нибудь js редактор из какой-то cms, но до Word очень далеко.

А всем этим графическим редакторам до Фотошопа — как до другой галактики.

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Я сейчас как раз имею дело с этими пакетами, код на Питоне писал не я. Я его аккуратно переписал на Яву (1:1) и явовский код работает примерно в 20-30 раз быстрее.

А может стоило попробовать реализацию питона под джаву: Jython?

Мне кстати самому интересно, как соотносятся про производительности Jython и Java.

Здравствуйте, D.Lans, Вы писали:

DL>Здравствуйте, Pavel Dvorkin, Вы писали:

PD>>Я сейчас как раз имею дело с этими пакетами, код на Питоне писал не я. Я его аккуратно переписал на Яву (1:1) и явовский код работает примерно в 20-30 раз быстрее.

DL>А может стоило попробовать реализацию питона под джаву: Jython?

DL>Мне кстати самому интересно, как соотносятся про производительности Jython и Java.

А мне интересно, во что скомпилится этот Jython. Напиши какой-нибудь код под него(пусть будет простой — с математикой, хотя можно добавить пару фирменных фишек Питона), скомпиль в жабовский байткод, декомпиль(не в жабу, а в читабельный вид — асм байткода — http://www.varaneckas.com/jad), листинги в студию.
А я напишу это же на жабе, и сделаю то же самое. И сравним на низком уровне, что вышло. Там сразу видно будет, байткод очень простой для понимания.

Здравствуйте, Eugeny__, Вы писали:

E__>Здравствуйте, D.Lans, Вы писали:

DL>>Здравствуйте, Pavel Dvorkin, Вы писали:

PD>>>Я сейчас как раз имею дело с этими пакетами, код на Питоне писал не я. Я его аккуратно переписал на Яву (1:1) и явовский код работает примерно в 20-30 раз быстрее.

DL>>А может стоило попробовать реализацию питона под джаву: Jython?

DL>>Мне кстати самому интересно, как соотносятся про производительности Jython и Java.

E__>А мне интересно, во что скомпилится этот Jython. Напиши какой-нибудь код под него(пусть будет простой — с математикой, хотя можно добавить пару фирменных фишек Питона), скомпиль в жабовский байткод, декомпиль(не в жабу, а в читабельный вид — асм байткода — http://www.varaneckas.com/jad), листинги в студию.
E__>А я напишу это же на жабе, и сделаю то же самое. И сравним на низком уровне, что вышло. Там сразу видно будет, байткод очень простой для понимания.

Не, лично я с ним ещё не работал. Пока просто интересуюсь.

Здравствуйте, D.Lans, Вы писали:


PD>>>>Я сейчас как раз имею дело с этими пакетами, код на Питоне писал не я. Я его аккуратно переписал на Яву (1:1) и явовский код работает примерно в 20-30 раз быстрее.

DL>>>А может стоило попробовать реализацию питона под джаву: Jython?

DL>>>Мне кстати самому интересно, как соотносятся про производительности Jython и Java.

E__>>А мне интересно, во что скомпилится этот Jython. Напиши какой-нибудь код под него(пусть будет простой — с математикой, хотя можно добавить пару фирменных фишек Питона), скомпиль в жабовский байткод, декомпиль(не в жабу, а в читабельный вид — асм байткода — http://www.varaneckas.com/jad), листинги в студию.
E__>>А я напишу это же на жабе, и сделаю то же самое. И сравним на низком уровне, что вышло. Там сразу видно будет, байткод очень простой для понимания.

DL>Не, лично я с ним ещё не работал. Пока просто интересуюсь.

А с Питоном? Я просто в нем ни бум-бум, и мой первый код врядли будет адекватен. Если есть просто код на Питоне, я сам займусь, мне же интересно. А на дворе пятница, спать я долго не планирую.

Здравствуйте, Eugeny__, Вы писали:

E__>Здравствуйте, D.Lans, Вы писали:


PD>>>>>Я сейчас как раз имею дело с этими пакетами, код на Питоне писал не я. Я его аккуратно переписал на Яву (1:1) и явовский код работает примерно в 20-30 раз быстрее.

DL>>>>А может стоило попробовать реализацию питона под джаву: Jython?

DL>>>>Мне кстати самому интересно, как соотносятся про производительности Jython и Java.

E__>>>А мне интересно, во что скомпилится этот Jython. Напиши какой-нибудь код под него(пусть будет простой — с математикой, хотя можно добавить пару фирменных фишек Питона), скомпиль в жабовский байткод, декомпиль(не в жабу, а в читабельный вид — асм байткода — http://www.varaneckas.com/jad), листинги в студию.
E__>>>А я напишу это же на жабе, и сделаю то же самое. И сравним на низком уровне, что вышло. Там сразу видно будет, байткод очень простой для понимания.

DL>>Не, лично я с ним ещё не работал. Пока просто интересуюсь.

E__>А с Питоном? Я просто в нем ни бум-бум, и мой первый код врядли будет адекватен. Если есть просто код на Питоне, я сам займусь, мне же интересно. А на дворе пятница, спать я долго не планирую.

Только начинаю изучать.

Здравствуйте, Pavel Dvorkin, Вы писали:


E__>>Хм. Насколько промежуточный жабовский язык поход на ассемблер х86? Практически никак. И тем не менее, в общем случае падение производительности не такое и большое.

PD>Смотря на чем. Для матричных операций я получил 2-3 раза.

Про числодробилки — да. Но и тем не менее не в 30 раз, как для Питона. И то, виртуалки совершенствуются. Несмотря на различную идеологию байткода и нативы. Кстати, ты использовал интерпритатор, или же версию с JIT? Это очень важно, ибо последняя может увеличить производительность после компиляции числодробилки в нативу в 2-15 раз.
А еще есть управление памятью. Которое очень сложный вопрос. В приложениях типа веба — шах и мат нативе. Тут много факторов. И быстрая работа ГЦ при сборе юного поколения объектов(а при обработке запроса все туда попадают), и быстрейшее выделение памяти в жабошарпах(передвинуть указатель это быстро), и раздельность потоков(непойманное исключение в жабошарпах ложит текущий поток обработки с записью в логи, в плюсах — весь сервер; в жабе еще и чекед исключения убирают трясун типа "а вдруг что-то пойдет не так" — всегда знаешь, что именно может пойти не так, а рантайм исключения — это крах в 99% случаев, там по-другому решать надо).

А реальные приложения вообще забавные. Мы тут замеры производили... Я офигел с самописного теста(пытался делать не особо однородный, получился такой говнокод, что самому страшно) — коре2дуо(2х2.2) проигрывает феному 1100(6х3.3) в однопоточке в 6 раз, выигрывает в многопоточке в 4 раза(как?), а новехонький топовый бульдозер от амд проигрывает в 8 раз феному по обоим тестам. И это тест за 20 минут написанный от фонаря. Реальные приложения еще труднее в оценке.

>>Плюс, JIT не стоит на месте, а очень даже развивается. А компилять код, зная контекст и аппаратное окружение, можно куда эффективнее, чем "для общего случая".


PD>Для обычного компилятора время не критично, и если проект компилируется минуты — переживем. JIT это себе позволить не может. Поэтому обычный компилятор может устроить какие угодно межмодульные оптимизации, в принципе его связка с линкером может перестраивать и оптимизировать код как угодно. JIT не может, по этой причине. Поэтому его развитие ограничено сложностью алгоритмов оптимизации — начиная с некоторой сложности, банально не хватит времени.

Зато обычный компилятор оптимизирует вслепую. А джит только то, что реально нужно, и у него точные данные про возможности именно этого проца. Причем обычным компиляторам уже очень много, а джит, по сути, на начальной стадии развития. Там еще непаханное поле, куда развиваться.

Здравствуйте, Ikemefula, Вы писали:

I>Нативный код дискредетировал себя проблемами со стабильностью и безопасностью. Единственное на чем он сейчас держится это низкоуровневый контроль ресурсов.

дискредитировал себя не нативный код, а С'стайл в C++

http://www.cplusplus.com/reference/clibrary/cstring/strcpy/

(смотрим на название сайта)

--------------------------------------------------------
cpp — мутант переходного периода, и должен умереть

#include 
#include 

void process(char *str)
{
  char buffer[256];

  strcpy(buffer, str);
  printf("Длина строки = %d\n", strlen(buffer));
  return;
}

void main(int argc, char *argv[])
{
  if (argc == 2)
    process(argv[1]);
  else
    printf("Usage: %s some_string\n", argv[0]);
}

Пока будет C++, будут бесконечные патчи и вот такие апдейты.

Здравствуйте, Eugeny__, Вы писали:

E__>А еще есть управление памятью. Которое очень сложный вопрос. В приложениях типа веба — шах и мат нативе.
Ох блин, опять эти сказки...

E__> Тут много факторов. И быстрая работа ГЦ при сборе юного поколения объектов(а при обработке запроса все туда попадают), и быстрейшее выделение памяти в жабошарпах(передвинуть указатель это быстро)
Ага, проходили мы это. Читай примерно тут: Re[20]: Внимание, Java!

Автор: CreatorCray
Дата: 20.07.10

Чтоб на жабе более менее быстро работало надо ещё чуть ли не ручками подбирать правильные параметры. Но простенький proof of concept аллокатор даёт ту же скорость что и оттюненая жаба. И это ещё не брались за оптимизацию.
Так что не надо нам рассказывать про чудеса, их не бывает.

E__>, и раздельность потоков(непойманное исключение в жабошарпах ложит текущий поток обработки с записью в логи, в плюсах — весь сервер; в жабе еще и чекед исключения убирают трясун типа "а вдруг что-то пойдет не так" — всегда знаешь, что именно может пойти не так, а рантайм исключения — это крах в 99% случаев, там по-другому решать надо).

E__>А реальные приложения вообще забавные. Мы тут замеры производили... Я офигел с самописного теста(пытался делать не особо однородный, получился такой говнокод, что самому страшно) — коре2дуо(2х2.2) проигрывает феному 1100(6х3.3) в однопоточке в 6 раз, выигрывает в многопоточке в 4 раза(как?)
Шота у вас там у теста в консерватории явно не в порядке.

E__>а новехонький топовый бульдозер от амд проигрывает в 8 раз феному по обоим тестам. И это тест за 20 минут написанный от фонаря. Реальные приложения еще труднее в оценке.
Это просто бульдозер весьма, гм, своеобразный получился.

PD>>Для обычного компилятора время не критично, и если проект компилируется минуты — переживем. JIT это себе позволить не может. Поэтому обычный компилятор может устроить какие угодно межмодульные оптимизации, в принципе его связка с линкером может перестраивать и оптимизировать код как угодно. JIT не может, по этой причине. Поэтому его развитие ограничено сложностью алгоритмов оптимизации — начиная с некоторой сложности, банально не хватит времени.

E__>Зато обычный компилятор оптимизирует вслепую.
Компиляторы уже давным давно умеют PGO, так что не в слепую.

E__> А джит только то, что реально нужно, и у него точные данные про возможности именно этого проца.
А толку, всё равно хуже чем у компилятора получается.

E__> Причем обычным компиляторам уже очень много, а джит, по сути, на начальной стадии развития.
У тех кто делал jit были все знания, накомпленные за время развития компиляторов. Так что возраст тут роли особой не играет.

Здравствуйте, D.Lans, Вы писали:

DL>А может стоило попробовать реализацию питона под джаву: Jython?

В моей задаче не стоило. Надо было просто перевести код на Яву. Python code в production не пойдет.

Здравствуйте, Eugeny__, Вы писали:

E__>Про числодробилки — да. Но и тем не менее не в 30 раз, как для Питона.

Конечно.

>И то, виртуалки совершенствуются. Несмотря на различную идеологию байткода и нативы. Кстати, ты использовал интерпритатор, или же версию с JIT?

Python — интерпретатор, плагин к эклипсу для Python 2.7. Для Явы — эклпипс.

E__>А еще есть управление памятью. Которое очень сложный вопрос. В приложениях типа веба — шах и мат нативе.

Вот тут согласен, но частично. Шах и мат не нативе, а нативе с указателями. Натива может вполне быть без указателей и со сборкой мусора, а тогда никакого шаха и мата не будет. Дело не в нативе vs. управляемый код, а в наличии или отсутствии сборки мусора.

>(непойманное исключение в жабошарпах ложит текущий поток обработки с записью в логи, в плюсах — весь сервер;

Ну это совсем не обязательно, можно на С++ ловить необработанные исключения.

E__>А реальные приложения вообще забавные. Мы тут замеры производили... Я офигел с самописного теста(пытался делать не особо однородный, получился такой говнокод, что самому страшно) — коре2дуо(2х2.2) проигрывает феному 1100(6х3.3) в однопоточке в 6 раз, выигрывает в многопоточке в 4 раза(как?),

Что-то сомнительно. Надо смотреть, что за тест.


PD>>Для обычного компилятора время не критично, и если проект компилируется минуты — переживем. JIT это себе позволить не может. Поэтому обычный компилятор может устроить какие угодно межмодульные оптимизации, в принципе его связка с линкером может перестраивать и оптимизировать код как угодно. JIT не может, по этой причине. Поэтому его развитие ограничено сложностью алгоритмов оптимизации — начиная с некоторой сложности, банально не хватит времени.

E__>Зато обычный компилятор оптимизирует вслепую. А джит только то, что реально нужно, и у него точные данные про возможности именно этого проца. Причем обычным компиляторам уже очень много, а джит, по сути, на начальной стадии развития. Там еще непаханное поле, куда развиваться.

Там все равно очень мало времени на вспашку поля. Что же касается возможностей процессора, то это в принципе можно и для нативы сделать — не так уж их много. Другое дело, что практически не делают — так я и не уверен, что JIT делает.

Здравствуйте, alexey_ma, Вы писали:

TSP>>А откуда такая любовь к нативному коду? Очень много программ, которые проще было бы реализовать меньшими силами на той же/*том же?*/ Java.
_>Да. Но есть задачи где без нейтива никак не обойтись. Отсюда и любовь, на нейтиве можно написать вообще все что угодно, конечно, возможно что с большими трудозатратами.

Вот представь, что ты хочешь написать что-то для ARMа, а твой SuperNativeCSharp умеет генерировать код только для x86, причём у него даже есть некие проблемы с 64 разрядными приложениями. Те, кто развивают этот язык говорят, что лет через 7 может добавят поддержку ещё какой-нибудь платформы.

Здравствуйте, monax, Вы писали:

M>Новые языки программирования растут как грибы после дождя. Старые набирают комьюнити. На вскидку популярные языки, которые на слуху: C, C++, C#, Java, VisualBasic, PHP, Python, Perl, JavaScript, lisp, scala, Deplhi, erlang, D, Dart, ObjectiveC, ActionScript, Lua, Ruby — какие-то из них мало используются (D), но всё равно на слуху. Так вот, большинство из этих языков интерпретируемые или компилятся в свой байт-код, нативный код из коробки дают C, C++, ObjC, Delphi, D и всё. Почему так мало языков, которые компилятся в нативный код?

А нафига новые языки с компиляцией в нативный код? Всё чаще нужна именно скорость разработаки и удобство сопровождения, а не скорость расчётов. Вот у меня в коллекции есть хорошая ссылочка:
http://www.stockme.ru/rus/blogs/document3110.phtml

Здравствуйте, azzx, Вы писали:

A>А нафига новые языки с компиляцией в нативный код? Всё чаще нужна именно скорость разработаки и удобство сопровождения, а не скорость расчётов. Вот у меня в коллекции есть хорошая ссылочка:
A>http://www.stockme.ru/rus/blogs/document3110.phtml

Внутренняя задержка 500 микросекунд

Что-то очень на враньё похоже, щедулер при 1000Hz даст время переключения 1 мл.сек. + нужно ещё посчитать квант процесса + нужно добавить погрешность переключения (в среднем от 0.5 до 1 тика) т.е. до 1 мл.сек. + время задержки в TCP/IP стеке (алгоритм Нагла может задержать пакеты, установка соединения и т.п.). Итого, не может быть внутренняя задержка меньше 2 мл.сек.

Здравствуйте, Философ, Вы писали:

Ф>дискредитировал себя не нативный код, а С'стайл в C++

И потому глючат даже сишные проги и проги на дельфях всяких ?

Здравствуйте, SilentNoise, Вы писали:

SN>Здравствуйте, jazzer, Вы писали:

J>>А нативщикам остается писать начинку, которой будет рулить какой-нть скрипт, и этот скрипт предоставит удобный и прозрачный DSL для решаемой задачи.
J>>И это хорошо.
J>>И пусть таких языков будет больше — людям жить будет легче, и программить смогут даже админы (перл, питон), которым для их поделок нафиг не нужны вяские петтерны и прочие радости "настоящего" программирования.
SN>Легкость разработки и компиляция/интерпретация это вообще ортогональные понятия.

Оно, конечно, да, только вот о компиляции/интерпретации тут никто не говорит, речь идет о нативности.
А нативность означает, что язык должен иметь дело с потрохами платформы, иначе это не нативность никакая, а просто компилируемость в машкоды.
А это никогда легким не назовешь, если только платформа не заточена под это специально (см. послание Лаптева о виртуальных машинах рядом).

You will always get what you always got
  If you always do  what you always did

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, Философ, Вы писали:

Ф>>дискредитировал себя не нативный код, а С'стайл в C++

I>И потому глючат даже сишные проги и проги на дельфях всяких ?

И потому же глючат шарповые проги и проги на VBNet'ах всяких