LINUX.ORG.RU

Python vs Lisp. Расстановка точек


0

1

питон:

den@ira-desktop:~/work/test$ time python -O test.py 
('answer: ', 39)

real	0m33.035s
user	0m32.890s
sys	0m0.084s
den@ira-desktop:~/work/test$

clisp:

den@ira-desktop:~/work/test$ time clisp test.lsp
39

real	2m44.491s
user	2m42.970s
sys	0m1.464s
den@ira-desktop:~/work/test$

def test():
    r = 0
    for i in range(0, 10000):
        for j in range(0, 10000):
            r = (r + (i * j) % 100) % 47
    return r
r = test()
print("answer: ", r)
(defun test ()
    (setq r 0)
    (dotimes (i 10000 r)
        (dotimes (j 10000 r)
            (setq r (mod (+ r (mod (* i j) 100)) 47))
        )
    )
)

(write (test))

а теперь докажите, что лисп не тормознутое УГ

Ответ на: комментарий от mv

>Чтение хороших лисповых исходников с утра доставляет эстетическое удовольствие и заставляет задуматься о суете нашей жизни.

В фортунки.

anonymous
()
Ответ на: комментарий от dave

>> Язык, скорость?! Часто это не главное.

Немного разовью мыслю. Когда говорят, что мериться пиписьками типа http://shootout.alioth.debian.org/ есть моветон, т.к. язык и его реализации вещи ортогональные, всегда возникает вопрос по поводу поиска той самой реализации, где язык раскрывается во всей своей красе в смысле производительностью. Как это ни печально, как правило спотыкаешься именно о производительность. Эх... Где те 640К...

cathode
()
Ответ на: комментарий от cathode

Есть, конечно, ограничения в производительности, диктуемые самим языком. Так, думаю, что вряд ли когда-нибудь питон догонит по скорости лисп. Этому мешает любовь пинтощиков черезмерно использовать ООП. А сигнальная модель ООП не очень дружит с динамическим языком. Быть может, генерик-функции CLOS быстрее в принципе ;)

dave ★★★★★
()
Ответ на: комментарий от cathode

>раскрывается во всей своей красе в смысле производительностью

Как это ни печально, как правило спотыкаешься именно о производительность.


Производительность уже давно не является узким местом во многих задачах (Google вон поспешно всё прикладное на web переносят). Да и для любого адекватного языка можно сделать байндинги на C'шную библиотеку, где будут собраны все ёмкие вычисления.

anonymous
()
Ответ на: комментарий от anonymous

>> Производительность уже давно не является узким местом во многих задачах

Я бы сказал в популярных задачах, а не во многих......

Google вон поспешно всё прикладное на web переносят

..... например, типа web-морд

cathode
()
Ответ на: комментарий от dave

> Быть может, генерик-функции CLOS быстрее в принципе ;)

Хотя, пожалуй, что это все же не так. Сигнальную модель можно свести к генерик-функциям. Но все равно питонщикам сильно мешает ООП. :)

dave ★★★★★
()
Ответ на: комментарий от anonymous

>Производительность уже давно не является узким местом во многих задачах

15 лет назад на 486 процессоре 33 мегагерца можно было создать хороший текстовый документ. Чтобы сейчас создать *такой же* документ, надо 3 гигагерца и 2 гигабайта памяти. Вопрос: на что программы расходуют системные ресурсы?

anonymous
()
Ответ на: комментарий от anonymous

> 15 лет назад на 486 процессоре 33 мегагерца можно было создать хороший текстовый документ. Чтобы сейчас создать *такой же* документ, надо 3 гигагерца и 2 гигабайта памяти. Вопрос: на что программы расходуют системные ресурсы?

Не гони. Сегодняшний latex точно так же хорошо работает на таком железе, как и тогдашний. И документы получаются ничуть не хуже, а даже и лучше.

anonymous
()
Ответ на: комментарий от anonymous

Не гони. Сегодняшний latex точно так же хорошо работает на таком железе, как и тогдашний. И документы получаются ничуть не хуже, а даже и лучше.

Точняк!

mv ★★★★★
()
Ответ на: комментарий от mv

Что с утра - это правильно. На ночь лисп читать нельзя, скобочки сниться будут. Вообще чтение лисповых исходников может заставить задуматься разве что о том, что хорошая это была штука - карательная психиатрия. Жаль, что отменили.

anonymous
()
Ответ на: комментарий от anonymous

Что с утра - это правильно. На ночь лисп читать нельзя, скобочки сниться будут. Вообще чтение лисповых исходников может заставить задуматься разве что о том, что хорошая это была штука - карательная психиатрия. Жаль, что отменили.

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

bibi
()
Ответ на: комментарий от anonymous

Ты ошибся, это была манда, а не монада, но ты от переботанства не понял.

Да это в сущности те же яйца вид сбоку.

bibi
()
Ответ на: комментарий от cathode

>Мне вот вчера после PL/SQL приснилась монада...

Вот оно! Торжество фрейдизма! Срочно переходить с PLSQL на Хаскель.

Монада в программировании — это абстракция линейной цепочки связанных вычислений. Монады повсеместно применяются в языке Хаскелл.

anonymous
()
Ответ на: комментарий от bibi

>> Да это в сущности те же яйца вид сбоку.

Монада от манды отличается как хуй и хай. Вроде похоже, но что-то не то)))

cathode
()
Ответ на: комментарий от anonymous

>> Монада в программировании — это абстракция линейной цепочки связанных вычислений.

Неправильное определение.

cathode
()
Ответ на: комментарий от dave

Ты потерял контекст.

Да кажется нет. Если говорить о скорости generic-методов, то их природа вовсе не способствует скорости и рассуждение:

Быть может, генерик-функции CLOS быстрее в принципе

принципиально неверно ;)

archimag ★★★
()
Ответ на: комментарий от tailgunner

>> Но все равно питонщикам сильно мешает ООП. :)

Чем?

Для скорости исполнения кода? Как это ни странно, своей доступностью и легкостью написания кода. Как следствие, используют ООП там где надо, и не надо. Как пример, сижу читаю доку к SimPy. Вижу много ООП не по делу. В лиспе, наверное, прежде подумали бы, чем стали использовать CLOS.

Потом, насколько я помню, ООП повсеместно используется в стандартных библиотеках питона. Что не есть гуд для скорости исполнения, но бывает крайне полезно для скорости написания кода.

dave ★★★★★
()
Ответ на: комментарий от archimag

>> Если говорить о скорости generic-методов, то их природа вовсе не способствует скорости

Особенно если учесть каким образом ищется most specific method.

cathode
()
Ответ на: комментарий от bibi

Манда с яйцами? Батенька, срочно к доктору!!!

anonymous
()
Ответ на: комментарий от dave

>> ООП повсеместно используется в стандартных библиотеках питона

Там любой модуль - уже объект, куда же повсеместнее?

cathode
()
Ответ на: комментарий от archimag

> принципиально неверно ;)

Читай мой следующий комментарий.

dave ★★★★★
()
Ответ на: комментарий от Love5an

ага, и AllegroCL или LispWorks

а меценатствовать под это мероприятие ты будешь?

ну можно хотя бы на бесплатных версиях посмотреть. ACL оказался медленней, чем SBCL, а LispWorks на равне:

;;; ACL:
CG-USER(1): (defun test ()
              (declare (optimize (speed 3) (debug 0) (safety 0)))
              (let ((r 0))
                (declare (type fixnum r))
                (dotimes (i 10000 r)
                  (declare (type fixnum i))
                  (dotimes (j 10000 r)
                    (declare (type fixnum j))
                    (setf r (mod (+ r (mod (* i j) 100))
                                 47))))
                (the fixnum r)))
TEST
CG-USER(2): (compile 'test)
TEST
NIL
NIL
CG-USER(3): (time (test))
; cpu time (non-gc) 6,000 msec user, 0 msec system
; cpu time (gc)     0 msec user, 0 msec system
; cpu time (total)  6,000 msec user, 0 msec system
; real time  5,993 msec
; space allocation:
;  844 cons cells, 14,824 other bytes, 9,000 static bytes
39
CG-USER(4):

;;; -------------------------------
;;; LispWorks:

CL-USER 1 > (defun test ()
              (declare (optimize (speed 3) (debug 0) (safety 0)))
              (let ((r 0))
                (declare (type fixnum r))
                (dotimes (i 10000 r)
                  (declare (type fixnum i))
                  (dotimes (j 10000 r)
                    (declare (type fixnum j))
                    (setf r (mod (+ r (mod (* i j) 100))
                                 47))))
                (the fixnum r)))
TEST

CL-USER 2 > (compile 'test)
TEST
NIL
NIL

CL-USER 3 > (time (test))
Timing the evaluation of (TEST)

User time    =        2.420
System time  =        0.000
Elapsed time =        2.425
Allocation   = 0 bytes
0 Page faults
39

CL-USER 4 > 
korvin_ ★★★★★
()
Ответ на: комментарий от anonymous

>> Педивикия к вашим услугам. Правьте.

Тут есть более подкованные в этом вопросе регистранты )) А вообще монада IO создавалась не для «абстракции линейной цепочки связанных вычислений».

cathode
()
Ответ на: комментарий от dave

>>> Но все равно питонщикам сильно мешает ООП. :)

Чем?

Для скорости исполнения кода?

Вообще-то классы в Питоне - это килограмм сахара поверх обычных функций, не более. Так что процедурный стиль или ООП - по скорости различий быть не должно.

tailgunner ★★★★★
()
Ответ на: комментарий от dave

> В лиспе, наверное, прежде подумали бы, чем стали использовать CLOS.

Да ладно, в большинстве библиотек какого-либо аскетизма по поводу использования CLOS замечено не было.

archimag ★★★
()
Ответ на: комментарий от anonymous

>> Кроме IO есть и полно других монад.

Ну это я для примера привел, самого яркого, так сказать.

cathode
()
Ответ на: комментарий от tailgunner

> Так что процедурный стиль или ООП - по скорости различий быть не должно.

Именно в этом сомневаюсь. Для статически типизированного языка, быть может. Для динамического - вряд ли.

dave ★★★★★
()
Ответ на: комментарий от dave

>> Так что процедурный стиль или ООП - по скорости различий быть не должно.

Именно в этом сомневаюсь.

Добавдяется attribute lookup, и всё.

tailgunner ★★★★★
()
Ответ на: комментарий от archimag

> Да ладно, в большинстве библиотек какого-либо аскетизма по поводу использования CLOS замечено не было.

Наверное, все же реже используется, чем ООП в питоне.

dave ★★★★★
()
Ответ на: комментарий от dmitry_vk

Тот код, который я показал, вполне нормально читается лисперами.

Это и есть основная проблема всех ЪЯП. Чтобы начать понимать код на них, эти языки нужно изучить хотя бы до какого-то начального уровня.

Я вот например раньше не знал python (недели две назад начал изучать) и до сих пор не знаю ruby. И тем не менее я был способен чисто интуитивно понимать бОльшую часть чужого кода на python'е и ruby. И даже мог вносить какие-то примитивные изменения. А вот с perl'ом, lisp'ом и haskell'ем такой фокус не проходит. Смотришь на исходник - и чувствуешь себя так же беспомощно, как при попытке угадать значение иероглифов на какой-нибудь древнеегипетской табличке в музее.

Deleted
()
Ответ на: комментарий от tailgunner

> Добавдяется attribute lookup, и всё.

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

archimag ★★★
()
Ответ на: комментарий от tailgunner

> Добавдяется attribute lookup, и всё.

А какова сложность поиска? O(1) или O(n), где n - это число методов в классе? Если O(1), то насколько велика константа. Хотя сомневаюсь, что там O(1) как в статических языках, где, вообще, двойная или тройная косвенная адресация - и все.

dave ★★★★★
()
Ответ на: комментарий от dave

> Наверное, все же реже используется, чем ООП в питоне.

Я не знаю, как можно судить о частоте, тем более, что подходы к ООП там разные. Но, если рассуждать огульно, то скорей всего нет ;)

archimag ★★★
()
Ответ на: комментарий от dave

>> Добавдяется attribute lookup, и всё.

А какова сложность поиска? O(1) или O(n), где n - это число методов в классе?

Там хэш (говорят, очень эффективный), так что вряд ли хуже O(log n). А если учесть, что даже обращение к полям «тупых» объектов (без методов, Си-структурам по факту) делается точно так же, я буду _сильно_ удивлен, если lookup методов на что-то заметно влияет.

tailgunner ★★★★★
()
Ответ на: комментарий от Deleted

>> Это и есть основная проблема всех ЪЯП. Чтобы начать понимать код на них, эти языки нужно изучить хотя бы до какого-то начального уровня.

Есть один интуитивно понятный интерфейс - сиська, все остальное требует изучения.

cathode
()
Ответ на: комментарий от tailgunner

>> Там хэш (говорят, очень эффективный)

Хэш по такому количеству данных будет проигрывать списку типа plista-а только в путь.

cathode
()
Ответ на: комментарий от cathode

>> Там хэш (говорят, очень эффективный)

Хэш по такому количеству данных будет проигрывать списку типа plista-а

Какому «такому»?

tailgunner ★★★★★
()

Не помню уже, а range из примера ТС - это ООП или нет?

dave ★★★★★
()
Ответ на: комментарий от tailgunner

Такому «такому». Даже в самой хитровывернутой иерархии классов вряд ли найдется класс с числом методов больше 50-80. На таком количестве ключей строить хэштаблицу тупо.

cathode
()
Ответ на: комментарий от cathode

> вряд ли найдется класс с числом методов больше 50-80. На таком количестве ключей строить хэштаблицу тупо.

Ну, тебе виднее, не вопрос. Правда, мой пойнт был не совсем в этом.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

> Там хэш (говорят, очень эффективный), так что вряд ли хуже O(log n).

Это уже много. И вряд ли можно сделать лучше, учитывая, что log n - самая медленно растущая функция.

dave ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.