LINUX.ORG.RU

Производительность кода sbcl

 , ,


0

3

На примере реализации restfull сервиса с запросом к субд и обработки строк результата.

Кто нибудь может дать хотя бы приблизительную оценку в процентах, скажем если сравнить с Go и Elixir? Типа лисп - 100%, го - 800%, эликсир - 85%.

Зачем ты ковыряться в вебне тащишь копролитный конпелятор ногтегрызного ЯП? Он не для этого, а для программы для сортировки музыкальной коллекции придуман, а также, чтобы SICP читать и примеры решать.

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

Это мне надо выучить все эти языки до уровня «написать сервис». А сейчас придет умный человек и скажет, пиши на го, это современный язык, а все эти лиспы и эликсиры сливают и плачут в коридоре. Или наборот, что го очень хорош только для очень узкой ниши, а тексты на нем обрабатывать заманаешься, там даже классов с наследованием нет.

Djanik ()

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

пс - никто и никогда тебе не даст линейного прироста при удвоении мощности цпу.

ergo ()
Последнее исправление: ergo (всего исправлений: 1)
Ответ на: комментарий от Djanik

Говорят, там все просто чудестно с ОО, в отличие от двух остальных. А у меня опыт из С++.

Тебе не нужно ооп для «рестфул сервисов». Используй clojure. Скорость в такой постановке вопроса тоже неуместна.

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

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

Djanik ()

Такой вопрос. Я вообще правильно понимаю термин «рестфул»? Сценарий такой, клиент дает запрос из браузера, я достаю данные из базы по набору параметров телеметрии и отдаю ему json. Это рестфул? Могу еще графики отдавать, наверное.

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

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

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

Говорят, там все просто чудестно с ОО, в отличие от двух остальных. А у меня опыт из С++.

Твой опыт из C++ к CLOS вообще никак не применим, чувак. Возьми golang и не страдай уже.

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

пс - никто и никогда тебе не даст линейного прироста при удвоении мощности цпу.

Это так отмазываются некомпетентные инженеры не умеющие в масштабирование. Доказывается очень просто - поставь рядом две несвязанных физических машины - получишь ровно в 2 раза большую производительность. Всё что меньше - на совести инженеров.

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

Ты хоть прочитал мой комментарий, который процитировал?😄😄😄

Хотя и в твоём кейсе всегда будет меньше 2х. Хреновый из тебя архитектор, если не учитываешь накладные расходы на дистрибьюцию.

ergo ()
Последнее исправление: ergo (всего исправлений: 2)
Ответ на: комментарий от Djanik

Это мне надо выучить все эти языки до уровня «написать сервис»

Ну и какие там заказы выполнять собрался? Даже хеллоувордики за пару часов наговнять не можешь.

На Go, конечно, вебню пиши. Или на Python. Сильно сомневаюсь, что ты упрёшься в производительность.

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

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

Я нигде не говорил, что надо брать го. Его как раз можно взять (но не нужно).

Скорость тоже важна, надо будет рисовать графики и еще не решил как это делать.

Графики рисовать ты все равно будешь в браузере на js. Лисповое ооп тебе тут ничем не поможет как и «скорость». Бери go или clojure и не этосамое.

alienclaster ★★★ ()

CLOS тормозной. Быстрое ООП - на записях. По скорости должно быть примерно одинаково. В SBCL нет горутин или чего-то аналогичного, там только обычные треды. Хотя есть какой-то cl-async, я им не пользовался, и думаю, что он не гармоничен и ломает язык. С другой стороны, в SBCL более умный сборщик мусора, чем в go. Про Эликсир не знаю.

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

Это так отмазываются некомпетентные инженеры не умеющие в масштабирование. Доказывается очень просто - поставь рядом две несвязанных физических машины - получишь ровно в 2 раза большую производительность. Всё что меньше - на совести инженеров.

Или не получишь. Я вот запустил квейк на двух одинаковых тачках рядом, но FPS шото в два раза не вырос.

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

Про мультикаст не слышал?

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

я тебе даже больше скажу… с каждым добавлением ресурса прирост будет уменьшаться, при чем это снижение будет нелинейным.

в общем, сходить бы тебе, почитать чего-нибудь по этой теме.

ergo ()
Последнее исправление: ergo (всего исправлений: 1)
Ответ на: комментарий от ergo

ты хоть прочитал мой комментарий, который процитировал?

ты прям разнос пошел по разным словам без их понимания

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

я тебе даже больше скажу… с каждым добавлением ресурса прирост будет уменьшаться, при чем это снижение будет нелинейным.

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

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

что что-то там что-то нелинейно

Ты точно сам читаешь мои комментарии? Ощущение, что тебе их пересказывает кто-то своими словами 😄

Не вижу смысла продолжать этот диалог. Пусть у вас будет удваиваться/утраиваться и пусть это все будет линейно. И черт с ней, этой клятой физикой. Сдаюсь 😊

ergo ()