LINUX.ORG.RU

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

 ,


0

0

Scieneer Common Lisp - это форк CMUCL, сделанный в 2000 году. Основные усилия по развитию языка были сфокусированы на высокопроизводительных научных расчетах (high-performance scientific computing). В результате, по мненю авторов, получился "Professional Common Lisp implementation for Symmetrical Multi-Processor (SMP) systems which is a key requirement for many high performance computing and enterprise applications."

Платформы, поддерживаемые языком:
32-bit (Linux x86 Solaris [x86, SPARC], HPUX 11.11 HPPA),
64-bit (Linux x86-64 Solaris [x86-64, SPARC], HPUX 11.11 HPPA).

>>> Подробности



Проверено: Shaman007 ()

Mummy LISP?

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

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

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

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

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

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

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

Sun-ch
() автор топика
Ответ на: комментарий от Sun-ch

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

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

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

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

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

anonymous
()

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

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

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

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

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

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

Sun-ch
() автор топика

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

Minoru ★★★
()

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

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

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

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/

Sun-ch
() автор топика
Ответ на: комментарий от Sun-ch

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

yz
()
Ответ на: комментарий от Sun-ch

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

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

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

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

Sun-ch
() автор топика
Ответ на: комментарий от Gharik

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

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

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

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

Sun-ch
() автор топика
Ответ на: комментарий от Sun-ch

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

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

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

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

Sun-ch
() автор топика

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

xTERM ★★
()
Ответ на: комментарий от Sun-ch

> Я думаю, что по вычислением с плавающей точкой он его сделает
> легко. Хотя 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 быстрый.

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

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

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

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

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

В догонку:

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?

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

> 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

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

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

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

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

> Да.

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

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

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

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.

Sun-ch
() автор топика
Ответ на: комментарий от Sun-ch

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. 

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

Признаю, был неправ. 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.

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

> Признаю, был неправ. 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

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

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

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

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

Дурак?

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

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

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

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

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