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

Да еще очень важна масштабируемость. При замене процессора с 16 ядрами на 32 ядра, производительность должна возрастать.

седня день тупака что ли…?

возьми и сделай себе тестег, который 100500+9к строк обработает.

и поделись с нами.

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

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

бугага

значит java

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

Похожа на С++, и уже не очень актуальна.

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

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

тонко, молодец.

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

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

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

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

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

Возможно, их стоит отрезать.

как же ТС тогда дрочить будет, изверг

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

как же ТС тогда дрочить будет

Кому?

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

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

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

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

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

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

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

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

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

Нет, не правильно. Статейку с Википедии прочти хотя бы.

Это рестфул?

Не обязательно.

Чувак лисп хочет. Уж не сомневайся, с дрочкой у него проблем не возникнет.

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

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

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

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

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

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

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

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

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

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

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

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

Тоже предлагаю юзать Го и не выпендриваться.

restful – это в очень общем случае просто crud, а отдавать ты можешь что угодно, хоть богомерзкий xml.

И в общем случае на язык скорее всего абсолютно пофиг. Бери, что знаешь. Ибо затык будет всё равно в сети и базе данных.

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

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

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

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

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

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

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

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

Суммарно вырос.