| 1.1, Tav (ok), 01:17, 28/11/2010 [ответить] [﹢﹢﹢] [ · · · ]
| –7 +/– |
 График — какая-то дурацкая расческа из единичных столбиков. Если уж изображать относительную производительность, то как-то так: http://speed.pypy.org/comparison/?exe=2%2B35,1%2B172&ben=1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20&env=1&hor=true&bas=2%2B35&chart=relative+bars
| | |
| |
| 2.3, Аноним (-), 02:00, 28/11/2010 [^] [^^] [^^^] [ответить]
| –3 +/– |
Не просто расческа, там даже на 1.0 тика и линии нет. Не верю, что люди, которые не могут нормально график нарисовать, могут написать эффективную реализацию питона.
| | |
| |
| 3.4, Aquarius (ok), 02:20, 28/11/2010 [^] [^^] [^^^] [ответить]
| +2 +/– |
 > Не просто расческа, там даже на 1.0 тика и линии нет. Не
> верю, что люди, которые не могут нормально график нарисовать, могут написать
> эффективную реализацию питона.
это не график, а именно диаграмма (прочитайте подписи) и не может быть графиком - столбцы не имеют естественного порядка кроме алфавитного по подписям
| | |
| |
| 4.5, Аноним (-), 02:35, 28/11/2010 [^] [^^] [^^^] [ответить]
| –16 +/– |
Нет никакогй разницы как это называется, важно что это сделано абсолютно безграмотно.
| | |
|
|
|
| 1.2, dq0s4y71 (??), 01:44, 28/11/2010 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– | |
> Отдельно на базе PyPy ведется разработка реализаций на языке Python интерпретаторов Prolog, Smalltalk, JavaScript, Io и Scheme.
http://codespeak.net/svn/pypy/lang/prolog/trunk/prolog/doc.txt
"Its speed is still quite a bit below that of highly optimized Prologs,
roughly 10-100 times slower than 'Sicstus Prolog'_."
М-да... Можно гланды удалять через задний проход, а можно и компиляторы писать на Питоне :)
| | |
| |
| 2.19, ы (?), 18:39, 28/11/2010 [^] [^^] [^^^] [ответить]
| +2 +/– |
А еще можно компиляторы от интерпретаторов не отличать и из тестовых опытов по возможности интерпретирования стороних языков на pypy делать далеко идущие выводы.
| | |
| |
| 3.23, dq0s4y71 (??), 20:31, 28/11/2010 [^] [^^] [^^^] [ответить]
| +/– | |
> А еще можно компиляторы от интерпретаторов не отличать
Можно и не отличать. Только в данном случае речь идет именно о (JIT) компиляторе.
> и из тестовых опытов
> по возможности интерпретирования стороних языков на pypy делать далеко идущие выводы.
А компиляторы не "сторонних" языков на Питоне обычно получаются лучше? :)
| | |
| |
| 4.29, ы (?), 00:24, 29/11/2010 [^] [^^] [^^^] [ответить]
| +/– |
>> А еще можно компиляторы от интерпретаторов не отличать
> Можно и не отличать. Только в данном случае речь идет именно о
> (JIT) компиляторе.
Речь шла об интерпретации стороннего синтаксиса, в синтаксис python, ни одного слова про JIT там нет. Уже сама постановка такой задачи подразумевает возможность почти неограниченной оптимизации, и первичный тестовый код вообще не может рассматриваться как нечто неизменное, тем более результаты тестирования быстродействия.
Хотя сам pypy конечно использует JIT и он полноценный в отличии от урезанного в CPython, также добавлю что первоначальная реализация pypy также в разы проигрывала по скорости CPython, сейчас как видно на графике, большинство тестов на pypy выполняется в разы быстрее и это конечно не предел.
>> и из тестовых опытов
>> по возможности интерпретирования стороних языков на pypy делать далеко идущие выводы.
> А компиляторы не "сторонних" языков на Питоне обычно получаются лучше? :)
А они существуют? Хотя конечно в python можно вставлять инструкции и на С и на Assembler, что позволяет создать компилятор на python, но создание исполняемых бинарников не входит в область применения этого языка и задачи им решаемые.
| | |
| |
| 5.53, dq0s4y71 (??), 15:44, 30/11/2010 [^] [^^] [^^^] [ответить]
| +/– |
> Речь шла об интерпретации стороннего синтаксиса, в синтаксис python, ни одного слова
> про JIT там нет.
Читайте внимательнее текст новости: "Благодаря задействованию JIT-компилятора, на лету транслирующего некоторые элементы в машинный код, минуя фазу интерпретации байткода в виртуальной машине, PyPy при выполнении некоторых операций в несколько раз обгоняет по производительности классическую реализацию Python на языке Си."
>>> и из тестовых опытов
>>> по возможности интерпретирования стороних языков на pypy делать далеко идущие выводы.
>> А компиляторы не "сторонних" языков на Питоне обычно получаются лучше? :)
> А они существуют?
Ну, раз вы говорите, что интерпретировать "сторонние" языки PyPy не может, то, наверное, какие-то НЕ "сторонние" может? :)
> Хотя конечно в python можно вставлять инструкции и на
> С и на Assembler, что позволяет создать компилятор на python, но
> создание исполняемых бинарников не входит в область применения этого языка и
> задачи им решаемые.
Чтобы создать компилятор, вовсе необязательно иметь возможность вставлять инструкции на
С и на Assembler.
Питон - язык общего назначения, то есть на нем в принципе можно писать все что угодно, включая компиляторы. Но на практике мы видим, что компиляторы на Питоне получаются, мягко говоря, не очень хорошие. Так что единственное его достоинство - это то, что на нем можно писать быстро. :)
| | |
| |
| 6.55, ы (?), 17:09, 30/11/2010 [^] [^^] [^^^] [ответить]
| +/– | |
>Читайте внимательнее текст новости: "Благодаря задействованию JIT-компилятора, на лету транслирующего некоторые элементы в машинный код, минуя фазу интерпретации байткода в виртуальной машине, PyPy при выполнении некоторых операций в несколько раз обгоняет по производительности классическую реализацию Python на языке Си."
Да из микса двух независимых новостей, в одной из которых говориться об реализации JIT для pypy, а в другой о интерпретации стороних языков, можно сделать далеко идующие неверные выводы.
>Ну, раз вы говорите, что интерпретировать "сторонние" языки PyPy не может,
Привет, приплыли, я такого не говорил. Читать читать и еще раз читать вникая в каждое слово.
>Чтобы создать компилятор, вовсе необязательно иметь возможность вставлять инструкции на
С и на Assembler.
Можно, но не удобно.
>Питон - язык общего назначения, то есть на нем в принципе можно писать все что угодно, включая компиляторы.
Можно, но не удобно.
>Но на практике мы видим, что компиляторы на Питоне получаются, мягко говоря, не очень хорошие.
Ни одной реализации не существует. С чего вы сделали вывод?
| | |
|
|
|
|
|
| 1.6, тоже Аноним (ok), 10:08, 28/11/2010 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
 Что-то мне подсказывает, что если взять Сишную реализацию питона и оптимизировать ее с установкой "можно жрать больше памяти", то прирост будет не только в "некоторых операциях". Да и лишних тормозов в остальных операциях не возникнет.
| | |
| |
| |
| 3.11, тоже Аноним (ok), 11:29, 28/11/2010 [^] [^^] [^^^] [ответить]
| +/– |
Обратная зависимость между экономией памяти и скоростью в алгоритмах - это самые азы той матчасти. Хотите возразить - приводите аргументы, а не тролль-мемы.
| | |
| |
| 4.20, ы (?), 18:42, 28/11/2010 [^] [^^] [^^^] [ответить]
| +/– |
> Обратная зависимость между экономией памяти и скоростью в алгоритмах - это самые
> азы той матчасти. Хотите возразить - приводите аргументы, а не тролль-мемы.
Вы что нибудь про Just-in-time compilation слышали?
| | |
| |
| 5.22, тоже Аноним (ok), 20:16, 28/11/2010 [^] [^^] [^^^] [ответить]
| –1 +/– |
Кто ж не слышал. JIT - это костыли, позволяющие интерпретируемым языкам не слишком отставать по скорости от компилируемых. Чтобы обгоняли - что-то не слышал...
| | |
| |
| 6.26, ы (?), 23:56, 28/11/2010 [^] [^^] [^^^] [ответить]
| +/– |
Отлично, теперь вы можете понять почему интерпретатор на python будет обгонять сишную реализацию, не считая конечно реализацию unladen-swallow.
| | |
| |
| 7.33, тоже Аноним (ok), 08:52, 29/11/2010 [^] [^^] [^^^] [ответить]
| –1 +/– |
Думаю, тут требуются некоторые подробности. Для начала - данные, где реально показывался бы обгон. "Некоторые операции" рассматривать смысла нет, пока в целом реализация заметно тормознее и прожорливее. Я верю, что есть операции, где язык более высокого уровня позволяет меньше "гонять порожняк", чем универсальная реализация на С. Но это просто оптимизация нескольких узких мест, немного смягчающая общее падение производительности.
| | |
| |
| |
| |
| 10.50, ы (?), 14:13, 30/11/2010 [^] [^^] [^^^] [ответить] | +/– | Я таки думаю нужно вам кофейку попить, чтобы правильно понимать графическую инфо... текст свёрнут, показать | | |
| |
| |
| 12.54, ы (?), 16:44, 30/11/2010 [^] [^^] [^^^] [ответить] | +/– | Извиняйте, и еще раз график вверху, синеньким это CPython Прошу прощения, но да... текст свёрнут, показать | | |
| 12.56, userd (ok), 19:08, 30/11/2010 [^] [^^] [^^^] [ответить] | +/– |  Может быть можно Может быть нельзя Пальцем ткните - какие основные алгоритмы в... текст свёрнут, показать | | |
| |
| |
| 14.59, ы (?), 21:44, 30/11/2010 [^] [^^] [^^^] [ответить] | +/– | Ага, цельный гугл над этим работает и ничего сделать не может Блин Сил уже н... текст свёрнут, показать | | |
|
|
|
|
|
|
|
|
| 6.39, Аноним123321 (ok), 14:46, 29/11/2010 [^] [^^] [^^^] [ответить]
| +/– |
 > JIT - это костыли, позволяющие интерпретируемым языкам не слишком отставать по скорости от компилируемых ...
хотите сказать что преобразование инструкций в машинный код (во время обработки интерпретируемой программы) -- это костыли?
...ну тогда с таким же успехом можно сказать что и "Архитектура фон Неймана" вычислительных машин -- это тоже костыли (в отличии от "Гарвардской архитектуры" вычислительных машин)
:-)
| | |
| |
| 7.40, тоже Аноним (ok), 16:42, 29/11/2010 [^] [^^] [^^^] [ответить]
| +/– |
JIT, в принципе, делает то же самое, что и С-компилятор, только не один раз при создании программы, а каждый раз при ее работе. Появился JIT именно из-за того, что чистая интерпретация тормозит невыносимо. И это не костыль? Еще скажите, что замыкания - это не глюк сборщика мусора, возведенный в принцип ;)
| | |
| |
| 8.44, ы (?), 09:49, 30/11/2010 [^] [^^] [^^^] [ответить] | +/– | А вот и нет Каждый раз не требуется, если конечно код не меняется, а вот время ... текст свёрнут, показать | | |
| |
| |
| 10.49, ы (?), 13:53, 30/11/2010 [^] [^^] [^^^] [ответить] | +/– | А теперь представь КИС корпоративную информационную систему , чье внедрение зан... текст свёрнут, показать | | |
| 10.51, ы (?), 14:16, 30/11/2010 [^] [^^] [^^^] [ответить] | +/– | Потому что python это инерпретируемый язык, и оптимизацией его байт-кода под кон... текст свёрнут, показать | | |
|
|
|
|
|
|
|
|
|
| 1.8, stimpack (?), 11:01, 28/11/2010 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
судя по "расческе", как ее тут окрестили, против природы все же не попрешь. Памяти стабильно жрет в два раза больше, а общая желтая полоска явно короче общей синей. Накладные расходы дают о себе знать.
Но сама новость в позитивных тонах :)
| | |
| |
| |
| |
| 4.24, тоже Аноним (ok), 20:39, 28/11/2010 [^] [^^] [^^^] [ответить]
| +/– |
Когда один язык пишут на другом языке (или даже на том же самом), неизбежно растут "обертки" из лишнего кода вокруг того, что действительно надо сделать в конкретном случае.
Оптимизирующий компилятор может бороться с этой регрессией, но в случае интерпретируемых языков его нет...
| | |
| |
| 5.25, Аноним (-), 22:39, 28/11/2010 [^] [^^] [^^^] [ответить]
| +/– |
Python же умеет компилировать в ".pyc" файлы. Может быть когда-нибудь...
| | |
| |
| 6.31, igron (ok), 01:25, 29/11/2010 [^] [^^] [^^^] [ответить]
| +/– |
 Это не компиляция, а просто удаление лишнего, комментариев и т.п.
| | |
| |
| 7.35, userd (ok), 11:15, 29/11/2010 [^] [^^] [^^^] [ответить]
| +/– |
Однако, преобразование исходного текста программы в байткод стековой виртуальной машины - это вполне компиляция.
| | |
|
|
| 5.38, Аноним123321 (ok), 14:38, 29/11/2010 [^] [^^] [^^^] [ответить]
| +/– | |
> Когда один язык пишут на другом языке (или даже на том же самом), неизбежно растут "обертки" ...
жесть! ну и анекдот :DDDDDDDD
...а на чём же ещё можно написать программу (в том числе интерпретатор-или-компилятор) -- КРОМЕ как на языке программирования?
...неужто на Волшебной Мане? :-D
когда пишешь <чтото> на Волшебной Мане -- то "обёртки" -- не растут? :-)
| | |
| |
| 6.41, тоже Аноним (ok), 16:46, 29/11/2010 [^] [^^] [^^^] [ответить]
| +/– |
А вы не в курсе, что любой язык программирования высокого уровня - это обертка над машинным кодом, позволяющая оперировать более сложными сущностями и не взорвать мозг?
Причем чем выше уровень языка, тем больше в этих обертках "мусора", помогающего создать более или менее универсальную абстракцию ценой выполнения лишних команд и использования лишней памяти.
| | |
|
|
|
|
|
| 1.36, Zenitur (?), 13:47, 29/11/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Компилирую последний nasm (libvpx попросил). Смотрю на процесс - а он на Си. Жду nasmnasm.
| | |
|
