Здравствуйте, FR, Вы писали:
AVK>>В этом направлении никто особо пока не работал всерьез. Есть шанс, что кое что будет в CLR 5, но это пока только планы.
FR>Ну явщики только этим и занимались.
Оптимизацией JVM для числодробилок? Можно ссылочку на масштабные проекты? А то там вроде бы даже поддержки векторных расширений процессоров в пользовательских высислениях до сих пор нет, я уж не говорю о таких изысках как generic арифметика.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>
Здравствуйте, WolfHound, Вы писали:
WH>А если вспомнить про рефакторинг... я вообще не представляю как рефакторить без статической типизации. WH>Автоматический рефакторинг для динамики сделать нельзя. Вообще никак. В лучшем случае получится что-то типа текстовой замены когда одно имя заменяется сразу во всей программе.
Угу при этом слово рефакторинг придумали Smalltalk разработчики.
Кстати рефакторинг в питоне все-таки появился, года три назад он практически отсутствовал, я недавно смотрел питоные IDE
хоть он и не идеален, но по моему уже лучше чем в C++. Кроме IDE вот эта http://rope.sourceforge.net/ библиотека тоже весьма неплоха.
Re[15]: почему в вебе распространены именно динамические язы
Здравствуйте, netch80, Вы писали:
VD>>То есть будучи транслированным на Яву код стал работать более чем в два раза быстрее нежели С/С++ версия.
N>А дальше что? Нашли причину или так и остались в непонятках?
Дык это не я же эту статью писал. Откуда я занаю. Но факт остается фактом даже не стремясь можно получить более быструю реализацию на яве нежели на С++.
С++ хорош не тем что он просто позволяет генерировать быстрый машинный код, а тем, что он позовляет делать низкоуровневые оптимизации.
ЗЫ
Данную ссыклу привели видимо в доказательство того, что скрипты могут работать быстрее компилируемых языков. Но это как всегда плохо прекрытая лож. Если внимательно почитать статью, то выясняется, что код как бы вовсе не на скрипте, а не его самбэте в котором нет ни малейшего намека на динамику и который можно эффективно компилировать в нэйтив код (или транслировать в С). Другими словами в статье говорится вовсе не о скрипте, а о вполне себе статическом языке.
Далее выясняется еще более интересные факты. Оказывается, что это даже не JIT-компиляция RPython, а какое-то в доску рукопашно оптимизированное решение для конкретных целей.
Далее становится еще интереснее, так как сравнивают они его с универсальными библиотеками регулярных выражений которые сильно отличаются от сравниваемого решения. Так сравниваемое решение делате только сопоставление, в то время как универсальные библиотеки позволяет разбирать сопоставляемые фрагменты. Как человек вдоволь назанимавшися парсерами могу четко сказать, что разбор сматченых фрагментов занимает очень много времени. Кроме того универсальные библиотеки поддреживают расширения вроде обратных ссылок, что делает их алгоритм отличным от сравнивамого. В доврешение всего универсальные библоитеки являются интрпретаторами регулярных выражений, а не компилируют их. Собственно авторы открытр говорят об всем этом.
Так что как не крути это еще одна попытка выдать сказки за чудесную действительность.
Я уже устал повторять. Чудес не бывает. Скрипты дико медленны и могу использоваться только как клей для компонентов созданных на более быстрых средствах разрабоки. Компиляция скриптов конечно может несколько их ускорить, но в общем случае это ускорение не будет очень значительным в следствии динамической природы самих язков.
Так что пора прекратить рассказывать сказки о шустрости скриптов.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[16]: почему в вебе распространены именно динамические язы
Здравствуйте, AndrewVK, Вы писали:
AVK>Оптимизацией JVM для числодробилок? Можно ссылочку на масштабные проекты? А то там вроде бы даже поддержки векторных расширений процессоров в пользовательских высислениях до сих пор нет, я уж не говорю о таких изысках как generic арифметика.
Почему вычисления они вроде прилично подтянули GC и оптимизацию использования стека, это гораздо больше просаживает чем кодогенератор.
Re[19]: почему в вебе распространены именно динамические язы
Здравствуйте, Mamut, Вы писали:
M>В начале двухтысячных Ericsson опросил своих клиентов, стоит ли вводить в Erlang статическую типизацию. Клиенты дружно послали их туда, где солнце не светит. Вот такая вот ошибка природы, ага.
Демагогия. Аппеляция к общественному мнению.
По существу есть что сказать?
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[21]: почему в вебе распространены именно динамические язы
Здравствуйте, netch80, Вы писали:
N>Моя практика показывает, что тестов достаточно. Разумеется, если они грамотно построены (вот это уже совершенно неформализуемый признак).
А я обхожусь исключительно функциональными тестами. Как показывает практика при наличии статической типизации другие не нужны.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[17]: почему в вебе распространены именно динамические язы
Ну этот тред вроде бы о применении динамики в числодробилках.
FR> они вроде прилично подтянули GC и оптимизацию использования стека, это гораздо больше просаживает чем кодогенератор.
Смотря что.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>
Здравствуйте, kochetkov.vladimir, Вы писали:
C>>Для этого надо всего-навсего выставить простую и интуитивно понятную переменную окружения: PYTHONDONTWRITEBYTECODE (в самом Питоне доступна как sys.dont_write_bytecode) KV>Нет. Он умеет не кэшировать байт-код в pyc-файлы, но создает его всегда, т.к. среда исполнения умеет выполнять только его.
Это уже детали реализации.
Sapienti sat!
Re[17]: почему в вебе распространены именно динамические язы
Здравствуйте, AndrewVK, Вы писали:
FR>>Так питон почти однозначно транслируется в RPython.
AVK>Не знаю что там куда транслируется, но сабсет RPython статически типизирован и как то странно приводить его в защиту динамических языков.
Цель проекта PyPy исполнять питон код без изменений но существенно быстрей чем интерпретатором, трансляция в RPython средство этого добиться.
На RPython код писать не будут в идеале, реально ничего плохого от переписывания некоторых кусков в RPython для оптимизации не будет. Притом
RPython вариант по сути тот же код с аннотациями.
Re[13]: почему в вебе распространены именно динамические язы
Здравствуйте, Mamut, Вы писали:
VD>>Ничего они не добились. Тут не раз приводили числодробильные тесты на которых они сливали по полной программе.
M>А никто и не собирается их исопльзовать для числодробления
Ты сильно заблуждаешся. Тут куча маньяков которые с пеной у рта будут доказывать обратное.
M>Как бы есть еще толпа задач, кроме числодробления. И никто не мешает подключить библиотеку на С, если числодробилка вдруг понадобится.
Подключать библиотеки мешает их отсутствие. Собственно если задача решается с помощью библиотеки, то ее и на С решить будет не сложно. А вот если библиотеки нет, то ее надо сначала написать. А писать на С — это вам не на Питоне или Эрланге ваять. Это труд в разы более тяжелый и не благодарный.
Меж тем есть языки писать на которых почти так же просто как на скриптах, и при этом получаемый код по быстродействию может быть таким же быстрым как если бы он был написан на С.
И тут мы приходим к теме данного обсуждения и понимаем, что ложна сама посылка. Распространены как скрипты, так и типобезопасные компилируемые языки. Вот С/С++ в данном сегменте действительно не распространен, так как с одной стороны писать на нем тяжело, а с другой добиться надежной работы программы существенно сложнее.
M>А на каких-гибудь нечислодробилках тот же Erlang спокойно работает на уровне того же С
Конек Эрланга кооперативная многозадачность. Если нужна именно она, то конечно Эрланг может оказаться очень даже подходящим продуктам. Но мы все же говорим не об этом.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[18]: почему в вебе распространены именно динамические язы
Здравствуйте, FR, Вы писали:
FR>Цель проекта PyPy исполнять питон код без изменений но существенно быстрей чем интерпретатором, трансляция в RPython средство этого добиться.
Отлично. Но речь то не о питоне, а о динамике. И то, что пипи компилирует реально, это никакая не динамика, а самая натуральная статика, пусть и с выводом типов кое где. Поэтому пипи как аргумент работает именно в защиту статически типизированных языков.
FR>На RPython код писать не будут в идеале, реально ничего плохого от переписывания некоторых кусков в RPython для оптимизации не будет.
Не будет. Но надо отдавать себе отчет, что это гибридное решение. Вон, С#4 весь компилируется, но это не мешает в нем писать динамический код. С соответствующими потерями перформанса, разумеется.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476 on Windows 7 6.1.7600.0>>
Здравствуйте, FR, Вы писали:
FR>Угу при этом слово рефакторинг придумали Smalltalk разработчики.
Только их "рефакторинг" тупо переименовывал все вхождения имени в программе.
Сравни с решарпером который может переименовать один из перегруженных методов.
FR>Кстати рефакторинг в питоне все-таки появился, года три назад он практически отсутствовал, я недавно смотрел питоные IDE
Могут ли они надежно переименовать метод класса при условии что есть другой класс с таким же методом?
Или они одно имя меняют на другое по всей программе?
FR>хоть он и не идеален, но по моему уже лучше чем в C++.
Нашол блин с чем сравнивать.
Сравни с явой или шарпом.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[19]: почему в вебе распространены именно динамические язы
Здравствуйте, AndrewVK, Вы писали:
AVK>Отлично. Но речь то не о питоне, а о динамике. И то, что пипи компилирует реально, это никакая не динамика, а самая натуральная статика, пусть и с выводом типов кое где. Поэтому пипи как аргумент работает именно в защиту статически типизированных языков.
Конечно внутри будет статика, только это как раз в пользу именно динамике, так как позволяет существенно ее ускорить, а что-там внутри неважно.
AVK>Не будет. Но надо отдавать себе отчет, что это гибридное решение. Вон, С#4 весь компилируется, но это не мешает в нем писать динамический код. С соответствующими потерями перформанса, разумеется.
Возможно в будущем и будут рулить гибриды.
Re[20]: почему в вебе распространены именно динамические язы
RPython[70] — созданная в рамках проекта PyPy сильно ограниченная реализация Python без динамизма времени исполнения и некоторых других возможностей. RPython код можно компилировать во множество других языков/платформ — C, JavaScript, Lisp,
Так что никакими скриптами тут и не пахнет. Мы имеем дело с языком который мало чем отличается от С. Разве что ли более ограниченный, так как с указателями не позволяет работать.
Потом там идет какая-то трехэтажная химия с джитом. Так что назвать это JIT-компиляцией скрипта никак нельзя. Там имеет место JIT-компиляция языка регулярных выражений. А скорость работы самого Питона там берется за пяденицу. И она на порядки медленнее чем любая другая реализация.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[15]: почему в вебе распространены именно динамические язы
Здравствуйте, FR, Вы писали:
FR>Ну были голоса что будет только одно телевидение NET вокруг, а натив только в песочнице для легаси.
Ну, найди ссылку, тогда обсудим. А пока оставим эти инсинуации.
FR>>>Это не миф, у лиспа например большинство реализаций компиляторы.
VD>>Это миф и я сам его проверил.
FR>Понятно компиляторы лиспа и схемы мне приснились.
Ты опять перевираешь чужие слова. Миф — это скорость получаемого кода. Я видел этот код (машинный). Он далек о того что может сделать даже дотнет с Явой. О сравнении его с хорошими оптимизирующими компиляторами С даже речи идти не может.
К тому же пересометрия в этой области обычно проводится на примитивных примерах где в основном присутствует простенькая целочисленная арифметика. А вот когда дело доходит до компиляции реальных лисповских приложений, то как и в случае со Смотоком, все становится куда печальнее. Динамика есть динамика. Она всегда накладывает свой след. Получать быстрый код в общем случае не представляется возможным. Можно говорить только о его ускорении по сравнению с интерпретацией.
Так что кончай повторять эту ересь в сотый раз. Право, надоело.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
