Курилка программистов, Флуд на около программерские темы Опции

[NanoBot-AMK]

Команда есть в наборе SSE4.2, но её нет в SSE4A. Так что нету её у меня.
А вообще, говорилось реализация хэшей с помощью базовых наборов, х86 и АРМ. Так вот, АРМ рвёт х86 только так, в точности по скорости работы хэшей. Там где х86 3 инструкции использует, АРМ использует одну, и как правило на суперскалярных АРМах эта инструкция вычисляется за один такт. А х86 тем временем потратит 3 такта. И лишь благодаря волшебному слиянию команд, может выполнить код быстрей, но это только новые процессоры, вроде райзена. Т.е. происходит процедура замены этих команд на одну АРМ подобную.

[abramcumner]

NanoBot-AMK, а результаты арма есть или он рвет в теории?
Кроме того не очень понятно, зачем сравнивать современные армы с x86 двадцатилетней(а то и тридцатилетней) давности. Наверное да, современные армы должны быть эффективней старинных х86, но это не точно. Почему не сравнить нынешние армы хотя бы с десятилетним интелом?

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

У всех процессоров сейчас есть волшебное слияние. Ты же сам упоминал 3 операции за такт на арме. На х86 "слияние" появилось в пентиумах(1992г). С тех пор все х86 с "волшебным слиянием".

[NanoBot-AMK]

По моим расчётом на hash MD5, ARM типа Cortex, должен тратить 4 такта на байт.
Тем временем современные процессоры х86 дают около 5 т/б, а мой как я говорил 6.36 т/б.
Слияние могут только самые последние процы делать. Об этом Кошак упомянул, и при чем не так эффективно, как если бы код сразу в RISC код переделать.

Сообщение отредактировал NanoBot-AMK - 12.01.2021, 21:28

[xrModder]

Не хочу начать очередную срач дискуссию, но такой вопрос: чем JavaScript плох перед Lua при применении в играх?

[Supple Hope]

Не хочу начать очередную срач дискуссию, но такой вопрос: чем JavaScript плох перед Lua при применении в играх?

Не знаю. Как по мне, оба одинаково плохи.

[xrModder]

Не знаю. Как по мне, оба одинаково плохи.

Это не ответ. Ладно, чем оба языка одинаково плохи?

[Supple Hope]

Не знаю. Как по мне, оба одинаково плохи.

Это не ответ. Ладно, чем оба языка одинаково плохи?

Динамическая типизация.

[abramcumner]

Бенчмарки скриптовых языков: https://github.com/r-lyeh-archived/scriptorium

[jamakasi]

Не хочу начать очередную срач дискуссию, но такой вопрос: чем JavaScript плох перед Lua при применении в играх?

С точки зрения интеграции в движек lua лучше, он изначально для этого создан и весьма широко применяется. Хотя и с интеграцией js были вроде движки, как минимум помню игру crome но не помню там была java или javascript а это разные языки.
Тут надо понимать принципиальные разницу. LUA был изначально придуман как нечто что интегрируется в другое приложение, и собственно там и застолбился. JS же изначально был уродцем который берет синтаксис Java который сильно в свое время всем зашел, но при этом типа без ниши как таковой, типа куда пойдет. Пошел он в веб, набрал критическую массу и сейчас изза этого костылями шагает назад в виде nodejs. К слову как человек пишущий на java иногда могу сказать что в ней есть встроенная поддержка ecmascript(js) в каждой версии, но ниразу не видел чтобы хоть гдето применялся на серьезных щщах.

Не знаю. Как по мне, оба одинаково плохи.

Не соглашусь, все в меру должно быть. Если в игре реализуют львиную долю логики в на скриптовых языках то это зло кровавое. Если это используют с умом, скажем используют чисто в квестах\катсценках и т.д. то это зачастую очень удобно для левелдизайнеров\квестописателей. Быстро въехали в язык и могут творить невероятные вещи. А вот когда в скрипты начинают тащить куски игры то это фейл в большинстве случаев, программисты движка страдают, дизайнеры страдают, все страдают и это всегда является тормозом разработки.

[Supple Hope]

Не хочу начать очередную срач дискуссию, но такой вопрос: чем JavaScript плох перед Lua при применении в играх?

С точки зрения интеграции в движек lua лучше, он изначально для этого создан и весьма широко применяется. Хотя и с интеграцией js были вроде движки, как минимум помню игру crome но не помню там была java или javascript а это разные языки.
Тут надо понимать принципиальные разницу. LUA был изначально придуман как нечто что интегрируется в другое приложение, и собственно там и застолбился. JS же изначально был уродцем который берет синтаксис Java который сильно в свое время всем зашел, но при этом типа без ниши как таковой, типа куда пойдет. Пошел он в веб, набрал критическую массу и сейчас изза этого костылями шагает назад в виде nodejs. К слову как человек пишущий на java иногда могу сказать что в ней есть встроенная поддержка ecmascript(js) в каждой версии, но ниразу не видел чтобы хоть гдето применялся на серьезных щщах.

Не знаю. Как по мне, оба одинаково плохи.

Не соглашусь, все в меру должно быть. Если в игре реализуют львиную долю логики в на скриптовых языках то это зло кровавое. Если это используют с умом, скажем используют чисто в квестах\катсценках и т.д. то это зачастую очень удобно для левелдизайнеров\квестописателей. Быстро въехали в язык и могут творить невероятные вещи. А вот когда в скрипты начинают тащить куски игры то это фейл в большинстве случаев, программисты движка страдают, дизайнеры страдают, все страдают и это всегда является тормозом разработки.

Ну тут сыглы. Насчет быстро въехать - хз, лично мне сами по себе скриптовые языки нифига не проще компилируемых. А простота достигается за счет хорошего АПИ/библиотеки с кучей удобных и полезных готовых функций и классов.

[RayTwitty]

Каждый инструмент хорош для своей задачи. Говорить о том, хороша ли дин. типизация или плоха, это тоже самое что говорить о молотке и кувалде. Одно другое заменить не может.

[Supple Hope]

Каждый инструмент хорош для своей задачи. Говорить о том, хороша ли дин. типизация или плоха, это тоже самое что говорить о молотке и кувалде. Одно другое заменить не может.

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

[RayTwitty]

Так динамическая типизация - это

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

или вобще забываешь и умножаешь уток на милиграммы.

Это проблема программиста, а не ЯП. Смысл переменных при статической типизации также требует документирования.

Сообщение отредактировал RayTwitty - 26.01.2021, 00:07

[Supple Hope]

Так динамическая типизация - это

экономия времени написания кода

Сколько времени примерно экономится в процентах?

[RayTwitty]

Сколько времени примерно экономится в процентах?

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

[Modera]

Не хочу начать очередную срач дискуссию, но такой вопрос: чем JavaScript плох перед Lua при применении в играх?

Вечнодерьмовые интерпретаторы. В нулевые годы они были либо кривыми (Mozilla, SpiderMonkey) либо закрытыми (Opera) либо кривыми и закрытыми (IE). Можно до сих пор скачать на сайте у мозиллы какие-нибудь древние spidermonkey типа 1.6 и испытать на своей шкуре.
Потом кривизна немного пофиксилась, но не исчезла, интерпретаторы JS стали очень тяжеловесными, и только после этого появились всякие фичи типа JIT-компиляции, которые для игр желательны.

LUA напротив был стабилен уже очень давно, LuaJit тоже существует очень давно, и он не тяжеловесный.

Никаких преимуществ JS перед луа как язык не имеет. Они вообще почти одинаковые, на самом деле, потому что JS был слизан с луа и отличается только синтаксисом.
Короче всё понятно должно быть, почему.

[Supple Hope]

Сколько времени примерно экономится в процентах?

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

Достаточно это сколько?

[Modera]

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

Динамическая типизация - это как раз самый главный инструмент под разные задачи. В реальных программах большинство данных хранится в структурах и контейнерах, а не стековых переменных. И вот тут уже здорово упрощаются многие задачи.
К примеру если тебе нужна функция которая выводит в лог структуру в виде строки, тебе в JS понадобится одна универсальная функция, которая принимает любой объект, перебирает все поля объекта и записывает в виде строки. В статических языках тебе понадобится для каждого типа(структуры) писать отдельную функцию, а типов могут быть тысячи.

Контейнеры это вообще отдельная песня. Без динамической типизации они выливаются либо в кучи небезопасных кастов, как например в делфи TList*, либо в особо дурацких языках таких как C++ в шаблоны, которые ведут к ужасному code-bloat, если у тебя в проекте 10 DLL, и в каждой из них используется std::vector<int>, код его реализации будет содержаться в каждой ДЛЛ, и не надо петь что это совсем немного и оперативной памяти у тебя достаточно, нерезиновые кеши у процессоров никуда не делись до сих пор.
Кроме этого, шаблоны ещё увеличивают время компиляции, вплоть даже до нескольких часов, если проект большой. У программеров тогды возникает желание это время экономить, они вкручивают луа с динамической типизацией который компилируется на лету при запуске программы и выносят туда весь некритичный к производительности код... Ну ты понел.

Бывали ещё языки которые совмещали динамическую и статическую типизацию, например ActionScript, но чёт не взлетело. Вот даже ты флеш не любишь. Остался только TypeScript от корпорации майкрософт, это такой ActionScript, который компилируется в JavaScript без ограничений, и сводит на нет всю пользу от своей строготипости.

* Ради великой справедливости, в делфи уже тоже шаблоны добавили, только они не шаблоны, а дженерики, но эт не важно.

[jamakasi]

Ну тут сыглы. Насчет быстро въехать - хз, лично мне сами по себе скриптовые языки нифига не проще компилируемых. А простота достигается за счет хорошего АПИ/библиотеки с кучей удобных и полезных готовых функций и классов.

Тут вопрос в сторонних людях. Вот пишешь ты свой двиг, и ты хоть 1000 раз обмажся красивым и удобным api но не сможешь заставить этим пользоваться левелдизайнера. А вот тот же Lua который ты подключишь и вынесешь только нужные api и задокументируешь изучиться буквально за вечер, максимум два. В любом случае это тоже в какомто роде костыль т.к. ты как разработчик движка должен был сделать удобный инструментарий вместо скриптов.
Взять для примера двиг goldsrc\source\квековские шде для левелдизайнеров\мапперов инструмент в виде IO между сущностями. Это очень удобно, пока не перерастает в сложные скрипты и тогда это уже проблема. Был бы именно скриптовый язык типа js\lua\angelscript то такие штуки были бы в разы проще.

Короче, нужна золотая середина.

[abramcumner]

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

Так это разные кеши же: кеша данных и кеша инструкций.

И как раз 10 копий стдвектора это кэшфрендли. Код, использующий вектор, и код самого вектора лежат рядышком и в кэше. Процессор все инструкции достает из кэша, а не мотается по всей памяти при вызовах методов вектора

Шаблонность(дженеричность) - это предсказатель переходов-френдли. У тебя нет переходов в зависимости от типа элемента. Тупые безусловные переходы, которые процессор просматривает на 100 команд вперед и затягивает в кэш инструкций.