Курилка программистов, Флуд на около программерские темы |
Здравствуйте, гость ( Авторизация | Регистрация )
Курилка программистов, Флуд на около программерские темы |
12.01.2021, 01:54
Сообщение
#381
|
|
Почти Мастер Репутация: 75 Группа: Участник Сообщений: 1168 Награды: 4 Регистрация: 10.11.2015 |
Команда есть в наборе SSE4.2, но её нет в SSE4A. Так что нету её у меня.
А вообще, говорилось реализация хэшей с помощью базовых наборов, х86 и АРМ. Так вот, АРМ рвёт х86 только так, в точности по скорости работы хэшей. Там где х86 3 инструкции использует, АРМ использует одну, и как правило на суперскалярных АРМах эта инструкция вычисляется за один такт. А х86 тем временем потратит 3 такта. И лишь благодаря волшебному слиянию команд, может выполнить код быстрей, но это только новые процессоры, вроде райзена. Т.е. происходит процедура замены этих команд на одну АРМ подобную. -------------------- СТАЛКЕР только для ПК!
|
 
|
|
|
|
12.01.2021, 02:24
Сообщение
#382
|
|
Игровое Воплощение Репутация: 394 Группа: Участник Сообщений: 4791 Награды: 4 Регистрация: 27.04.2011 |
NanoBot-AMK, а результаты арма есть или он рвет в теории?
Кроме того не очень понятно, зачем сравнивать современные армы с x86 двадцатилетней(а то и тридцатилетней) давности. Наверное да, современные армы должны быть эффективней старинных х86, но это не точно. Почему не сравнить нынешние армы хотя бы с десятилетним интелом? Цитата И лишь благодаря волшебному слиянию команд, может выполнить код быстрей, но это только новые процессоры, вроде райзена. У всех процессоров сейчас есть волшебное слияние. Ты же сам упоминал 3 операции за такт на арме. На х86 "слияние" появилось в пентиумах(1992г). С тех пор все х86 с "волшебным слиянием". |
 
|
|
12.01.2021, 20:29
Сообщение
#383
|
|
Почти Мастер Репутация: 75 Группа: Участник Сообщений: 1168 Награды: 4 Регистрация: 10.11.2015 |
По моим расчётом на hash MD5, ARM типа Cortex, должен тратить 4 такта на байт.
Тем временем современные процессоры х86 дают около 5 т/б, а мой как я говорил 6.36 т/б. Слияние могут только самые последние процы делать. Об этом Кошак упомянул, и при чем не так эффективно, как если бы код сразу в RISC код переделать. Сообщение отредактировал NanoBot-AMK - 12.01.2021, 21:28 -------------------- СТАЛКЕР только для ПК!
|
 
|
|
25.01.2021, 21:31
Сообщение
#384
|
|
Мастер Игры Репутация: 104 Группа: Участник Сообщений: 1331 Регистрация: 08.08.2018 |
Не хочу начать очередную
|
 
|
|
25.01.2021, 21:38
Сообщение
#385
|
|
Босс Репутация: 257 Группа: Участник Сообщений: 4151 Награды: 4 Регистрация: 15.08.2008 |
|
 
|
|
25.01.2021, 21:50
Сообщение
#386
|
|
Мастер Игры Репутация: 104 Группа: Участник Сообщений: 1331 Регистрация: 08.08.2018 |
|
 
|
|
25.01.2021, 22:30
Сообщение
#387
|
|
Босс Репутация: 257 Группа: Участник Сообщений: 4151 Награды: 4 Регистрация: 15.08.2008 |
|
 
|
|
25.01.2021, 22:42
Сообщение
#388
|
|
Игровое Воплощение Репутация: 394 Группа: Участник Сообщений: 4791 Награды: 4 Регистрация: 27.04.2011 |
Бенчмарки скриптовых языков:
|
 
|
|
25.01.2021, 22:54
Сообщение
#389
|
|
Доктор Игровых Наук Репутация: 544 Группа: Участник Сообщений: 3657 Награды: 9 Регистрация: 12.07.2007 |
Не хочу начать очередную срач дискуссию, но такой вопрос: чем JavaScript плох перед Lua при применении в играх? С точки зрения интеграции в движек lua лучше, он изначально для этого создан и весьма широко применяется. Хотя и с интеграцией js были вроде движки, как минимум помню игру crome но не помню там была java или javascript а это разные языки. Тут надо понимать принципиальные разницу. LUA был изначально придуман как нечто что интегрируется в другое приложение, и собственно там и застолбился. JS же изначально был уродцем который берет синтаксис Java который сильно в свое время всем зашел, но при этом типа без ниши как таковой, типа куда пойдет. Пошел он в веб, набрал критическую массу и сейчас изза этого костылями шагает назад в виде nodejs. К слову как человек пишущий на java иногда могу сказать что в ней есть встроенная поддержка ecmascript(js) в каждой версии, но ниразу не видел чтобы хоть гдето применялся на серьезных щщах. Не знаю. Как по мне, оба одинаково плохи. Не соглашусь, все в меру должно быть. Если в игре реализуют львиную долю логики в на скриптовых языках то это зло кровавое. Если это используют с умом, скажем используют чисто в квестах\катсценках и т.д. то это зачастую очень удобно для левелдизайнеров\квестописателей. Быстро въехали в язык и могут творить невероятные вещи. А вот когда в скрипты начинают тащить куски игры то это фейл в большинстве случаев, программисты движка страдают, дизайнеры страдают, все страдают и это всегда является тормозом разработки. |
 
|
|
25.01.2021, 23:43
Сообщение
#390
|
|
Босс Репутация: 257 Группа: Участник Сообщений: 4151 Награды: 4 Регистрация: 15.08.2008 |
Не хочу начать очередную срач дискуссию, но такой вопрос: чем JavaScript плох перед Lua при применении в играх? С точки зрения интеграции в движек lua лучше, он изначально для этого создан и весьма широко применяется. Хотя и с интеграцией js были вроде движки, как минимум помню игру crome но не помню там была java или javascript а это разные языки. Тут надо понимать принципиальные разницу. LUA был изначально придуман как нечто что интегрируется в другое приложение, и собственно там и застолбился. JS же изначально был уродцем который берет синтаксис Java который сильно в свое время всем зашел, но при этом типа без ниши как таковой, типа куда пойдет. Пошел он в веб, набрал критическую массу и сейчас изза этого костылями шагает назад в виде nodejs. К слову как человек пишущий на java иногда могу сказать что в ней есть встроенная поддержка ecmascript(js) в каждой версии, но ниразу не видел чтобы хоть гдето применялся на серьезных щщах. Не знаю. Как по мне, оба одинаково плохи. Не соглашусь, все в меру должно быть. Если в игре реализуют львиную долю логики в на скриптовых языках то это зло кровавое. Если это используют с умом, скажем используют чисто в квестах\катсценках и т.д. то это зачастую очень удобно для левелдизайнеров\квестописателей. Быстро въехали в язык и могут творить невероятные вещи. А вот когда в скрипты начинают тащить куски игры то это фейл в большинстве случаев, программисты движка страдают, дизайнеры страдают, все страдают и это всегда является тормозом разработки. Ну тут сыглы. Насчет быстро въехать - хз, лично мне сами по себе скриптовые языки нифига не проще компилируемых. А простота достигается за счет хорошего АПИ/библиотеки с кучей удобных и полезных готовых функций и классов. |
 
|
|
25.01.2021, 23:46
Сообщение
#391
|
|
Игровой Бог Репутация: 648 Группа: Участник Сообщений: 5354 Награды: 9 Регистрация: 24.09.2010 |
Каждый инструмент хорош для своей задачи. Говорить о том, хороша ли дин. типизация или плоха, это тоже самое что говорить о молотке и кувалде. Одно другое заменить не может.
-------------------- |
 
|
|
25.01.2021, 23:56
Сообщение
#392
|
|
Босс Репутация: 257 Группа: Участник Сообщений: 4151 Награды: 4 Регистрация: 15.08.2008 |
Каждый инструмент хорош для своей задачи. Говорить о том, хороша ли дин. типизация или плоха, это тоже самое что говорить о молотке и кувалде. Одно другое заменить не может. Так динамическая типизация - это и есть отсутствие инструментов под разные задачи. Сидишь как дурак и документируешь что в какой переменной лежит, или вобще забываешь и умножаешь уток на милиграммы. |
 
|
|
26.01.2021, 00:04
Сообщение
#393
|
|
Игровой Бог Репутация: 648 Группа: Участник Сообщений: 5354 Награды: 9 Регистрация: 24.09.2010 |
Так динамическая типизация - это экономия времени написания кода. А время деньги. Если нужно производительное решение, то берутся ЯП со статической типизацией. или вобще забываешь и умножаешь уток на милиграммы. Это проблема программиста, а не ЯП. Смысл переменных при статической типизации также требует документирования. Сообщение отредактировал RayTwitty - 26.01.2021, 00:07 -------------------- |
 
|
|
26.01.2021, 00:06
Сообщение
#394
|
|
Босс Репутация: 257 Группа: Участник Сообщений: 4151 Награды: 4 Регистрация: 15.08.2008 |
|
 
|
|
26.01.2021, 00:11
Сообщение
#395
|
|
Игровой Бог Репутация: 648 Группа: Участник Сообщений: 5354 Награды: 9 Регистрация: 24.09.2010 |
Сколько времени примерно экономится в процентах? Достаточно, чтобы люди для этого придумали больше 10-ка языков. -------------------- |
 
|
|
26.01.2021, 01:02
Сообщение
#396
|
|
. Репутация: 750 Группа: Участник Сообщений: 7072 Награды: 4 Регистрация: 30.07.2010 |
Не хочу начать очередную Вечнодерьмовые интерпретаторы. В нулевые годы они были либо кривыми (Mozilla, SpiderMonkey) либо закрытыми (Opera) либо кривыми и закрытыми (IE). Можно до сих пор скачать на сайте у мозиллы какие-нибудь древние spidermonkey типа 1.6 и испытать на своей шкуре. Потом кривизна немного пофиксилась, LUA напротив был стабилен уже очень давно, LuaJit тоже существует очень давно, и он не тяжеловесный. Никаких преимуществ JS перед луа как язык не имеет. Они вообще почти одинаковые, на самом деле, потому что JS был слизан с луа и отличается только синтаксисом. Короче всё понятно должно быть, почему. |
 
|
|
26.01.2021, 01:25
Сообщение
#397
|
|
Босс Репутация: 257 Группа: Участник Сообщений: 4151 Награды: 4 Регистрация: 15.08.2008 |
|
 
|
|
26.01.2021, 01:41
Сообщение
#398
|
|
. Репутация: 750 Группа: Участник Сообщений: 7072 Награды: 4 Регистрация: 30.07.2010 |
Так динамическая типизация - это и есть отсутствие инструментов под разные задачи. Сидишь как дурак и документируешь что в какой переменной лежит, или вобще забываешь и умножаешь уток на милиграммы. Динамическая типизация - это как раз самый главный инструмент под разные задачи. В реальных программах большинство данных хранится в структурах и контейнерах, а не стековых переменных. И вот тут уже здорово упрощаются многие задачи. К примеру если тебе нужна функция которая выводит в лог структуру в виде строки, тебе в JS понадобится одна универсальная функция, которая принимает любой объект, перебирает все поля объекта и записывает в виде строки. В статических языках тебе понадобится для каждого типа(структуры) писать отдельную функцию, а типов могут быть тысячи. Контейнеры это вообще отдельная песня. Без динамической типизации они выливаются либо в кучи небезопасных кастов, как например в делфи TList*, либо в особо дурацких языках таких как C++ в шаблоны, которые ведут к ужасному code-bloat, если у тебя в проекте 10 DLL, и в каждой из них используется std::vector<int>, код его реализации будет содержаться в каждой ДЛЛ, и не надо петь что это совсем немного и оперативной памяти у тебя достаточно, нерезиновые кеши у процессоров никуда не делись до сих пор. Кроме этого, шаблоны ещё увеличивают время компиляции, вплоть даже до нескольких часов, если проект большой. У программеров тогды возникает желание это время экономить, они вкручивают луа с динамической типизацией который компилируется на лету при запуске программы и выносят туда весь некритичный к производительности код... Ну ты понел. Бывали ещё языки которые совмещали динамическую и статическую типизацию, например ActionScript, но чёт не взлетело. Вот даже ты флеш не любишь. Остался только TypeScript от корпорации майкрософт, это такой ActionScript, который компилируется в JavaScript без ограничений, и сводит на нет всю пользу от своей строготипости. * Ради великой справедливости, в делфи уже тоже шаблоны добавили, только они не шаблоны, а дженерики, но эт не важно. |
 
|
|
26.01.2021, 07:19
Сообщение
#399
|
|
Доктор Игровых Наук Репутация: 544 Группа: Участник Сообщений: 3657 Награды: 9 Регистрация: 12.07.2007 |
Ну тут сыглы. Насчет быстро въехать - хз, лично мне сами по себе скриптовые языки нифига не проще компилируемых. А простота достигается за счет хорошего АПИ/библиотеки с кучей удобных и полезных готовых функций и классов. Тут вопрос в сторонних людях. Вот пишешь ты свой двиг, и ты хоть 1000 раз обмажся красивым и удобным api но не сможешь заставить этим пользоваться левелдизайнера. А вот тот же Lua который ты подключишь и вынесешь только нужные api и задокументируешь изучиться буквально за вечер, максимум два. В любом случае это тоже в какомто роде костыль т.к. ты как разработчик движка должен был сделать удобный инструментарий вместо скриптов. Взять для примера двиг goldsrc\source\квековские шде для левелдизайнеров\мапперов инструмент в виде IO между сущностями. Это очень удобно, пока не перерастает в сложные скрипты и тогда это уже проблема. Был бы именно скриптовый язык типа js\lua\angelscript то такие штуки были бы в разы проще. Короче, нужна золотая середина. |
 
|
|
26.01.2021, 11:22
Сообщение
#400
|
|
Игровое Воплощение Репутация: 394 Группа: Участник Сообщений: 4791 Награды: 4 Регистрация: 27.04.2011 |
код его реализации будет содержаться в каждой ДЛЛ, и не надо петь что это совсем немного и оперативной памяти у тебя достаточно, нерезиновые кеши у процессоров никуда не делись до сих пор. Так это разные кеши же: кеша данных и кеша инструкций. И как раз 10 копий стдвектора это кэшфрендли. Код, использующий вектор, и код самого вектора лежат рядышком и в кэше. Процессор все инструкции достает из кэша, а не мотается по всей памяти при вызовах методов вектора Шаблонность(дженеричность) - это предсказатель переходов-френдли. У тебя нет переходов в зависимости от типа элемента. Тупые безусловные переходы, которые процессор просматривает на 100 команд вперед и затягивает в кэш инструкций. |
 
|
|
Текстовая версия | Сейчас: 08.05.2024, 06:06 |