Недостатки Racket

Erlang в этом смысле порадовал (он реально не сериализует объект, а отправляет «указатель» содержащий имя узла и адрес объекта).

Что мешает сделать в Racket такие указатели?

Если ф-я топлевел то можно (если нужный модуль подгружен там где ф-ю собсно будут вызывать). Если это замыкание, то надо юзать сериализованную лямбду (которая делается при помощи тех же механизмов, что сериализуемые продолжения в stateless server).

fork с ipc через pipe

Что именно тебе не нравится - fork или ipv через pipe?

selffix: IPC

fork. это получается еще одна полная копия racket vm, опять жрущая кучу памяти. у нас, в реальной жизни, в итоге:

[dozor@vm64 dfo]$ ps axuww|grep racket|grep -v grep|wc -l
43
[dozor@vm64 dfo]$ echo $((`ps axuww|grep racket|grep -v grep|awk '{print $6}'|tr '\n' + | sed 's/+$//'`))
3745416

fork. это получается еще одна полная копия racket vm, опять жрущая кучу памяти.

Ну так этот отдельный инстанс должен выступать в качестве воркера, а не в качестве таска. То есть в принципе их больше чем ядер быть не может. Какие проблемы?

И, да, при чистом запуске вм 90% объема - это загруженный байткод. Для racket/base там уже 8 мб, а если обрезать до '#%kernel, то и вовсе 3.

я ж сказал - проблемы - пожирание памяти. а ракет, «урезаный до #%kernel», в реальной жизни, нафиг не нужен. еще раз - если ты считаешь, что всё это бред и я не прав - рассмотри предложение по ссылке, а не переубеждай меня тут.

я ж сказал - проблемы - пожирание памяти. а ракет, «урезаный до #%kernel», в реальной жизни, нафиг не нужен.

До кернела это просто пример, до куда можно обрезать. До racket/base - вполне разумно (и так и надо делать, по дефолту вообще). Ну будет у тебя пол десятка воркеров на 10мб каждый, для вашей задачи это слишком много?

если ты считаешь, что всё это бред и я не прав

Я ничего не считаю, ты описал конкретную практическую проблему, я описал как эту проблему предполагали решать сами разработчики racket. Вы так пытались? Проблема осталась?

рассмотри предложение по ссылке

Я на другом конце страны живу, к сожалению.

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

Только они функции, а не переменные.

Функции, да. Ну и чего такого.

И вместо (setf *global* 'new-value) неясно что ставить.Заново (define *global* (make-parameter 'new-value)) ?

Нет, define внутри функции сработает как let, которому параметры до лампочки. Нужно применить parameterize.

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

Кстати, насчёт

Нет unwind-protect

Аналогичный эффект в racket достигается с помощью call-with-continuation-barrier.

Нужно применить parameterize

Не понял. Он же только внутри себя переопределяет. Можно аналог

(defvar *global* 1)
(defun func () *global*)
(defun set-func (x) (setf *global* x))

(func) -> 1
(set-func 2)
(func) -> 2
(let ((*global* 3))
   (func)) -> 3

?

Или хотя бы (define set-func ...) ?

Теперь понял вопрос. Нужно вызвать (*global* 'new-value)

#lang racket
(define *global* (make-parameter 1))
(define (func) (*global*))
(define (set-func x) (*global* x))
(func)
(set-func 2)
(func)
(parameterize ((*global* 3))
   (func))

Теперь понял вопрос

Да, в таком виде полный аналог специальных переменных (плюс-минус скобки).

Тогда по сравнению с Common Lisp'ом минусами остаются только особенности реализации (тредов нет, скорость меньше, чем у SBCL, готовых биндингов/библиотек тоже меньше).

ковырял палочкой :) недостатки сугубо технологические - дистр 77М, на х86_64 gracker и dracket неработоспособны, а без хвалёного REPL небыло смысла ковырять дальше :)

тредов нет

Это шутка что ли?

Racket supports multiple threads of evaluation. Threads run concurrently, in the sense that one thread can preempt another without its cooperation, but threads currently all run on the same processor (i.e., the same underlying OS process and thread) (с) http://docs.racket-lang.org/reference/eval-model.html#(part._thread-model)

Эм. Ты как так запускал все это, что у тебя неработоспособно было? О_О Только что проверил - работает, запускается. REPL тоже работает.

Linux theknight 3.6.8-pf #1 SMP PREEMPT Thu Nov 15 11:58:56 MSK 2012 x86_64 Intel(R) Core(TM) i3 CPU M 350 @ 2.27GHz GenuineIntel GNU/Linux

И чем тебя не устраивает размер дистрибутива?

Угу, и там же ссылка на futures...

скорость меньше, чем у SBCL

Сколько можно уже повторять эту ложь?

futures

Я не понял касколько они реально работают. В документации: «A future executes its work in parallel (assuming that support for parallelism is available) until it detects an attempt to perform an operation that is too complex for the system to run safely in parallel». Возможно ли реально сделать поток с соединением к БД + поток с контроллером + по потоку на каждое соединения пользователя? Или оно внезапно схлопнется и всё начнёт исполняться на одном ядре процессора?

скорость меньше, чем у SBCL

Сколько можно уже повторять эту ложь?

http://benchmarksgame.alioth.debian.org/u32/compare.php?lang=racket&lang2...

Хотя, да, не везде и в разы только на k-nucleotide и fasta.

Плюсануть что ли в карму анонимуса? )

Возможно ли реально сделать поток с соединением к БД + поток с контроллером + по потоку на каждое соединения пользователя?

Это лучше через places тогда делать. Один воркер на бд, один на контроллер, и пара-тройку (ну сколько у тебя ядер осталось свободных) на пользователей.

http://benchmarksgame.alioth.debian.org/u32/compare.php?lang=racket&lang2...

Лол шутаут? Так как на шутауте никто ИРЛ не пишет. В случае идеоматического (не наполненного кучей анальной акробатики с аннотациями типов у всего и вся и генерацией VOPов (я блять могу на Racket тогда сгенерить LLVM-код, и оно будет на уровне сишки)) кода Racket быстрее SBCL чуть менее чем всегда.

На счет шутаута уже приводил пример бтв. В реализации binary trees в Racket деревья на структурах, а в SBCL - на списках. Если в ракетке сделать тоже на списках (изменением буквально пары строк) то получается вдвое быстрее оригинала и на треть быстрее SBCL.

pidigits измеряет скорость ффи дефакто, если взять последнюю версию ракеты там тоже будет быстрее SBCL.

Дата регистрации: 12.02.2013 8:02:55
Первая созданная тема: 12.02.2013 8:50:40

48 минут доходило что для толксов нужен скор 50? Какой толстый вброс.

filtered-in
	  (lambda (name)
	    (regexp-replace
	     #rx"unsafe-fl" name "fl"))
...
(unless (unsafe-fx= o *system-size*)
      (let* ([o1 (unsafe-vector-ref *system* o)])
        (let loop-i ([i  (unsafe-fx+ o 1)]

Так пишут ВНЖ?

Идём дальше. Regex-dna. byte-regexp vs cl-ppcre:scan. cl-ppcre работает со строками, а не с ascii строками - ясно, откуда взялся выигрыш грохота-вымогательства.

Схемка разросшаяся против своей сущности. Тот, кто называет это «батарейками», никогда не видел что такое батарейки на самом деле. Обычно вся прелесть батареек в том, что их можно вынуть и поменять.

Весьма редко. А что?

Идём дальше. Regex-dna. byte-regexp vs cl-ppcre:scan. cl-ppcre работает со строками, а не с ascii строками - ясно, откуда взялся выигрыш грохота-вымогательства.

Ну так предоставьте реализацию CL, которая тоже работает с ASCII строками и мы сравним. А о тех пор - это какие-то ваши левые предположения. Может в данном бенчмарке скорость регекспов - вообще не слишком существенна? Еще мне интересно, почему реализацию на общелиспе в 4(!) раза длиннее. Чего там за говно наворотили?

Схемка

Racket - НЕ схемка. Как следствие, весь остаток поста становится бессмысленными.

Обычно вся прелесть батареек в том, что их можно вынуть и поменять.

А в Racket кто запрещает выкинуть и поменять? Она задизайнена как метаязыковой фреймворк, так уж смена _батареек_ там сделана заведомо легче, прощеи прозрачнее чем в подавляющем большинстве ЯП.

Еще мне интересно, почему реализацию на общелиспе в 4(!) раза длиннее.

Не знаю про какие 4 раза ты говоришь: http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?test=all&lang=...

И это не последний sbcl. Пары тестов вообще нет.

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

Не знаю про какие 4 раза ты говоришь

racket: 527

cl: 1948

Не в 4, в 3.7.

Давай разгоняй ветер дальше. Но racket - тормоз.

А я и не спорю с тем, что racket - тормоз. Мне просто смешно, когда говорят что racket медленее sbcl, в то время как sbcl - еще больший тормоз.

Какой-то миф такой у общелисперов на счет того, что sbcl весь такой быстрый. Хоть под нос им бенчмарки сунь, в которых он тормозит - а хер там: «не вижу, не слышу, и вообще я в домике!!11!».

Вообще-то там только ASCII. В коде стоит

(setf cl-ppcre:*regex-char-code-limit* 128))

А накрутили там два-в-одном варианты для +sb-thread и -sb-thread. Чистая реализация на cl-ppcre на http://benchmarksgame.alioth.debian.org/u32/program.php?test=regexdna&lan... , но она на больших данных падает.

А typed racket - тот-же тормоз, который просто обернули в принудительное указание типов, скорости это не добавляет ни капли.

Вообще-то неверно. http://docs.racket-lang.org/ts-guide/optimization.html

Выкидываются runtime проверки типов, большая часть зависимых от типа решений уходят на стадию компиляции. Фактически, всё то же, что и в sbcl при (declare (type ...))

P.S. Почему на shooutout не используют typed racket?

Вообще-то неверно. http://docs.racket-lang.org/ts-guide/optimization.html

Да нет, в общем верно. То есть программу аналогичную тому, что получается в typed racket, после оптимизаций можно и без typed racket написать. То есть она операции на unsafe-аналоги заменяет, как в тех же шутаутных реализациях.

Какой-то миф такой у общелисперов на счет того, что sbcl весь такой быстрый.

Схема обязана быть медленнее за счёт поддержки продолжений (при одинаково качественной реализации лиспа и схемы). Хотя лисп с cl-cont будет ещё медленней.

P.S. Почему на shooutout не используют typed racket?

Там очень старая ракета, там нету еще typed racket помоему. Или есть но совсем еще недоделанный.

Схема обязана быть медленнее за счёт поддержки продолжений

С чего вдруг? Если продолжения не использовать, то и влияние их в рантайме не существенно. То есть можно построить тест (завязанный на особенности конкретной реализации продолжений), в котором продолжений не будет, но будет из-за них тормознее, однако 99% кода пох совершенно.

Если продолжения не использовать, то и влияние их в рантайме не существенно.

Ну не знаю. Если я просто заверну код в (cl-cont:with-call/cc ...), то тормоза мне обеспечены. Даже если продолжения не используются.

В целом, само наличие продолжений требует некоторой поддержки от всех функций (не будешь же перекомпилировать map в зависимоcти от того, есть в переданной функции продолжение или нет). Аналогично поддержке исключений в C++.

racket: 527 cl: 1948

Где ты это выкопал? И это про regex-dna? По моей ссылке 41.83 и 44.96 - практически на равных, и это единственный тест, где racket хоть 13 сотых отыграл. Ври дальше.

Мне просто смешно, когда говорят что racket медленее sbcl, в то время как sbcl - еще больший тормоз.

Смех без причины - ну ты знаешь...

Хоть под нос им бенчмарки сунь,

Ну вот я тебе «сунул», а ты и орёшь: «не вижу, не слышу, и вообще я в домике!!11!».

Схема обязана быть медленнее за счёт поддержки продолжений

А, так общеблядь наебать пыталась. Ну ожидаемо, чо. Буду внимательнее. Вообще я посмотрел, там все вроде делают под ASCII.

Схема обязана быть медленнее за счёт поддержки продолжений

nuff said.

Выкидываются runtime проверки типов, большая часть зависимых от типа решений уходят на стадию компиляции. Фактически, всё то же, что и в sbcl при (declare (type ...))

А сам racket со всеми своими либами - на typed racket? Весь-весь? Хера толку от проверок в МОЁМ коде, если все «системные» либы - динамические?

Или таки переписали? О_о

P.S. Почему на shooutout не используют typed racket?

вопрос к фанбоям racket

Где ты это выкопал? И это про regex-dna?

Ты вообще за разговором следишь? Речь а размере кода.

Ну вот я тебе «сунул», а ты и орёшь: «не вижу, не слышу, и вообще я в домике!!11!».

Что ты мне сунул? Я выше уже упоминал, шутаутовские бенмарки бессмысленны, т.к. сравнивается неидеоматический код с неидеоматическим кодом. Мне это неинтересно, мне интересна производительность РЕАЛЬНОГО кода.

Там очень старая ракета, там нету еще typed racket помоему. Или есть но совсем еще недоделанный.

указаны 5.3.1 и 5.3.2 - старые? Или фанбоям некогда тесты переписывать?

Ну не знаю. Если я просто заверну код в (cl-cont:with-call/cc ...), то тормоза мне обеспечены. Даже если продолжения не используются.

Потому что код перепидорашивает cps-трансформацией. При нативной же реализации код остается как был, будет тратиться время на сам захват продолжения (то есть вызов call/cc) и собственно вызов продолжения. А все что между ними - на 99% пох.

В целом, само наличие продолжений требует некоторой поддержки от всех функций (не будешь же перекомпилировать map в зависимоcти от того, есть в переданной функции продолжение или нет).

Эта проблема в том случае, если делается cps-трансформация. В нативной реализации никто ничего не передает.

Мне это неинтересно, мне интересна производительность РЕАЛЬНОГО кода.

А это значит код их какой-то фантастики... Ну-ну

Вас интересует размер? Используй apl, j, k

указаны 5.3.1 и 5.3.2 - старые?

5.3.1-2? ну значит обновились, еще недавно все плохо было.

А это значит код их какой-то фантастики...

Именно так. Это код специально для шутаута, к реальности он не имеет отношения.

Вас интересует размер?

А в racket размер не за счет обфускации меньше, там кода меньше просто по смыслу.

И, да, читабельность и понятность решения для меня важнее его производительности.