LINUX.ORG.RU

Go или Scala в играх

 , ,


0

4

Что перспективнее для переписывания игрового сервера с эталонной реализации на python(+3 питон модуля нативных на сишке): Scala или Go?

Тестил node.js - генерирует нашу игровую карту за 34 мсек, питон же отрабатывает 970 мсек (почти секунду). Ядро использует двумерные/трёхмерные массивы, поиск путей A*, всякие логарифмические рандомы/натуральное распределение.

Если брать гоу - не укакаемся ли мы писать это всё? На питоне то писать было не совсем просто, а как с этим (всякие графы с весами, querry приоритетные) обстоят дела в гоу или скала? В скале скорее всего я легко смогу подключить java либы, но мы стараемся не тянуть в наш движок ненужный функционал и жирных либ. Не из соображений производительности, а в плана легкого рефакторинга.

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

Короче, мне не нравится java way, но скалу рассматриваю из-за лёгкой похожести на питон. Гоу тоже интересен, но библиотек мало, опыт подчерпнуть просто не откуда по гоу, уточнять всё придётся на stackoverflow, если выбирать главной реализацией его. Также на гоу я пишу в Sublime, писАть тяжело, автокомплит с плагином для гоу никудышный, в доках приходится зарываться, в час по чайной ложке. К Скале есть отличный плагин в IDEA... Скала прекрасно умеет функциональщину, легко обрабатываются массивы и т.п. - в каком-то плане такой же рай как и в питоне :)

★★★★★

Последнее исправление: CYB3R (всего исправлений: 2)

Что уж точно, так Go будет значительно более многословным чем Python или Scala. Если у вас при статической типизации необходимы generics, то вы приехали, в Go тут только какой-то костыльный шаблонизатор аля привет из 80-х.

Рекомендую Scala если не жалко памяти на сам JVM. В качестве бонуса тот код который у вас на С, если он сугубо математический, то можно переписать на той же Scala, но только на массивах, без ФВП и без жирного for-loop, только через while и у вас будет скорость близкая к С в этих узких промежутках

vertexua ★★★★★
()

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

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

Со скалой есть много проблем, начиная с того что выловить скала программиста в дикой природе еще сложнее чем программиста на го

Откуда инфа?

vertexua ★★★★★
()

PyPy? Какая-то у вас совсем неправильная скорость.
Может проще починить чем целиком переписывать?

Vit ★★★★★
()

Скала прекрасно умеет функциональщину

А какой смысл вообще писать на скале не в функциональном стиле?

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

А почему бы и нет? Она вообще мультипарадигменная. Начинающий может обходиться и без ФП.

Правда очень скоро начинаешь его использовать ибо быстрее, короче и нагляднее :)

LongLiveUbuntu ★★★★★
()

Тебе скалу лучше не брать, Go норм

Debasher ★★★★★
()

Тестил node.js - генерирует нашу игровую карту за 34 мсек, питон же отрабатывает 970 мсек (почти секунду).

Что, bottleneck именно в генерации игровой карты?

anonymous
()

Точно проблема в питоне? С массивами через numpy работаете? А распараллеливать пробовали? Непонятно, почему node.js в 30 раз быстрее.

sanchopanca
()

Где вас таких берут? Вам правда легче поменять язык, чем профилировать, изменять алгоритмы, распараллеливать вычисления? Пишите уж тогда сразу на C++.

anonymous
()

Rust ещё не советовали?

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

Да кому ты рассказываешь. Развелось этих программистов как грязи. А вот вакансий для них нет почти.

BattleCoder ★★★★★
()

Тестил node.js - генерирует нашу игровую карту за 34 мсек, питон же отрабатывает 970 мсек (почти секунду)

И проблема конечно же в языке, ага

Gvidon ★★★★
()

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

nagibator
()

А в чём проблема питонячей реализации?

vladimir-vg ★★
()

пиши на ocaml'e - и шустро (в отличие от Scala), и легковесные треды есть (в пику Go) + отличное сочетание ФП и императивщины + отличный FFI.

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

пиши на ocaml'e - и шустро (в отличие от Scala)

Гон, код на Scala бегает шустро - в большинстве случаев не медленнее, чем на Java. А памяти жрёт много.

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

Гон, код на Scala бегает шустро - в большинстве случаев не медленнее, чем на Java. А памяти жрёт много.

шустро в сравнении с Java. но куда им до нативного ocaml'a?

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

выловить скала программиста в дикой природе еще сложнее чем программиста на го

Плохо искали. Мне что-то не сильно сыпятся по скале вакансии.

у каждого своя скала

И да, и нет.

Субъективно, ситуация намного лучше, чем с C++. Но некоторый разброс стилей имеет место быть: начиная со Scala-как-Java, до трешака с типами и макросами, как в scalaz и shapeless. По опыту могу сказать, что намного больше вероятность встретить код где-то у нижней границы этого ареала. Магия - удел немногих.

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

куда им до нативного ocaml'a

Не дай себя обмануть - ocaml тоже крутится в своём рантайме навроде JVM. Просто он другой и пакуется в исполняемый файл.

Я бы сформулировал так: куда рантайму ocaml'а, да оракловой JVM?

migesok
()
Ответ на: комментарий от migesok
$ file main.native
main.native: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=9f9b6b47cbc008d4f50d7886a00269b9182b406f, not stripped

ocaml умеет как и в байткод, так и в натив.

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

и что? это же не виртуальная машина какая-нибудь. все работает нативно и быстро, смысла сравнивать с JVM-based не вижу - OCaml скорее замена C++ (у которого тоже свой рантайм, кстати).

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

Да, в работе с многомерными массивами и обходе соседей.

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

С массивами работаем не через numpy. Распараллеливать пробовали - результат не очень, данные плохо параллелятся - все элементы зависят от соседних, между тредами придётся синхронизировать данные - в топку, производительность ощутимо падает.

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

Си - ооочень много кода, в движок тащить придётся библиотеки сишные, они могут ещё и не собраться под какой-нить ARM - гемор и риск.

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

тот код который у вас на С, если он сугубо математический, то можно переписать на той же Scala, но только на массивах, без ФВП и без жирного for-loop, только через while

Как на счет breeze? К чему эта игра в «я у мамы оптимизатор»?

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

Посмотри сравнение scala с OCaml http://benchmarksgame.alioth.debian.org/u32/compare.php?lang=ocaml&lang2=scala
Scala тоже компилируется в натив благодаря JIT, поэтому она обгоняет OCaml.

OCaml скорее замена C++

Замена с++ с сборщиком мусора? лол.

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

Посмотри сравнение scala с OCaml http://benchmarksgame.alioth.debian.org/u32/compare.php?lang=ocaml&lang2=...

Вижу слив по объему памяти где в разы, а где и на порядки.

Замена с++ с сборщиком мусора? лол.

А Си++ не только для рилтайма используется.

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

Какой breeze, людям чаще попроще вещи нужно делать. Плюс полистав их сорцы я увидел дохрена функциональщины, так что это они «у мамы оптимизаторы» хреновы. Еще бенчмаркают этого слоупока, лол

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

Чего фейспалм? Если обмазаться numpy - то придётся забыть о pypy, jython. А я хотел бы легко мигрировать между платформами.

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

Чего фейспалм?

Того, что если нужна скорость, numpy без вариантов.

А я хотел бы легко мигрировать между платформами.

Python с Numpy уж точно мигрирует не хуже Scala или Go.

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

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

vertexua ★★★★★
()

но скалу рассматриваю из-за лёгкой похожести на питон

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

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