DioD
offline
Опыт:
45,134Активность: |
если бы это было сделано изначально на глобалке вам непришлось бы думать об этом, ток что всё гуд. Продолжайте думать |
12.01.2007, 11:01 | #41
+0/−0
Профиль |
Приват |
Поиск |
Цитата |
IP: Записан
|
nic666
offline
Опыт:
5,612Активность: |
Однако... пусть изначально все на кеше и переделывать много, но никто ведь не запрещает отказаться от чтения из него хотя бы.
1) убрать чтение из CFG_I Код:
2) вставить дублирование вконце функции Код:
3) Далее если кеш сохраняется в файл, то по событию Game Load прийдется поставить затычку Код:
Это будет значительно быстрее работать...... разве не очевидно? nic666 добавил: В добавок к сказанному и запись можно уменьшить например так Код:
|
12.01.2007, 11:39 | #42
+0/−0
Профиль |
Приват |
Поиск |
Цитата |
IP: Записан
|
p01nTT
offline
Опыт:
11,160Активность: |
юзаем WEHelper + jass helper
создаем триггер и пишем в нём globals integer array time (или 3 глобалки sec,min и hour) endglobals |
12.01.2007, 15:36 | #43
+0/−0
Профиль |
Приват |
Поиск |
Цитата |
IP: Записан
|
dk
offline
Опыт:
60,293Активность: |
Короче мой вариант, заместо кфг юзаем обычные глобалки. Три переменных udg_Seconds, udg_Minutes, udg_Hours целочисленные естественно...
Код:
|
12.01.2007, 17:50 | #44
+0/−0
Профиль |
Приват |
Поиск |
Цитата |
IP: Записан
|
zibada
offline
Опыт: отключен
|
Цитата:
бред, причем полный. вот из-за таких утверждений и получаются недо-"профи", для которых "кэш" - едва ли не матерное слово.. хотя ассоциативный массив на хэш-таблицах - это совершенно базовая структура данных во многих популярных интерпретируемых языках (perl, php, javascript, ...). (причем то, что называется "глобалки" - обычно есть не более чем записи в таком же массиве) то, что в жассе это реализовано не на уровне синтаксиса ( set arr["hello"] = "preved"), а через набор функций, принципиально мало что меняет. насчет "скорость работы зависит от заполненности"... значительно тормозить может только добавление записи при большом их количестве, но не апдейт старой записи - об этом я писал, и подтверждающие тесты прикладывал. ежели не веришь так - марш в гугл по словам "хэш-таблица"... виной 99% всех тормозов являются корявые алгоритмы и ничего более. просто задолбало уже читать эту бредовню, копируемую из поста в пост без каких-либо подтверждений... |
|
12.01.2007, 21:25 | #45
+0/−0
Профиль |
Приват |
Поиск |
Цитата |
IP: Записан
|
nic666
offline
Опыт:
5,612Активность: |
!
Уважаемый, когда Intel встроит в процессор архитектуру оптимизированную под кеш, который сродни допотомному INI файлу версии Windows 1.05 - вот тогда он будет оптимальнейшей структурой среди INTEL процессоров, и ни среди каких либо иных. Вы ожидаете от меня подтверждающих тестов? На предмет 1) он и работает в 10-100 раз медленее чем массивы и глобалки 2) скорость работы зависит от заполненности Я готов их для вас сделать. Только имейте ввиду, что это не так просто, как те тесты что вы прилагали, так как несколько последних значений чтения/записи в кеш - кешируются в скрытых глобальных переменных, вот если бы вы пробовали случайные выборки, то вы бы и сами пришли бы к тому же выводу... |
13.01.2007, 00:07 | #46
+0/−0
Профиль |
Приват |
Поиск |
Цитата |
IP: Записан
|
exAres
I love magic :)
offline
Опыт:
7,788Активность: |
nic666 - кеш конечно-же медленнее чем массивы и глобалки это само-собой и тем более если им "очень часто" пользоватся, но в некоторых случаях его использование очень удобное, например передача информации через хендл, это конечно-же можно сделать и с помощью массивов но не думаю что это будет работать быстрее чем кеш. Конечно с кешем бывают другие глюки типа перезаписи - но это только в случае если за этим не следить (читать запись с удалённого юнита и т.п. но это глюки даже не кеша а варкрафта, бывают также глюки и с РБ функциями но это уже другая история). Ну и в общем кеш достаточно полезная вещь!
|
13.01.2007, 00:35 | #47
+0/−0
Профиль |
Приват |
Поиск |
Цитата |
IP: Записан
|
zibada
offline
Опыт: отключен
|
если бы у нас было нечто компилируемое - да, тут вопросов нет.
но у нас-то не тот случай. насчет глобалок я не уверен, но допустим, имена функций - это явно аналогичная кэшу структура (иначе бы не было, например, такой вещи, как ExecuteFunc). а насчет 10 раз - для простого сравнения (set i = udg_global[a]) и (set i = GetStoredInteger(...)) это может и выполняться, за счет лишнего вызова функции, а вот как только дело переходит к реальным задачам (самое тупое: привязать параметр к конкретному юниту) начинается изобретение всяких велосипедов, т.е. что-то типа (set i = GetData(u, ...), а GetData уже лазает в нужный массив, попутно еще пару функций вызывая, например custom value у юнита считать).
и все эти "10 раз" 20 раз теряются за счет всех этих "оберток". еще один, приближенный к реальности пример: в ходе ковыряния в одной известной в узких кругах карте (клон доты), где была довольно навернутая система хранения всего и вся в массивах, в ходе расшифрования тамошних данных я взял, да и заменил все это на обращения через кэш...
разница в скорости, если и есть, то на глаз незаметна вообще, хотя там под несколько тысяч записей вроде было. мапа валяется где-то на форуме. так стоит ли конструировать велосипеды? или каждому инструменту - свое место?
а пример давай - может быть, я в каком-то месте и не прав, но куда лучше фактические подтверждения, а не болтовня.. |
13.01.2007, 00:44 | #48
+0/−0
Профиль |
Приват |
Поиск |
Цитата |
IP: Записан
|
DioD
offline
Опыт:
45,134Активность: |
Скорость кеша и глобалок при записи раз в секунду одинакова...
Даже не знаю какой такой пример можно будет показать. |
13.01.2007, 01:18 | #49
+0/−0
Профиль |
Приват |
Поиск |
Цитата |
IP: Записан
|
nic666
offline
Опыт:
5,612Активность: |
DioD обратите внимание на заявление !:
Цитата:
Сдедовательно хочу вас спросить, какие ассоциации у вас возникают с 38 секундами? или 39 секундами? и т.д. Совершенно очевидно, что никаких. Следовательно, можете ли вы утверждать, что кеш - это хорошая идея для такой Задачи№1 ??? "Скорость кеша и глобалок при записи раз в секунду одинакова..." то есть скорость черепахи и скакуна одинакова при прохождении одного сантиметра? Возможно... но ведь игра обычно длится не секунду. Считайте, что то время которое обусловлено разницей скорости - украли у игроков, думаю за всю игру это будет несколько минут, а может десятков... могли бы это время занять чем то более интересным, чем торможение кеша :) nic666 добавил: MrSmiLe А я разве говорил что кеш "вредная вещь"? НЕт! Многие задачи без кеша и решить на порядок труднее... Кеш вешь полезнейшая. Вот только у каждой вещи своя область применения... вы же не забиваете калькулятором гвозди? И "ассоциативный массив" должен применяться, если есть соответствие со строкой, заранее не определенной структуры - не приводимой к числу. Если же речь только о числах, то кеш это плохая идея. А в таком случае, очень плохая идея: Код:
|
|
13.01.2007, 10:38 | #50
+0/−0
Профиль |
Приват |
Поиск |
Цитата |
IP: Записан
|
herr_horror
Фиолетовый андроид
offline
Опыт:
139Активность: |
Цитата:
Скорость раз в секунду одинакова у чего угодно! Раз в секунду я ковыряюсь в носу, раз в секунду я пишу в кеш.) Итак, ситуация прямо как на картине "Боярыня Морозова": стороны разделились на два лагеря - кешевиков и глобалщиков. Я знаю одно: ассоциативный массив подразумевает бинарный поиск, а по времени (итерациям) - это логарифмическая функция. С другой стороны я знаю, как, например, в языках типа php - работа со всеми массивами ведется как с хешем, видимо, разработчики php посчитали несущественным разницу - что же нам готовят близардовцы? Ну что, предлагаю написать тесты. а) Во всех тестах число заполненных ячеек одинаково и равно, ну путь тыщ восемь. (сколько разрешается писать? Какова размерность - я не в курсе просто) засекаем время чтения б) прогоним тесты по выборке с первого элемента по последний в) прогоним тесты с выборкой случайного элемента г) длину ассоциативного индекса в одном случае стараемся делать как можно меньше - ну пусть те же самые значения. что для массива д) .. в других - символов десять, двадцать, и как можно больше. (Г, Д) - проверят наше предположение, что близардовцы взяли алгоритм бинарного поиска. Суть нашего эксперимента - найти среднее время чтения их глобалки и кеша. Скорость доступа к глобалке будет больше, но почти наверняка можно сказать, что при большой интенсивности использования данных не спасет ни то ни другое - тормозить будет почти одинакого. Давайте разберемся с тестами. У кого какие предложения будут? |
|
13.01.2007, 10:38 | #51
+0/−0
Профиль |
Приват |
Поиск |
Цитата |
IP: Записан
|
nic666
offline
Опыт:
5,612Активность: |
!
Цитата:
Именно так! 100% согласен. nic666 добавил: herr_horror не против сделать тесты. Единственная коррктива: Время отмерять нечем... 1) оно в игре относительно 2) сами отдельные операции занимают слишком мало времени и нет инструмента для измерения миллисекунд Предлагаю поступить наоборот: засекать например 3 минуты на каждый тест и смотреть число выполненных операций за это время. |
|
13.01.2007, 10:46 | #52
+0/−0
Профиль |
Приват |
Поиск |
Цитата |
IP: Записан
|
herr_horror
Фиолетовый андроид
offline
Опыт:
139Активность: |
Из стандартного да...
Придется считать итерации. Но мы бы не были армянскими комсомольцами, если бы не делали себе трудностей Но можно сделать, например, так... как вам идея..
Берем периодически срабатываемый таймер - у него можно настроить время срабатывания в миллисекундах.
call TimerStart (ЧТО_ЗА_ТАЙМЕР, ВРЕМЯ, true, function ИТЕРАЦИЯ_ТАЙМЕРА )
параметр ВРЕМЯ можно было ставить в сотых, наверняка и в тысячных можно ставить.
Таким образом, засекаемое время будет отмеряться в миллисекундах+ время на вход в процедуру таймера+время на выход.
Параллельно контролируем время дедовскими методами, близардосвким секундомером.
Получится интересная формула: ВРЕМЯ_В_СЕКУНДАХ = N_обращений * (ВРЕМЯ_ТАЙМЕРА + ВРЕМЯ_НА_ОБРАБОТКУ_ФУНКЦИИ_ТАЙМЕРА)
Откуда мы вычислим время, затрачиваемое на использование таймера и далее эксперимент ведем уже не пренебрегая этим временем, но имея аппарат для более точной засечки времени. |
13.01.2007, 11:03 | #53
+0/−0
Профиль |
Приват |
Поиск |
Цитата |
IP: Записан
|
zibada
offline
Опыт: отключен
|
Цитата:
нет.... это не двоичное дерево, а хэш-таблица. ну то есть это тот же массив, только индекс не предоставляется непосредственно, а вычисляется как некоторая функция от строки, вот и вся разница. амортизированная оценка (да почитайте что-нибудь по алгоритмам, что ли, перед тем, как спорить... хотя бы в википедии) - O(1) по всем операциям (тестами это подтверждается), и хоть эта константа, возможно, похуже, чем у обращения к глобалкам, вопрос-то в том - насколько существенно? с чего взято утверждение, что запись (udg_global[a]) - это "прямой доступ к памяти", а не неявное обращение к аналогичной таблице? во-первых, например, в упомянутых интерпретируемых языках (а жасс тоже интерпретируемый) это в принципе неверное утверждение (потому там и нет глубокой разницы - числовые или строковые индексы использовать), во-вторых, в таком случае тормоза были бы не в 10, и не в 100, а в 1000 раз сильнее, причем на ВСЕХ операциях, чего на практике не наблюдается. вот только давайте действительно не препираться из-за ерунды, и уж тем более не разбиваться на "остроконечников" с "тупоконечниками" =) а действительно стоит что-то протестировать, дабы понять, насколько задержки сильнее, и, как следствие, для каких задач этим можно просто пренебречь... Отредактировано !, 13.01.2007 в 12:01. |
|
13.01.2007, 11:35 | #54
+0/−0
Профиль |
Приват |
Поиск |
Цитата |
IP: Записан
|
herr_horror
Фиолетовый андроид
offline
Опыт:
139Активность: |
Знаешь, а ведь переубедил! +1
Сам даже не помню, откуда взялось заблуждение с логарифмической функцией.
Какие-то обрывки знаний наводят на книгу вроде Г. Шилда Теория и практика программирования, хотя хз, но ведь, это если самим делать бинарный поиск. А сами мы его не делаем! С хеш-функциями все обстоит именно как с массивами! Существуют много хеш-преобразований, и, кстати CRC32 - практически одно из них!
Попробую сформулировать в чем все-таки была загвоздка в нашем общем споре.
Хеш-функция делает отображение значения Х в индекс массива А. Во внутреннем представлении - это все тот же массив (!!!). Но! Существует коллизия хеш-функций, когда мощность отображаемого множества больше мощности множества индексов А, то есть количества индексов массива во внутреннем представлении. В этом случае, появляются лишние две, три..N итерации, на фильтрацию мусорных значений.
Попробую подвести итоги, которые можно было подвести в первом посте):
если, близардовцы нормально все сделали - такая функция существует и все наши споры бессмысленны - парой лишних операторов на поиск можно пренебречь. Если они такую функцию делали руками, перебором или еще там чем, дерево строили.. то я боюсь даже предположить... Если ! утверждает, что разницы не почувствовал, почему бы ему не поверить. А пока завяжем узелок на память, при случае выяснить, как же реализована работа с хешем у близардовцев.) |
13.01.2007, 15:59 | #55
+0/−0
Профиль |
Приват |
Поиск |
Цитата |
IP: Записан
|
0pJl9lTa
offline
Опыт:
3,397Активность: |
Код на перфой странице наипростейшей, так что в оптимизации нет смысла...
0pJl9lTa добавил: Гаспада, совсем не то думаете.... Кстати, задача поставлена неправильно... |
13.01.2007, 19:49 | #56
+0/−0
Профиль |
Приват |
Поиск |
Цитата |
IP: Записан
|
DioD
offline
Опыт:
45,134Активность: |
поставь задачу правильно тогда...
тут полная интерактивность, суть втом что каждый делает то что он может и как он может, результат работы по разному плану различен, так что ответов будет как минимум 2 |
14.01.2007, 07:05 | #57
+0/−0
Профиль |
Приват |
Поиск |
Цитата |
IP: Записан
|
dk
offline
Опыт:
60,293Активность: |
Ну так и когда ты представишь
|
14.01.2007, 07:09 | #58
+0/−0
Профиль |
Приват |
Поиск |
Цитата |
IP: Записан
|
DioD
offline
Опыт:
45,134Активность: |
еще не все, так что потерпите малость. |
14.01.2007, 07:38 | #59
+0/−0
Профиль |
Приват |
Поиск |
Цитата |
IP: Записан
|
0pJl9lTa
offline
Опыт:
3,397Активность: |
Правильно нуна было сказть так.
Задача: Сделать функцию в результате выполнения которой вы получаете запись типа 00:00:00, где каждая цифорка это часы\минуты\секунды. Далее даешь свой код, и моришь кто сделает лучше, а не оптимизирует твой. Свой сам оптимизируй :-P |
14.01.2007, 11:34 | #60
+0/−0
Профиль |
Приват |
Поиск |
Цитата |
IP: Записан
|