Python и Psyco

Прикольно. Добавление двух строчек:

1. import psyco
2. psyco.full()

В начало программы вычисления чисел Фибоначи, ускоряет оную... в 30 раз

Всего в 2.5 раза медленнее чистого Си

А вот интересно, есть ли что-нибудь подобное для Perl, ибо нет времени ещё и Питон с нуля ботать
Хотя мне кажется, для подобных вещей вполне оправдана связка perl+forth, когда всю мутную рутину типа файлы-строки и т.д. оставляем Перлу, а Форту поручаем что-нибудь сильно греющее процессор.

x000> А вот интересно, есть ли что-нибудь подобное для Perl

Компиляторы в бинарный вид есть, а вот реально ускоряющих выполнение Perl-программ не слышал.

x000> ибо нет времени ещё и Питон с нуля ботать

Я, вот, как раз сейчас за Питон берусь. Похоже, через 2..3 года на нём очень и очень многое работать будет.

Да и сейчас меня просто поражает количество библиотек и модулей под него.

Кроме того, весьма удобный, мощный и гармоничный язык. Да ещё и достаточно быстрый для скриптового (без psyco - этот модуль не всюду реальный прирост даёт).

x000> Хотя мне кажется, для подобных вещей вполне оправдана связка perl+forth, когда всю мутную рутину типа файлы-строки и т.д. оставляем Перлу, а Форту поручаем что-нибудь сильно греющее процессор.

Потому, ИМХО, будущее за "языковыми клеями", типа .NET. Ну и, может, Java удержится на коне и возьмёт эту область, последнее время у них тенденции на лицо. Хотя ещё и более робкие и инерционные, чем в .NET

...

Но вот как заменитель Перлу в консоли, заменитель древнему Бейсику на десктопе и заменитель PHP в Вебе - тут Питон очень хорошо вписывается. И это его ниша будет, думаю.

Так уж и важно быстродействие для Питона? Что то я не слышал чтобы на нём писали расчётные задачи..

OSland> Так уж и важно быстродействие для Питона? Что то я не слышал чтобы на нём писали расчётные задачи..

Питон сейчас первый претендент на язык всяких научных расчётов

Кроме того, сейчас Питон (области, где важно быстродействие):

- Высокопроизводительная Web-платформа
- Язык плагинов массы ресурсоёмких приложений (Blender, GIMP)
- Язык кучи популярных десктопных GUI-приложения (Gajim, куча Gnome-аплетов...)
- Скриптовый язык игровых движков (Civilization IV)

Интерпретатор по определению не может быть быстрее - VM требует дань в виде тиков процессора, даже форт тут проигрывает.
А так - да - Питон один из самых лучших языков последних лет.

Вы знаете (!) есть такие специальные щипцы для обжима витой пары в ардж-45. И так же наверняка знаете что туже самую операцию можно и отвёрточкой тоненькой сделать - только вот всёж щипцами и быстрее и легче и надёжнее.. поэтому одним Питоном все "дырки" не заткнуть. Слишком он широкий уже стал. Монстр.

OSland> Интерпретатор по определению не может быть быстрее

А в наше время разве интерпретаторы среди популярных языков ещё хоть где-то остались? Ну, кроме JavaScript на стороне клиента и /bin/bash.

Интерпретаторы остались конечно - куда же без них?
Просто они сейчас попрятались внутрь конечных программых продуктов - в качестве скриптов, диалог-настройка и т.п.

Интерпретаторы как языки? Сейчас когда IDE-шки стали "воровать" у интерпритаторов интерактивность при разработке кода - даже сложно и ответить что есть иптерпритатор, а что компилятор..

Питон - вроде бы интерпретатор, форт (но его никто не знает)..ДжВиБайсик был такой

За рисунок рядом с моим ником конечно спасибо - только убрать его можно как то?

OSland> Питон - вроде бы интерпретатор

Фиг знает, сколько уже времени (если не с самого начала) компилятор. При чём в наше время даже с сохранением байткода в *.pyc

> форт (но его никто не знает)

Двухрежимный транслятор, основной режим (с точки зрения конечного продукта) которого - классический компилятор. Интерпретация там только при трансляции входного потока.

> ..ДжВиБайсик был такой

Ну ты вспомнил. Я даже qbasic (не путать с компилятором QB45) решил не приводить, а он помоложе будет

Как бы там ни было, сегодня практически все "скриптовые" языки - компилирующие. Просто некоторые компилируют неявно (Perl или PHP без eaccelerator) при каждом запуске, а некоторые так и вообще в "натуральном виде" - тот же Питон.

OSland> За рисунок рядом с моим ником конечно спасибо - только убрать его можно как то?

Сменить на свой. В шапке форума в "Объявлении" см. ссылочку Что за аватары мне прописываются?

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

Питон компилятор? Я не так хорошо его знаю, но по моему там есть причина по которой он всё же интерпретатор - там вроде бы где-то данные можно исполнять как код в run-time?

А интерпретация форта (классического) происходит же не только при обработке входного потока. Там должен быть адресный толковщик шитого кода в момент исполнения.. Некая VM.. (про SPF не будем говорить - он "выродок" в этом смысле - хотя с какой стороны взглянуть..)

Инрепретаторы ПОТЕНЦИАЛЬНЕЕ мощнее компиляторов, дайте время - и именно они завоюют мир.

OSland> Питон компилятор?

Именно. Ибо исполняет код программы не "с листа", а в виде байткода. Более того, в отличии от многих других аналогов в наше время имеет привычку сохранять байткод на диск в *.pyc файлах, чтобы при повторном запуске не компилировать заново

OSland> Я не так хорошо его знаю, но по моему там есть причина по которой он всё же интерпретатор - там вроде бы где-то данные можно исполнять как код в run-time?

Возможность eval не делает компилятор интерпретатором Ибо реализовать оный я могу даже на Си (прицепив в комплект к программе Си-компилятор). А в том же .NET это вообще штатная вещь.

OSland> А интерпретация форта (классического) происходит же не только при обработке входного потока. Там должен быть адресный толковщик шитого кода в момент исполнения..

Компилятор != компилятор в машинный код. Второй случай - только подмножество первого.

OSland> Некая VM..

Если рассматривать VM как интерпретатор, то в наше время всё вообще будет весело. Возьми, скажем, процессоры от Трансмета. Их внутренний машинный код не имеет ничего общего с x86. Они выполняются "в виртуальной машине на процессоре" (транслятор команд). Поэтому даже x86 ассемблер с этой твоей точки зрения на этих процессора превращается в "интерпретатор".

Нет, разница между этими классам трансляторов определена не один десяток лет и вполне определённо. Интерпретатор - это транслятор, который исполняет код прямо из исходника, без промежуточных форматов. Скажем, если в qbasic подменялся какой-то фрагмент исполняемой программы во время её исполнения, то работа программы менялась сразу, без её перезапуска.

А вот компиляторы - они перед исполнением преобразуют во внутренний формат ВЕСЬ код программы сразу. И только потом исполнят во внутреннем формате. А уж каким методом исполнят - дело десятое.

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

OSland> Инрепретаторы ПОТЕНЦИАЛЬНЕЕ мощнее компиляторов, дайте время - и именно они завоюют мир.

Думается мне, время интерпретаторов уже давно прошло.

Вот время скриптовых языков - как раз сейчас пришло. Но практически все из них - компиляторы

>>> Ибо реализовать оный я могу даже на Си (прицепив в комплект к программе Си-компилятор

подключите - получите интерпретатор


Далее - интересно девки пляшут - это если Питон в байткод - то это компилятор, а вот если ДЖава - то интерпритатор? )

Но вообще то я вынужден признать что ситуация с определением интерпрЕтатор/компилятор сложная и запутанная. Ваше определение (исходный код и т.п.) мне не нравиться - мне ближе фортовское - что интерпрЕтатор имеет транслятор в run-time, а компилятор - нет.

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

qbasic работал через шитый код

>> Ибо реализовать оный я могу даже на Си (прицепив в комплект к программе Си-компилятор
OSland> подключите - получите интерпретатор

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

OSland> Далее - интересно девки пляшут - это если Питон в байткод - то это компилятор, а вот если ДЖава - то интерпритатор? )

Окстись, родной Java не только компилятор (изначально), но более того, это компилятор в нативный машинный код. Или у нас недавно JIT отменили? Или ты вдруг Java и JavaScript путаешь?

OSland> Но вообще то я вынужден признать что ситуация с определением интерпритатор/компилятор сложная и запутанная.

В том-то и дело, что всё очень и очень прозрачно.

Формальное определение, повторюсь - это то, по которому интерпретатор исполняет код строчка за строчкой, а компилятор - транслирует весь исходник во внутренний формат.

OSland> qbasic работал через шитый код

qbasic и QB - это разные языки. Первый - интерпретатор, исполнял прямо "с листа". Можно было даже программу подменять во время выполнения. Второй - компилятор в байткод. Из-за этого, между прочим, у них разница в скорости в порядок с лишним была. Чуть ли не раз в 20

спасибо за общение - ушел спать - сил уже нет..

P.S. а будущие - всё же - за интерпретаторами

Balancer> Т.е. я с помощью прикладной программы могу вдруг превратить язык, на котором она написана из одной категории в другую?

да


Balancer> Или ты вдруг Java и JavaScript путаешь?

ну из контекста совершенно ясно, что я имел ввиду ту джаву которая имеет виртуальную машину..

Balancer> Формальное определение, повторюсь - это то, по которому интерпретатор исполняет код строчка за строчкой, а компилятор - транслирует весь исходник во внутренний формат.

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


Balancer> qbasic и QB - это разные языки. Первый - интерпретатор, исполнял прямо "с листа". Можно было даже программу подменять во время выполнения. Второй - компилятор в байткод

я знал только "Кю" и "Квик" первый в байт код второй - компилятор.. про чистый интерпретатор васика начинавшийся с "q" впервые слышу..

OSland> да

Это несерьёзно

OSland> ну из контекста совершенно ясно, что я имел ввиду ту джаву которая имеет виртуальную машину..

Тем более несерьёзно.

OSland> для меня - возможность транслирования в рантайм, поскольку исходный код штука гибкая - это может быть и формат интел нехдесимал.

Формулировка крайне ограниченная. Пример с процессорами Transmeta я уже приводил. Сюда же можно прикопать Java-процессоры или выполнение кода в эмуляторах. Ладно язык, но что, в зависимости от того, выполняется ли один и тот же бинарник на родном железе или в эмуляторе, язык на котором он написан, будет превращаться то в компилятор, то в интерпретатор? Это уже, извини, совсем бред.

OSland> я знал только "Кю" и "Квик" первый в байт код второй - компилятор.. про чистый интерпретатор васика начинавшийся с "q" впервые слышу..

qbasic был чистым интерпретатором. Подмени ему программу во время выполнения - он начнёт выполнять новую. Когда-то я пользовался этим трюком. Точно также он и не видит синтаксических ошибок в коде, пока до них не дойдёт.