The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Первый выпуск Topaz, высокопроизводительной реализации Ruby,..., opennews (ok), 07-Фев-13, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


9. "Первый выпуск Topaz, высокопроизводительной реализации Ruby,..."  +/
Сообщение от Lain_13email (ok), 07-Фев-13, 02:20 
Тесты показывают, что на JS возможна производительность близкая к C (V8 в основном в 2 раза медленнее, но иногда выдаёт код даже более быстрый, чем на C). Ещё учти, что PyPy (компилятор питона на питоне) в основном в 10 раз более быстрый код генерирует, чем CPython (компилятор питона на си).
Так что PHP на JS может внезапно оказаться быстрее того, что есть сейчас. Такие дела. Другое дело, что скорость PHP особой роли обычно не играет кроме очень динамичных сайтов. В остальных случаях достаточно хорошего кэширования.
Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

12. "Первый выпуск Topaz, высокопроизводительной реализации Ruby,..."  +2 +/
Сообщение от Аноним (-), 07-Фев-13, 03:42 
> Тесты показывают, что на JS возможна производительность близкая к C (V8 в основном в 2 раза медленнее, но иногда выдаёт код даже более быстрый, чем на C).

Синтетические - может быть. В реальной жизни он медленнее на порядки и всегда будет.

Ответить | Правка | Наверх | Cообщить модератору

17. "Первый выпуск Topaz, высокопроизводительной реализации Ruby,..."  +4 +/
Сообщение от Lain_13email (ok), 07-Фев-13, 06:35 
На порядки медленнее Питон. PyPy на порядок, CPython на все два порядка. Всё зависит от прямоты рук — плохой и крайне медленный код можно написать на любом языке и это не вина языка если программа сортирует пару миллионов строк методом пузырька. Вот памяти он всегда будет жрать в несколько раз больше C, но память сейчас обычно не проблема даже на относительно дешёвых планшетах.
Ответить | Правка | Наверх | Cообщить модератору

75. "Первый выпуск Topaz, высокопроизводительной реализации Ruby,..."  –1 +/
Сообщение от Аноним (-), 07-Фев-13, 22:49 
> можно написать на любом языке

...но на JS написать медленный код - как делать нефиг, а вот быстрый - надо долго изгаляться. Потому что динамическая типизация подразумевает массу лишних проверок "а не изменился ли у нас тип". Что распостраняется даже на самые простые операции.

Ответить | Правка | Наверх | Cообщить модератору

85. "Первый выпуск Topaz, высокопроизводительной реализации Ruby,..."  +1 +/
Сообщение от Lain_13email (ok), 08-Фев-13, 03:10 
>Потому что динамическая типизация подразумевает массу лишних проверок

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

Ответить | Правка | Наверх | Cообщить модератору

13. "Первый выпуск Topaz, высокопроизводительной реализации Ruby,..."  +/
Сообщение от AnonuS (?), 07-Фев-13, 03:57 
> Ещё учти, что PyPy (компилятор питона на питоне) в основном в 10 раз более быстрый код генерирует, чем CPython (компилятор питона на си).

И что ты этим хотел сказать? Хотел нам пояснить принципиальную невозможность генерации быстрого "змеиного" кода компилятором написанным на "С"?

Ответить | Правка | К родителю #9 | Наверх | Cообщить модератору

18. "Первый выпуск Topaz, высокопроизводительной реализации Ruby,..."  +2 +/
Сообщение от Lain_13email (ok), 07-Фев-13, 06:38 
> И что ты этим хотел сказать? Хотел нам пояснить принципиальную невозможность генерации
> быстрого "змеиного" кода компилятором написанным на "С"?

То, что компилятор написанный на высокоуровневом языке может позволить выполнять оптимизации, которые на чистом С реализовать на несколько порядков сложнее. PyPy это крайне наглядно доказал.

Ответить | Правка | Наверх | Cообщить модератору

20. "Первый выпуск Topaz, высокопроизводительной реализации Ruby,..."  –1 +/
Сообщение от Аноним (-), 07-Фев-13, 07:12 
> PyPy это крайне наглядно доказал.

А что, сам pypy при выполнении питонятины уже обгоняет си? Или уже не является кастрированной реализацией питона, с запретом использовать ряд функционала?

Ответить | Правка | Наверх | Cообщить модератору

26. "Первый выпуск Topaz, высокопроизводительной реализации Ruby,..."  –1 +/
Сообщение от Lain_13email (ok), 07-Фев-13, 08:18 
> А что, сам pypy при выполнении питонятины уже обгоняет си?

Вероятно ты не понял, но PyPy компилирует код в бинарный и ничего не исполняет. Собственно и CPython делает то же самое. Если нужный код вынести в модули, то при первом исполненни будут даже созданы бинарные файлы на диске, которые будут использованы при следующем запуске вместо пересборки питонятины ещё раз.

Код собранный из питонятины работает медленнее Си. Собранный PyPy — на порядок, собранный CPython на два порядка. Собственно тут поднимался вопрос о реализации компилятора PHP на JS и я указал именно на то, что написать компилятор на высокоуровневом языке может оказаться более выгодным, чем писать его на низкоуровневом с точки зрения скорости выполнения собранного кода после его оптимизации компилятором. Сам компилятор при этом наверняка будет работать медленнее даже при ограничении на использование одинакового набора оптимизаций, но это ведь и не важно — в случае компиляции нам ведь важно как быстро мы побежим, а не как долго мы к этому будем готовиться.

Другое дело, что на высокоуровневом языке наверняка будет невыгодно писать интерпретатор или JIT-компилятор с точки зрения времени затрачиваемого на интерпретацию и JIT-компиляцию, так-как это время уже реально будет влиять на скорость работы приложения. В случае PHP использование компилятора действительно проблематично и приведёт к невозможности реализации некоторых его возможностей. Вообще чего уже только ни придумали для ускорения пыха. И конвертер в C++, и компилятор в байткод .NET…

> Или уже не является кастрированной реализацией питона, с запретом использовать ряд функционала?

Не являлся. Там есть некоторые различия в риализаци некоторых вещей, но в основном они связаны со сборщиком мусора, некоторыми стратегиями оптимизации исполнимого кода и изначально недокументированным поведением. Всего таких различий мало и их довольно легко избежать. Может не хватать некоторых модулей, но лишь потому, что их нужно переписать на самом же питоне и это ещё не сделано, а не потому, что это невозможно.

Подробности по ссылке, ничего ужасного принципиально неразрешимого там нет: http://pypy.readthedocs.org/en/latest/cpython_differences.html

Ответить | Правка | Наверх | Cообщить модератору

33. "Первый выпуск Topaz, высокопроизводительной реализации Ruby,..."  +1 +/
Сообщение от Аноним (-), 07-Фев-13, 09:49 
> Вероятно ты не понял, но PyPy компилирует код в бинарный и ничего не исполняет. Собственно и CPython делает то же самое.

Путаете CPython и Cython. В машинный код компилируется последний. Первый — это образцовая реализация питона. Он является интерпретатором и компилируется в байткод.

Ответить | Правка | Наверх | Cообщить модератору

44. "Первый выпуск Topaz, высокопроизводительной реализации Ruby,..."  +/
Сообщение от Lain_13email (ok), 07-Фев-13, 10:32 
> Путаете CPython и Cython. В машинный код компилируется последний. Первый — это
> образцовая реализация питона. Он является интерпретатором и компилируется в байткод.

Ты прав, путаю, но всё же CPython это интерпретатор и компилятор — он ведь компилирует то, что разобрал, в байткод, а не выполняет команды последовательно, так ведь? PyPy же вообще собирает и оптимизирует байткод по-мере надобности используя JIT-компилятор.

Ответить | Правка | Наверх | Cообщить модератору

47. "Первый выпуск Topaz, высокопроизводительной реализации Ruby,..."  +3 +/
Сообщение от pavel_simple (ok), 07-Фев-13, 10:42 
>> Путаете CPython и Cython. В машинный код компилируется последний. Первый — это
>> образцовая реализация питона. Он является интерпретатором и компилируется в байткод.
> Ты прав, путаю, но всё же CPython это интерпретатор и компилятор —
> он ведь компилирует то, что разобрал, в байткод, а не выполняет
> команды последовательно, так ведь? PyPy же вообще собирает и оптимизирует байткод
> по-мере надобности использую JIT-компилятор.

... кони, люди...

Ответить | Правка | Наверх | Cообщить модератору

48. "Первый выпуск Topaz, высокопроизводительной реализации Ruby,..."  +2 +/
Сообщение от Lain_13email (ok), 07-Фев-13, 10:48 
Ну ладно, ладно, CPython это интерпретатор байт-кода. Легче стало?
Ответить | Правка | Наверх | Cообщить модератору

65. "Первый выпуск Topaz, высокопроизводительной реализации Ruby,..."  +/
Сообщение от GentooBoy (ok), 07-Фев-13, 19:52 
ага отлегло прям
Ответить | Правка | Наверх | Cообщить модератору

76. "Первый выпуск Topaz, высокопроизводительной реализации Ruby,..."  –1 +/
Сообщение от Аноним (-), 07-Фев-13, 22:56 
> Вероятно ты не понял, но PyPy компилирует код в бинарный и ничего не исполняет.

IIRC он умеет только урезанный субсет питона с уймой ограничений.

> Собственно и CPython делает то же самое.

Ага, понятно, FAIL засчитан. Cpython может компилировать в некий промежуточный байткод. Но эпикфэйл состоит в том что далее этот байткод ... ИНТЕРПРЕТИРУЕТСЯ.

Но да, спасибо, я заметил - питонисты настолько тупые, что вообще не способны понять что нет никакой разницы, будут ли интерпретироваться слова или какие-то байткоды. Спасибо что подтвердили мой тезис.

> код вынести в модули, то при первом исполненни будут даже созданы
> бинарные файлы на диске, которые будут использованы при следующем запуске вместо
> пересборки питонятины ещё раз.

Вот только в модулях опять же некий абстрактный байткод, который CPU напрямую выполнять не может. И поэтому питон его интерпретирует. Трабла в том что полезная логика программы оказывается густо разбавлена логикой интерпретера. По поводу чего интерпритаторы тормознее компиляторов, которые перегоняют все в нативный машинный код 1 раз, а потом в коде остается только логика программы. Так что разбавление кода интерпретаторским - пропадает. Интерпретеры тормознее компилеров by design. В счет чего cpython (который интерпретер) - без шансов vs компилеров или хотя-бы умеющих JIT. Pypy в этом плане лучше, но он IIRC умеет только урезаный субсет питона и совсем не факт что обгонит си на одном и том же алгоритме, так что громкие тезисы о супер-оптимизации как-то не выглядят доказанными.

Ответить | Правка | К родителю #26 | Наверх | Cообщить модератору

54. "Первый выпуск Topaz, высокопроизводительной реализации Ruby,..."  +/
Сообщение от Тутутиту (?), 07-Фев-13, 12:53 
>> PyPy это крайне наглядно доказал.
> А что, сам pypy при выполнении питонятины уже обгоняет си? Или уже
> не является кастрированной реализацией питона, с запретом использовать ряд функционала?

Да вроде как да

Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру