Бесплатная версия Scieneer Common Lisp

>Commom

Тогда уж Mommon List

Mormon list?

Прозреваю толпу троллей

Для Ъ - maxima хоть под него собирается?

А нужна ли maxima?

Нужна, до хера кода под ней. Или можешь предложить альтернативу за разумные деньги?

Mammal Lips, о да.

Mummy LISP?

SCL 1.3.7 + Maxima 5.14.0 + Fedora Core 7 (64bit) => A-OK

> Для Ъ - maxima хоть под него собирается?

Зачем тебе scl для maxima? Только если заявленная поддержка архитектур, отсутствующих у свободных реализаций.

Maxima - как бенчмарк качества поддержки некоего минимального подмножества стандарта.

Как зачем? Одна лицензия на LispWorks для 64 битного линакса стоит больше 5 тыс. долларов, под соляру портов вообще нет. А тут даже лицензия стоит порядка 300 баксов.

Для нормальной проверки есть ansi-тесты Dietz'а.

Саныч, я, конечно, понимаю, что ынтерпрайз и все дела, но максима прекрасно работает на 64-битном линуксе на sbcl.

А зато на спарке не работает и вообще максима это не показатель. ИМХО ни одна реализция лиспа, кроме SL не умеет работать с "256G bytes of memory allocated for the lisp heap".

Это уже перебор, многие реализации отпадают. Мне проще код писать, пользуясь тем же подмножеством, что и Maxima.

Кому нибудь удалось бесплатно скачать? Мне отказали, "так как некоторые пункты заказа требуют проверки".

> "так как некоторые пункты заказа требуют проверки".

такая же хрень.

>Тогда уж Mommon List

mormon

Дык весь ЛОР уже качает, 12к коннектов. Мне уже позвонили из Австралии с угрозами.

Заметьте, винда не поддерживается.

Реквестирую выклад на рапидшару или подобное место тем, кто скачал.

Там вроде как генерится лицензия, завязанная на мас адрес.

To get the free version you have to jump through a number of hoops like registering (which appears to be personally approved on a case-by-case basis) and creating a license file that is tied to the installation computer via its MAC address.

http://planet.lisp.org/

И чё? Мы уже МАС поменять не в состоянии?

> Там вроде как генерится лицензия, завязанная на мас адрес.

Оно в плане кодогенерации с SBCL тягаться может?

Со скоростью у него как? Обгоняет сишный код?

Ну и зачем все это после выхода php 5?

Я думаю, что по вычислением с плавающей точкой он его сделает легко. Хотя sbcl может тоже умеет 80 битные числа и всякие фичи современных процессоров.

>Со скоростью у него как? Обгоняет сишный код?

Как известно по утверждениям ЛОРовских аналитиков, сишный код легко обгоняют жаба, моно и похапе с питоном. Посему странице к 4-5-й сабж тоже должен обогнать.

А ето смотря на каких задачах. Не удивлюсь, если их http демон обгонит апача на той же платформе, по числу обрабатываемых коннектов.

>Не удивлюсь, если их http демон обгонит апача на той же платформе, по числу обрабатываемых коннектов.

Вот когда они реализуют всю функциональность апача, тогда и можно будет сравнивать. А так да, лайти легко обгоняет апач.

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

О! Неужели они вняли моему гневному письму, в котором я поклялся не поддерживать SCL пока он не будет бесплатным ;)

> Я думаю, что по вычислением с плавающей точкой он его сделает
> легко. Хотя sbcl может тоже умеет 80 битные числа и всякие фичи 
> современных процессоров.

Да, sbcl умеет 80 бит, если его собрать без поддержки sse2 (в sse2 
32/64 бита только).

Ну вот скачал, проверил этот SCL... 

Итак, в главных ролях SBCL-1.0.21.18, CLISP-2.46 и SCL-1.3.8.1. 
Платформа Fedora Rawhide x86-64, Core2Duo T7500.

Целочисленка. Исходник: http://coding.derkeiler.com/Archive/Lisp/comp.lang.lisp/2006-03/msg01674.html

10 итераций, потому что дефолтные 1000 на SCL и CLISP ждать ну очень 
долго.

sbcl:
Evaluation took:
  0.054 seconds of real time
  0.053992 seconds of total run time (0.052992 user, 0.001000 system)
  [ Run times consist of 0.025 seconds GC time, and 0.029 seconds non-GC time. ]
  100.00% CPU
  117,446,813 processor cycles
  22,770,016 bytes consed

scl:
Evaluation took:
  13.713145 seconds of real time
  13.524339 seconds of thread run time
  13.524341 seconds of process run time
  13.524944 seconds of user run time
  0.030995 seconds of system run time
  [Run times include 0.266625 seconds GC run time]
  0 page faults
  553,436,552 bytes consed by this thread and
  553,426,976 total bytes consed.

clisp:
Real time: 25.087885 sec.
Run time: 24.904215 sec.
Space: 755832 Bytes
GC: 1, GC time: 0.003 sec.


Плавающая точка. Исходник: http://www.ffconsultancy.com/ocaml/ray_tracer/code/5/ray.lisp

Параметры: level = 9, n = 5, потому что дефолтные 512 только на SBCL
за единицы секунд считаются.

sbcl:
Evaluation took:
  0.054 seconds of real time
  0.052992 seconds of total run time (0.051992 user, 0.001000 system)
  98.15% CPU
  117,214,592 processor cycles
  626,944 bytes consed

scl:
Evaluation took:
  44.950226 seconds of real time
  44.225426 seconds of thread run time
  44.225426 seconds of process run time
  44.399254 seconds of user run time
  0.079988 seconds of system run time
  [Run times include 0.688325 seconds GC run time]
  0 page faults
  2,399,990,528 bytes consed by this thread and
  2,399,964,304 total bytes consed.

clisp:
Real time: 11.745443 sec.
Run time: 11.590237 sec.
Space: 171476344 Bytes
GC: 79, GC time: 0.902853 sec.


300 долларов за SCL? Нет, спасибо. Коммьюнити опять порвало в клочья
злобных проприетарщиков. Стоит отметить, что AllegroCL и LispWorks
на этих тестах висят где-то в районе интерпретируемого CLISP.

Btw, я нарушил лицензионное соглашение, опубликовав тут бенчмарки без
ведома владельца SCL... ;) С другой стороны, ко мне применили 
недобросовестную рекламу, сказав, что SCL быстрый.

Спи спокойно, лучше SBCL пока лиспа нет :)

Ну здрасте. Кого сейчас интересует производительность? SCL мне куда более интересен заявленной хорошей поддержкой многопроцессности, хотя попробовать еще не успел. И ваш бенчмарк вообще однобокий.

В догонку:

SCL: * (time (main 9 "bbb" 5))

Evaluation took: 0.079089 seconds of real time

SBCL: * (time (main 9 "bbb" 5))

Evaluation took: 0.160 seconds of real time

What am I doing wrong?

> What am I doing wrong?

Давайте разберёмся. Мне самому интересно, как один форк CMUCL'а может
быть на столько медленнее другого форка.

У меня:

Scieneer Common Lisp 1.3.8.1
Copyright (c) 2000-2008, Scieneer Pty Ltd. All Rights Reserved.
Restricted noncommercial license. Licensed to XXX.
Loaded subsystems:
    Compiler 1.0, target Intel x86

Вы откомпилировать не забыли?

> Вы откомпилировать не забыли?

Я наивно полагаю, что раз это последователь CMUCL, то НЕкомпилировать он не умеет. Я не прав?

Да.

> Да.

Если "Да" означает, что я неправ, то, for your information, disassemble показывает вполне себе машинный код, а не байт-код, как в CLISP.

Очень странно, вот люди пишут

The Scieneer Common Lisp is 10% faster than optimize C code for your problem. The Scieneer Common Lisp takes advantage of SSE2 and SSE3 instructions but does not yet taking advantage of SIMD operations. Extended precision floating point is also supported using the x87 FPU instructions.

Все же откомпилируйте и сравните результат.

File: digamma.c
-=-
#include "math.h"

static inline double digamma(double x)
{
      double p;
      x=x+6;
      p=1/(x*x);
      p=(((0.004166666666667*p-0.003968253986254)*p+
        0.008333333333333)*p-0.083333333333333)*p;
      p=p+log(x)-0.5/x-1/(x-1)-1/(x-2)-1/(x-3)-1/(x-4)-1/(x-5)-1/(x-6);
      return p;

}

double timeit()
{
   int  i;
   double  result;

   for (i = 10000; i < 10000000; i++)
     {
       result = digamma((double) i);
     }

   return result;

}

main()
{
   timeit();
}

-=-

cc -O3 -o digamma digamma.c -lm
time digamma
1.624u 0.004s 0:01.61 100.6%    0+0k 0+0io 0pf+0w

File: digamma1.lisp
-=-
(in-package :cl-user)

(declaim (inline digamma/setq-x))
(defun digamma/setq-x (x)
   (declare (optimize (speed 3) (safety 0) (debug 0))
           (type (double-float (0d0) *) x))
   (let ((x (+ x 6d0)))
     (declare (type (double-float (6d0) *) x))
     (let* ((p (/ 1d0 (* x x)))
           (logx (log x))
           (one 1d0))
       (declare (type double-float one p))
       (setq p (* (- (* (+ (* p (- (* p 0.004166666666667d0)
                                  0.003968253986254d0))
                          0.008333333333333d0) p)
                    0.083333333333333d0) p))
       (+ p (- (- (- (- (- (- (- logx
                                (/ 0.5d0 x))
                             (/ one (setq x (- x one))))
                          (/ one (setq x (- x one))))
                       (/ one (setq x (- x one))))
                    (/ one (setq x (- x one))))
                 (/ one (setq x (- x one))))
              (/ one (setq x (- x one)))))
       )))

(defun timeit ()
   (declare (optimize (speed 3) (safety 0) (debug 0)))
   (let ((result 0d0))
     (declare (double-float result))
     (loop for i from 10000 to 10000000
          do (setf result (digamma/setq-x (coerce (the fixnum i) 'double-float))))
     result))
-=-

* (time (timeit))
Compiling lambda nil:
Compiling Top-Level Form:

Evaluation took:
   1.4379311 seconds of real time
   1.4306431 seconds of thread run time
   1.4306521 seconds of process run time
   1.432089 seconds of user run time
   0.004 seconds of system run time
   0 page faults
   16 bytes consed by this thread and
   16 total bytes consed. 

Признаю, был неправ. compile-file действительно помог, хотя беглым
просмотром disassemble в том и другом случае разницы не увидел.

Целочисленка, с n=512

sbcl:

Evaluation took:
  3.445 seconds of real time
  3.378487 seconds of total run time (3.375487 user, 0.003000 system)
  98.06% CPU
  7,559,477,112 processor cycles
  622,976 bytes consed

scl:
Evaluation took:
  4.73977 seconds of real time
  4.690479 seconds of thread run time
  4.690477 seconds of process run time
  4.699286 seconds of user run time
  0.004 seconds of system run time
  0 page faults
  620,864 bytes consed by this thread and
  620,864 total bytes consed.
С точкой: (n=512)

sbcl:
  6.064 seconds of real time
  6.028083 seconds of total run time (5.981091 user, 0.046992 system)
  [ Run times consist of 0.157 seconds GC time, and 5.872 seconds non-GC time. ]
  99.41% CPU
  13,307,863,679 processor cycles
  460,238,944 bytes consed

scl:
Evaluation took:
  7.817378 seconds of real time
  7.626751 seconds of thread run time
  7.626752 seconds of process run time
  7.62684 seconds of user run time
  0.027996 seconds of system run time
  [Run times include 0.146377 seconds GC run time]
  0 page faults
  326,664,952 bytes consed by this thread and
  326,661,416 total bytes consed.

> Признаю, был неправ. compile-file действительно помог, хотя беглым
просмотром disassemble в том и другом случае разницы не увидел.

Оно компилирует перед этим, пруф:

CL-USER> (declaim (optimize speed))
EXTENSIONS::%UNDEFINED%
CL-USER> (defun foo (a b) (+ a b))
FOO
CL-USER> (compile *)
In: LAMBDA (A B)
(+ A B)
<Много советов по оптимизации>.

Compilation unit finished.
18 notes



CL-USER> (defun foo (a b) (+ a b))
FOO
CL-USER> (disassemble *)
In: LAMBDA (A B)
(+ A B)
<Много советов по оптимизации>.

Compilation unit finished.
18 notes

>Или можешь предложить альтернативу за разумные деньги?
Альтернативы maxima за разумные деньги конечно нет, но сама maxima вряд ли может считаться альтернативой той же maple (поскольку умеет лишь double precision на спец. функциях).

> Альтернативы maxima за разумные деньги конечно нет, но сама maxima вряд ли может считаться альтернативой той же maple (поскольку умеет лишь double precision на спец. функциях).

Дурак?

Ни то, ни другое, для численных задач вообще не пригодно. А для аналитических задач maxima вполне применима, уж всяко не хуже maple.

>Ни то, ни другое, для численных задач вообще не пригодно.
Ну-ну. Man dsolve/numeric в Maple. ode в Matlab имеет низкую точность.

P.S. прежде чем 3.14деть, вы хотя-бы поработать попробывали...