Re[2]: OFF: Разгон машины тьюринга :)))
Привет! Это публичная конференция, тут каждый сам решает - присоединяться к ветке или нет. :) Просто Ваша задача существенно превосходит мой уровень - решил немного самообразованием заняться :) Нифига, тут есть товарищи, которые курят куда более тяжелую траву :)) order by 2 desc - сортировка по второму полю (количество ключевых Сначала так и подумал, потом усомнился - ведь Вы же количество считаете и к оптимизации стремитесь. Начали мелкать мысли по поводу sort-buffer и cursor stability - и под конец совсем запутался :) Правильно. Но я исходил из того соображения, что количество записей в виртуальной таблице, с которой происходит объединение - несравнимо мало, по сравнению с таблицей текстовых индексов - там ну от силы десяток записей, а в индексах - 12 миллионов. Так что натурал по rdb$database - это ну никак не тормоза. Вот натурал по индексной таблице - это жжж.. :) Правильно. Но первый вариант мне почему-то нравится больше и order by 2 desc тут не смотрится Да, действительно. Я предположил, что может быть некоторое различие в быстродействии между отбором через where во внешнем запросе и having в derived table, не отражаемое в плане - было бы интересно узнать, не домыслы ли это. Вот тут надо к поставщикам тяжелых... медпрепаратов обратиться - к Димам, Владу или Алексу :) Если они будут не заняты - мне тоже было бы интересно узнать ответ. Хотя по логике - зачем серверу врать и делать что-то, не отраженное в плане? Запрос с IN(), как я показал - в моем случае тормознутее :)) План PLAN JOIN (SORT (IDX W ORDER FK_T_SEARCH_WORDS_1 INDEX (T_SEARCH_WORDS_IDX1, T_SEARCH_WORDS_IDX1, T_SEARCH_WORDS_IDX1)), D INDEX (PK_T_DOCUMENTS)) В этом случае и отбор записей, и сортировка идут по индексу - насколько я помню, это нехорошо. Эта проблема недавно здесь обсуждалась - ветка странное время выполнения запроса от Kochmin Alexandr. Ну то обсуждение я видел, но прокомментировать не могу. Так вот интересно, если убрать сортировку по индексу, то сможет ли этот вариант конкурировать с остальными двумя? А как ее убрать? Рулить хинтом оптимизатору +0, как в твоем запросе? О результатах - ниже. ;-) select count(1) from t_documents d, (select w.document_id+0 from t_search_words w where w.lang_id=2 and w.flag=1 and w.word in (2624961196, 1902388292, 1228066714) group by 1 having Count(1) = 3) idx where d.lang_id=2 and d.published_when='01.07.2002' and d.published_when='02.07.2007' and d.publisher_id =36149 and d.id=idx.document_id Если интересно, просьба сравнить в быстродействии. Слегка переделанный запрос (только имена полей добавил, чтобы сервер не ругался, тоже результат третьего исполнения): select count(1) as cnt from t_documents d, (select w.document_id+0 as doc_id from t_search_words w where w.lang_id=2 and w.flag=1 and w.word in (2624961196, 1902388292, 1228066714) group by 1 having Count(1) = 3) idx where d.lang_id=2 and d.published_when='01.07.2002' and d.published_when='02.07.2007' and d.publisher_id =36149 and d.id=idx.doc_id Plan PLAN JOIN (SORT (IDX W INDEX (T_SEARCH_WORDS_IDX1, T_SEARCH_WORDS_IDX1, T_SEARCH_WORDS_IDX1)), D INDEX (PK_T_DOCUMENTS)) Adapted Plan PLAN JOIN (SORT (IDX W INDEX (T_SEARCH_WORDS_IDX1, T_SEARCH_WORDS_IDX1, T_SEARCH_WORDS_IDX1)), D INDEX (PK_T_DOCUMENTS)) Prepare time = 203ms Execute time = 780ms Avg fetch time = 780,00 ms Current memory = 67 378 548 Max memory = 78 021 200 Memory buffers = 4 000 Reads from disk to cache = 11 335 Writes from cache to disk = 0 Fetches from cache = 73 914 Т.е. ничем по сути не лучше - большее время запроса на пару мс не считается, так как сейчас сервер реиндексирует базу с обновленным словарем. Я тут другую хрень обнаружил - об этом в соседней ветке. -- Best regards, Sergeymailto:[EMAIL PROTECTED]
Re: OFF: Разгон машины тьюринга :)))
Sergey Mereutsa wrote: Да, действительно. Я предположил, что может быть некоторое различие в быстродействии между отбором через where во внешнем запросе и having в derived table, не отражаемое в плане - было бы интересно узнать, не домыслы ли это. Вот тут надо к поставщикам тяжелых... медпрепаратов обратиться - к Димам, Владу или Алексу :) Если они будут не заняты - мне тоже было бы интересно узнать ответ. Не должно быть разницы, это ведь по большому счету одно и то же. ЗЫ. Насколько я помню, в природе есть только одна операция, не отражаемая в плане. Это DISTINCT внутри агрегатной функции. Там сортировка выполняется для каждой группы отдельно (для устранения дубликатов). -- Дмитрий Еманов
Re: OFF: Разгон машины тьюринга :)))
Доброго времени суток! Sergey Mereutsa wrote: Нифига, тут есть товарищи, которые курят куда более тяжелую траву :)) За полетом их мысли я даже следить не пытаюсь :) Правильно. Но я исходил из того соображения, что количество записей в виртуальной таблице, с которой происходит объединение - несравнимо мало, по сравнению с таблицей текстовых индексов - там ну от силы десяток записей, а в индексах - 12 миллионов. Так что натурал по rdb$database - это ну никак не тормоза. Вот натурал по индексной таблице - это жжж.. :) Да, виртуальная таблица - несомненно, красивое решение. Но я имел в виду то, что order by 2 desc добавляет лишний SORT в план Или результат объединения - всего лишь несколько записей, и SORT здесь на быстродействие не повлияет? Да, действительно. Я предположил, что может быть некоторое различие в быстродействии между отбором через where во внешнем запросе и having в derived table, не отражаемое в плане - было бы интересно узнать, не домыслы ли это. Вот тут надо к поставщикам тяжелых... медпрепаратов обратиться - к Димам, Владу или Алексу :) Если они будут не заняты - мне тоже было бы интересно узнать ответ. Хотя по логике - зачем серверу врать и делать что-то, не отраженное в плане? Было у меня смутное воспоминание, что какие-то операции в плане не учитывались - видимо та, о которой говорил Дмитрий. В этом случае и отбор записей, и сортировка идут по индексу - насколько я помню, это нехорошо. Эта проблема недавно здесь обсуждалась - ветка странное время выполнения запроса от Kochmin Alexandr. Ну то обсуждение я видел, но прокомментировать не могу. Собственно, теоретическое обоснование приводил Д. Кузьменко (см ссылку в его посте от 03.07.2007 11:43). Так вот интересно, если убрать сортировку по индексу, то сможет ли этот вариант конкурировать с остальными двумя? А как ее убрать? Рулить хинтом оптимизатору +0, как в твоем запросе? Ну да. Альтернатива для эстетов - cross join rdb$database :) Слегка переделанный запрос (только имена полей добавил, чтобы сервер не ругался, тоже результат третьего исполнения): Спасибо! Prepare time = 203ms Execute time = 780ms Avg fetch time = 780,00 ms Current memory = 67 378 548 Max memory = 78 021 200 Memory buffers = 4 000 Reads from disk to cache = 11 335 Writes from cache to disk = 0 Fetches from cache = 73 914 Т.е. ничем по сути не лучше - большее время запроса на пару мс не считается, так как сейчас сервер реиндексирует базу с обновленным словарем. Ну количество чтений с диска все же поменьше, так что есть шанс, что он обскачет Ваш первоначальный вариант :) Кстати, что касается оптимизации запросов. Правильно ли я понимаю, что Reads from disk характеризуют нагрузку на дисковую подсистему, а Fetches from cache - на память и процессор? Можно ли с уверенностью предсказать Execute time (или хотя бы ранжировать их) на незанятом сервере, зная эти параметры? В Вашем случае имеем Ваш I II Iopt Execute time =764ms 2s 886ms624msX Reads from disk to cache =17 54215 229 8 801 11 335 Fetches from cache = 73 78793 782 133 848 73 914 Думается все же, что X 764, хотя зависимость неясна. Интересно, сможет ли Iopt соперничать с II вариантом Влада Хорсуна при возрастании числа ключевых слов? С уважением, Евгений.
Re: OFF: Разгон машины тьюринга :)))
Доброго времени суток! Dmitry Yemanov wrote: Не должно быть разницы, это ведь по большому счету одно и то же. ЗЫ. Насколько я помню, в природе есть только одна операция, не отражаемая в плане. Это DISTINCT внутри агрегатной функции. Там сортировка выполняется для каждой группы отдельно (для устранения дубликатов). Значит, я таки стормозил. Спасибо за внесение ясности. С уважением, Евгений.
Re: OFF: Разгон машины тьюринга :)))
Здравствуйте, Сергей! Sergey Mereutsa wrote: Подсчет количества найденных документов (ну вот захотелось им такую фичу и все): select count(d.id) from t_documents d, (select w.document_id, count(1) as cnt from t_search_words w, ( select 2624961196 as wrd from rdb$database union select 1902388292 as wrd from rdb$database union select 1228066714 as wrd from rdb$database ) t1 where w.lang_id=2 and w.flag=1 and w.word=t1.wrd group by 1 order by 2 desc ) idx where d.lang_id=2 and d.published_when='01.07.2002' and d.published_when='02.07.2007' and d.publisher_id =36149 and d.id=idx.document_id and idx.cnt=3 Извините, что влезаю, но никак не могу понять, зачем order by 2 desc в idx? Правильно ли я понимаю, что Ваш запрос эквивалентен следующему: select count(1) from t_documents d, (select w.document_id from t_search_words w, ( select 2624961196 as wrd from rdb$database union select 1902388292 as wrd from rdb$database union select 1228066714 as wrd from rdb$database ) t1 where w.lang_id=2 and w.flag=1 and w.word=t1.wrd group by 1 Having Count(1) = 3 ) idx where d.lang_id = 2 and d.published_when = '01.07.2002' and d.published_when = '02.07.2007' and d.publisher_id = 36149 and d.id = idx.document_id ? или, если взять за основу вариант Влада Хорсуна, select count(1) from t_documents d, (select w.document_id from t_search_words w cross join rdb$database where w.lang_id=2 and w.flag=1 and w.word in (2624961196, 1902388292, 1228066714) group by 1 having Count(1) = 3) idx where d.lang_id=2 and d.published_when='01.07.2002' and d.published_when='02.07.2007' and d.publisher_id =36149 and d.id=idx.document_id ? С уважением, Евгений.
Re[2]: OFF: Разгон машины тьюринга :)))
Привет! select count(d.id) from t_documents d, (select w.document_id, count(1) as cnt from t_search_words w, ( select 2624961196 as wrd from rdb$database union select 1902388292 as wrd from rdb$database union select 1228066714 as wrd from rdb$database ) t1 where w.lang_id=2 and w.flag=1 and w.word=t1.wrd group by 1 order by 2 desc ) idx where d.lang_id=2 and d.published_when='01.07.2002' and d.published_when='02.07.2007' and d.publisher_id =36149 and d.id=idx.document_id and idx.cnt=3 Извините, что влезаю, Это публичная конференция, тут каждый сам решает - присоединяться к ветке или нет. :) но никак не могу понять, зачем order by 2 desc в idx? order by 2 desc - сортировка по второму полю (количество ключевых слов, найденных в документе). Это общая конструкция - на нее может, а может и не, накладываться условие отсечения and cnt=3 (3 - это количество ключевых слов в данном случае). Грубо (абсолютно не точно) - это сортировка по релевантности - т.е. документы, в которых встречаются 3 из 3-х слов идут первыми, затем те, в которых 2 из 3 и т.д. У гугла понятие релевантности отличается - как и у яндекса. Правильно ли я понимаю, что Ваш запрос эквивалентен следующему: select count(1) from t_documents d, (select w.document_id from t_search_words w, ( select 2624961196 as wrd from rdb$database union select 1902388292 as wrd from rdb$database union select 1228066714 as wrd from rdb$database ) t1 where w.lang_id=2 and w.flag=1 and w.word=t1.wrd group by 1 Having Count(1) = 3 ) idx where d.lang_id = 2 and d.published_when = '01.07.2002' and d.published_when = '02.07.2007' and d.publisher_id = 36149 and d.id = idx.document_id ? Правильно. Но первый вариант мне почему-то нравится больше и order by 2 desc тут не смотрится :) или, если взять за основу вариант Влада Хорсуна, select count(1) from t_documents d, (select w.document_id from t_search_words w cross join rdb$database where w.lang_id=2 and w.flag=1 and w.word in (2624961196, 1902388292, 1228066714) group by 1 having Count(1) = 3) idx where d.lang_id=2 and d.published_when='01.07.2002' and d.published_when='02.07.2007' and d.publisher_id =36149 and d.id=idx.document_id ? Запрос с IN(), как я показал - в моем случае тормознутее :)) -- Best regards, Sergeymailto:[EMAIL PROTECTED]
Re: OFF: Разгон машины тьюринга :)))
Доброго времени суток! Sergey Mereutsa wrote: Это публичная конференция, тут каждый сам решает - присоединяться к ветке или нет. :) Просто Ваша задача существенно превосходит мой уровень - решил немного самообразованием заняться :) order by 2 desc - сортировка по второму полю (количество ключевых слов, найденных в документе). Это общая конструкция - на нее может, а может и не, накладываться условие отсечения and cnt=3 (3 - это количество ключевых слов в данном случае). Грубо (абсолютно не точно) - это сортировка по релевантности - т.е. документы, в которых встречаются 3 из 3-х слов идут первыми, затем те, в которых 2 из 3 и т.д. У гугла понятие релевантности отличается - как и у яндекса. Сначала так и подумал, потом усомнился - ведь Вы же количество считаете и к оптимизации стремитесь. Начали мелкать мысли по поводу sort-buffer и cursor stability - и под конец совсем запутался :) Правильно. Но первый вариант мне почему-то нравится больше и order by 2 desc тут не смотрится Да, действительно. Я предположил, что может быть некоторое различие в быстродействии между отбором через where во внешнем запросе и having в derived table, не отражаемое в плане - было бы интересно узнать, не домыслы ли это. или, если взять за основу вариант Влада Хорсуна, select count(1) from t_documents d, (select w.document_id from t_search_words w cross join rdb$database where w.lang_id=2 and w.flag=1 and w.word in (2624961196, 1902388292, 1228066714) group by 1 having Count(1) = 3) idx where d.lang_id=2 and d.published_when='01.07.2002' and d.published_when='02.07.2007' and d.publisher_id =36149 and d.id=idx.document_id ? Запрос с IN(), как я показал - в моем случае тормознутее :)) План PLAN JOIN (SORT (IDX W ORDER FK_T_SEARCH_WORDS_1 INDEX (T_SEARCH_WORDS_IDX1, T_SEARCH_WORDS_IDX1, T_SEARCH_WORDS_IDX1)), D INDEX (PK_T_DOCUMENTS)) В этом случае и отбор записей, и сортировка идут по индексу - насколько я помню, это нехорошо. Эта проблема недавно здесь обсуждалась - ветка странное время выполнения запроса от Kochmin Alexandr. Так вот интересно, если убрать сортировку по индексу, то сможет ли этот вариант конкурировать с остальными двумя? Собственно, я стормозил - несмотря на RN, решил что группировки по выражениям нету. Начал думать, как вырубить ORDER FK_T_SEARCH_WORDS_1 и додумался до такого извращения, как cross join с rdb$database. Вариант должен быть таким select count(1) from t_documents d, (select w.document_id+0 from t_search_words w where w.lang_id=2 and w.flag=1 and w.word in (2624961196, 1902388292, 1228066714) group by 1 having Count(1) = 3) idx where d.lang_id=2 and d.published_when='01.07.2002' and d.published_when='02.07.2007' and d.publisher_id =36149 and d.id=idx.document_id Если интересно, просьба сравнить в быстродействии. Спасибо! С уважением, Евгений.
Re: OFF: Разгон машины тьюринга :)))
Alexander V. Skvortsov ... Dmitri Kuzmenko ... делала, а RELEASE со всеми оптимизациями по скорости - результат в разы быстрее! ;-). Приложение по прежнему однопоточное, гипертрединг по прежнему включён. Загрузка выше 52% не поднимается. :-) И что из этого ? с гипертредингом-то - разумеется. Он же показывает одно ядро как 2 ядра, а на самом деле их ... эээ... где-то в сумме полтора, если не меньше. 1.25 примерно :-) Фазу сортировки можно подсократить, загрузив второе ядро ещё одним потоком, который, пока 1-й сортирует, будет подгружать очередной кусок данных и сортировать его. Придётся только сериализовать чтение входного файла - выходной файл для каждого куска свой. Процентов на 40-50 должно ускориться. В смысле, время сократится на треть где-то. :-) Ты для начала сравни время собственно сортировки и чтения с диска соответствующей порции данных. А потом уже проценты вычисляй ;) Раз процессорная мощность используется на половину, то конечно можно её задействовать полнее, но не таким образом -- Хорсун Влад
Re: OFF: Разгон машины тьюринга :)))
On 14 июн, 10:14, Kovalenko Dmitry [EMAIL PROTECTED] wrote: Привет всем. ... Не все таки меня здорово подкололи насчет моей реализации управления деревом, хранящимся в файле. Ржунемогу. Респект шутнику :) Вообщем, не асилил :( Вчера понял, что я уже забыл ради чего я затеял кэш - решил заморозить это направление. Пишу сразу в базу. Локальные кэши (которые были в памяти и работали до кеша в индексе) я оставил - реально помогают уменьшить количество обращений к базе. Но пишу я вот по какому виду. Многопоточная лихорадка меня еще не покинула :) - хочу чтобы сервер мог работать в _одной_ транзакции для двух подключений. То бишь подключения видят грязные изменения другого подключения. Гы. - придумал такую штуку. Нужно время от времени фиксировать сделанную работу (посредством commit_retaining). Перебрал в голове несколько вариантов как останавливать генераторы при достижении порогового объема. Больше всего понравилась идея прикрутить синхронизацию много читателей, один писатель. Когда генератор данных в БД начинает новую порцию данных (начал индексацию очередного документа), он блокирует подключение как читатель. Когда поток, следящий за размером данных, закачанных в базу, видит что пора фиксировать - он пытается заблокировать на запись. В этот момент все новые попытки читать приостанавливаются, ждется завершение работы текущих читателей, и после того как все читатели будут выгнаны - делаем commit_retaining. Бугага. Коваленко Дмитрий.
Re[2]: OFF: Разгон машины тьюринга :)))
Привет! Спасибо! Вопрос - ты считал количество колизий для CRC32? Большое оно? Мы как-то попробовали подсчитать - и забили. Для осмысленного теста - исчезающе мало. Даже если и вдруг - то пусть обращаются :) Только вот неймется им искать по части слова хоть тресни. Придется делать фулскан по заголовку как в старой системе. Хотя, как оказалось, причина этого до ужаса банальна. Чичазз выдам государственную тайну: многие юристы просто не знают, как правильно пишутся термины. Отсюда и такое настойчивое желание. Достали они меня все. поиск делается с помощью SELECT a.docid FROM index a, query b WHERE a.term = b.term GROUP BY a.docid HAVING COUNT(*) = tand value т.е. твое решение такое же как там, так что думаю, что твой запрос оптимален. Мдям-с, вот так всегда. Надо будет еще поковырять различные варианты. -- Best regards, Sergeymailto:[EMAIL PROTECTED]
Re[2]: OFF: Разгон машины тьюринга :)))
Привет! Сергей, текст очень сильный, прочитал пока только треть - дальше страшно. Скачал словари из ОО. Возник вопрос - где бы почитать про их формат? А то схожу не разберусь. Меня интересует процесс приведения слова в его нормальную форму. Или можно на пальцах, если несложно. Как только закончим - напишу полностью про все с примерами кода. Мне не жалко, а эти чайники не удосужились в контракте указать ничего о нераспространении кода. Тем более, что это наш собственный велосипед. -- Best regards, Sergeymailto:[EMAIL PROTECTED]
Re: OFF: Разгон машины тьюринга :)))
Только вот неймется им искать по части слова хоть тресни. Придется делать фулскан по заголовку как в старой системе. По моему такая деградация поиска возникает если они не знают начало слова. Типа *нный. Если же госуда*, то можно построить список слов, которые удовлетворяют этому шаблону и потом применить нормальный поиск Думаю, так оно у вас и сделано. вот кстати. Я тут комбинации горожу, а ведь можно (тут кто-то так и сделал) слово разваливать на кусочки :) Коваленко Дмитрий.
Re: Re[2]: OFF: Разгон машины тьюринга :)))
Подсчет количества найденных документов (ну вот захотелось им такую фичу и все): select count(d.id) from t_documents d, (select w.document_id, count(1) as cnt from t_search_words w, ( select 2624961196 as wrd from rdb$database union select 1902388292 as wrd from rdb$database union select 1228066714 as wrd from rdb$database ) t1 where w.lang_id=2 and w.flag=1 and w.word=t1.wrd group by 1 order by 2 desc ) idx where d.lang_id=2 and d.published_when='01.07.2002' and d.published_when='02.07.2007' and d.publisher_id =36149 and d.id=idx.document_id and idx.cnt=3 Тут все просто - виртуальную табличку, в которой содержатся слова для поиска объединяем с поисковыми индексами, а результат объединения - объединяем с таблицей с документами. Указание найти все три слова - последний and . Про то, что логически правильнее было бы использовать union all я знаю, но ключевые слова 2 раза не указывают. Если кто сможет указать более оптимальный вариант запроса - и такой же понятный - буду очень признателен. Это пробовали ? select count(d.id) from t_documents d, (select w.document_id, count(1) as cnt from t_search_words w where w.lang_id=2 and w.flag=1 and w.word in (2624961196, 1902388292, 1228066714) group by 1 order by 2 desc ) idx where d.lang_id=2 and d.published_when='01.07.2002' and d.published_when='02.07.2007' and d.publisher_id =36149 and d.id=idx.document_id and idx.cnt=3 и\или select count(d.id) from t_documents d where d.lang_id=2 and d.published_when='01.07.2002' and d.published_when='02.07.2007' and d.publisher_id =36149 and exists (select * from _search_words w1 where w.document_id = d.id and w.lang_id=2 and w.flag=1 and w.word = 2624961196) and exists (select * from _search_words w2 where w.document_id = d.id and w.lang_id=2 and w.flag=1 and w.word = 1902388292) and exists (select * from _search_words w3 where w.document_id = d.id and w.lang_id=2 and w.flag=1 and w.word = 1228066714) -- Хорсун Влад
Re[4]: OFF: Разгон машины тьюринга :)))
Привет! Это пробовали ? Попробовал. (с переконнектом между запросом, так что если и затесался кэш - то только от операционки, знаю, что в идеале надо бы сервак перегрузить, но правов нету. Кстати, даже после переконнекта кэш операционки вносит лепту - мой повторный запрос исполняется меньше секунды даже после переконнекта.) Каждый запрос в рамках одного подключения исполнялся три раза, привожу результат третьего исполнения: Статистика: Мой III Prepare time = 219ms 187ms 219ms Execute time = 764ms 2s 886ms624ms Avg fetch time =764,00 ms 2 886,00 ms 624,00 ms Current memory =67 214 38067 509 784 67 610 984 Max memory =88 446 41278 127 420 67 743 440 Memory buffers =4 000 4 000 4 000 Reads from disk to cache = 17 54215 229 8 801 Writes from cache to disk = 0 0 0 Fetches from cache =73 78793 782 133 848 * Планы: Мой запрос: Plan PLAN JOIN (SORT (SORT (JOIN ((IDX T1 RDB$DATABASE NATURAL) PLAN (IDX T1 RDB$DATABASE NATURAL) PLAN (IDX T1 RDB$DATABASE NATURAL), IDX W INDEX (T_SEARCH_WORDS_IDX1), D INDEX (PK_T_DOCUMENTS) Adapted Plan PLAN JOIN (SORT (SORT (JOIN ((IDX T1 RDB$DATABASE NATURAL) PLAN (IDX T1 RDB$DATABASE NATURAL) PLAN (IDX T1 RDB$DATABASE NATURAL), IDX W INDEX (T_SEARCH_WORDS_IDX1), D INDEX (PK_T_DOCUMENTS) Твой первый: Plan PLAN JOIN (SORT (IDX W ORDER FK_T_SEARCH_WORDS_1 INDEX (T_SEARCH_WORDS_IDX1, T_SEARCH_WORDS_IDX1, T_SEARCH_WORDS_IDX1)), D INDEX (PK_T_DOCUMENTS)) Adapted Plan PLAN JOIN (SORT (IDX W ORDER FK_T_SEARCH_WORDS_1 INDEX (T_SEARCH_WORDS_IDX1, T_SEARCH_WORDS_IDX1, T_SEARCH_WORDS_IDX1)), D INDEX (PK_T_DOCUMENTS)) Твой второй: Plan PLAN (W INDEX (PK_T_SEARCH_WORDS)) PLAN (W INDEX (PK_T_SEARCH_WORDS)) PLAN (W INDEX (PK_T_SEARCH_WORDS)) PLAN (D INDEX (T_DOCUMENTS_IDX3, FK_T_DOCUMENTS)) Adapted Plan PLAN (W INDEX (PK_T_SEARCH_WORDS)) PLAN (W INDEX (PK_T_SEARCH_WORDS)) PLAN (W INDEX (PK_T_SEARCH_WORDS)) PLAN (D INDEX (T_DOCUMENTS_IDX3, FK_T_DOCUMENTS)) * Насколько я могу судить, твой второй запрос (я его слегка отредактировал - вместо select * написал select 1 - по идее должно чуть-чуть меньше памяти слопать) работает толику быстрее за счет отсутствия сортировки - надо будет посмотреть изменение производительности, если будет 10 ключевых слов. На первый из твоих запросов кэш вообще никак не влияет, как я могу судить. Но вот что мне интересно - так это почему при количестве чтений меньшем почти в раза, третий запрос исполняется почти с такой же скоростью, как и первый? -- Best regards, Sergeymailto:[EMAIL PROTECTED]
Re: OFF: Разгон машины тьюринга :)))
Vlad Horsun [EMAIL PROTECTED] сообщил/сообщила в новостях следующее: news:[EMAIL PROTECTED] по прежнему включён. Загрузка выше 52% не поднимается. :-) И что из этого ? Да ничего особенного. Резервы есть, значит. Ты для начала сравни время собственно сортировки и чтения с диска соответствующей порции данных. А потом уже проценты вычисляй ;) Чтение с диска соответствующей порции данных - от 16 секунд (для 1-й порции) до 31 сек. (для предпоследней). К концу кэш ОС забился... Время собственно сортировки - 41 секунда. Запись - 14-15 сек. Раз процессорная мощность используется на половину, то конечно можно её задействовать полнее, но не таким образом Переделал в двухпоточную, доступ к входному файлу сериализован, запись выходных файлов отдаётся на откуп ОС через асинхронный вызов. Итог: 557 сек - 398 сек. Время сократилось на 28%. Загрузка процессора ниже 65% не падает, процентов (на глаз) 80 времени - держится на 100%. Диск молотит без остановок. В первом варианте по индикатору HDD можно было чётко видеть, какой этап (чтение/сортировка/запись) идёт. :-) Результат, конечно, не так впечатляет, как включение оптимизации компилятору... ;-)
Re: OFF: Разгон машины тьюринга :)))
Как только закончим - напишу полностью про все с примерами кода. Мне не жалко, а эти чайники не удосужились в контракте указать ничего о нераспространении кода. Тем более, что это наш собственный велосипед. Спасибо, буду ждать! а то я только начинаю этот велосипед придумывать и хочется его развивать ;)
Re: OFF: Разгон машины тьюринга :)))
Alexander V. Skvortsov ... Vlad Horsun ... Ты для начала сравни время собственно сортировки и чтения с диска соответствующей порции данных. А потом уже проценты вычисляй ;) Чтение с диска соответствующей порции данных - от 16 секунд (для 1-й порции) до 31 сек. (для предпоследней). К концу кэш ОС забился... Время собственно сортировки - 41 секунда. Запись - 14-15 сек. Чегой-то долгая у тебя сортировка. Раз процессорная мощность используется на половину, то конечно можно её задействовать полнее, но не таким образом Переделал в двухпоточную, доступ к входному файлу сериализован, запись выходных файлов отдаётся на откуп ОС через асинхронный вызов. Итог: 557 сек - 398 сек. Время сократилось на 28%. Загрузка процессора ниже 65% не падает, процентов (на глаз) 80 времени - держится на 100%. Диск молотит без остановок. В первом варианте по индикатору HDD можно было чётко видеть, какой этап (чтение/сортировка/запись) идёт. :-) Звучит вроде неплохо ;) Дисковый IO замерял ? Результат, конечно, не так впечатляет, как включение оптимизации компилятору... ;-) Есть ещё резервы в самой сортировке :) -- Хорсун Влад
Re: OFF: Разгон машины тьюринга :)))
Сергей, текст очень сильный, прочитал пока только треть - дальше страшно. Скачал словари из ОО. Возник вопрос - где бы почитать про их формат? А то схожу не разберусь. Меня интересует процесс приведения слова в его нормальную форму. Или можно на пальцах, если несложно.
Re: OFF: Разгон машины тьюринга :)))
On 3 июл, 13:08, Alex V. Skvortsov [EMAIL PROTECTED] wrote: другой, получил 50 минут (если не считать генерацию файла). Машина PIV 4 GHz с включёным гипертредингом. Можно параллельно закачивать и Чёрт, палец не к той клавише прилип. :-) 3ГГц, конечно. сортировать в памяти 2 куска, а в процессе записи сливать их в один гигабайтный файл. Процентов на 30 время сократится. Фигня всё эти проценты. Выставил студии, чтобы она не DEBUG-версию делала, а RELEASE со всеми оптимизациями по скорости - результат в разы быстрее! ;-). Приложение по прежнему однопоточное, гипертрединг по прежнему включён. Загрузка выше 52% не поднимается. :-) Генерация 480 млн 64-битных значений- 188 сек (ага, через rand()*rand() :-), сортировка кусками по 512 метров - 557 секунд в сумме (std::sort 512 метров за 41 секунду сортирует), объединение 8-ми получившихся файлов в 1 сортированный файл _на_том_же_разделе_ - 364 секунды. Итого 18 с половиной минут.
Re: OFF: Разгон машины тьюринга :)))
Hello, Alex! Alex V. Skvortsov wrote: делала, а RELEASE со всеми оптимизациями по скорости - результат в разы быстрее! ;-). Приложение по прежнему однопоточное, гипертрединг по прежнему включён. Загрузка выше 52% не поднимается. :-) с гипертредингом-то - разумеется. Он же показывает одно ядро как 2 ядра, а на самом деле их ... эээ... где-то в сумме полтора, если не меньше. 1.25 примерно :-) -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Re: OFF: Разгон машины тьюринга :)))
On 3 июл, 13:42, Kovalenko Dmitry [EMAIL PROTECTED] wrote: Нет не правильно. Точнее правильно, но не совсем. Для пар слов - так оно и есть. Для комбинаций из трех слов, сначало формируется две пары (WordID1,WordID2), (WordID2,WordID3) потом этим парам назначается идентификатор pairID1, pairID2 Они ж вроде уже должны быть сформированы и назначены уже? Это же добавление к _уже_имеющейся_паре_ (word2, word3) слова word1 слева, am I right? Или ты для троек слов всё с нуля генеришь? эти идентификаторы объединяются в новую пару - (pairID1,pairID2) и она снова добавляется в индекс. Если добавилась, значит пара уникальная - и ей присваивается индекс pairID3. Если не добавилась - значит такая комбинация из трех слов уже была и берется существующий индекс. Что-то тут я уже потерялся. Горючее (кофе) кончилося. Идентификаторы пары слов и пары пар как-нибудь различаются? Хотя... Зачем их различать-то... Не, кофе куплю - продолжу. Конечно, эту последовательность можно свести к сортировке. Но тогда потребуется два прохода по всем объектам. А этого хочется избежать. Реально, конечно, можно вообще забить на тот клиентский индекс, который я хочу построить - просто регистрировать пары в базе и не парится. К этому, кажется все и идет :) ... детей не люблю, но сам процесс ... Или задача именно поддерживать индекс отсортированным в процессе генерации пар? Ага. А пока кофе нету - ОВСФ: зачем? Есть первичное создание индекса. Есть добавление единичного документа. Со вторым, я так думаю, у тебя проблем уже не будет. А первое нужно не каждый день. В общем, моё ИМХО на фоне недостатка кофеина - сделать отдельно высокооборотистый движок и отдельно с большим крутящим моментом. :-)
Re: OFF: Разгон машины тьюринга :)))
On 3 июл, 13:45, Kovalenko Dmitry [EMAIL PROTECTED] wrote: Машина PIV 4 GHz с включёным гипертредингом. ~~~ Гы. А штатная частота какая? Да перепутал я клавиши. :-( 3 ГГц всего.
Re: OFF: Разгон машины тьюринга :)))
Для комбинаций из трех слов, сначало формируется две пары (WordID1,WordID2), (WordID2,WordID3) потом этим парам назначается идентификатор pairID1, pairID2 Они ж вроде уже должны быть сформированы и назначены уже? Это же добавление к _уже_имеющейся_паре_ (word2, word3) слова word1 слева, am I right? Или ты для троек слов всё с нуля генеришь? Комбинация для трех слов - формируется из двух комбинации для двух. эти идентификаторы объединяются в новую пару - (pairID1,pairID2) и она снова добавляется в индекс. Если добавилась, значит пара уникальная - и ей присваивается индекс pairID3. Если не добавилась - значит такая комбинация из трех слов уже была и берется существующий индекс. Что-то тут я уже потерялся. Горючее (кофе) кончилося. Идентификаторы пары слов и пары пар как-нибудь различаются? Хотя... Зачем их различать-то... Не, кофе куплю - продолжу. Идентификаторы пары и отдельного слова ничем не различаются - назначаются одним генератором. Я просто решил, что комбинация ((WordID1,WordID2),WordID3) не так полезна, как (((WordID1,WordID2),(WordID2,WordID3)) А пока кофе нету - ОВСФ: зачем? Есть первичное создание индекса. Есть добавление единичного документа. Со вторым, я так думаю, у тебя проблем уже не будет. А первое нужно не каждый день. Да это я так ... очень сильно увлекся ... захотел поиграть в серверо- писателей. О потраченном времени ни капли не жалею :) Коваленко Дмитрий.
Re: OFF: Разгон машины тьюринга :)))
Dmitri Kuzmenko [EMAIL PROTECTED] сообщил/сообщила в новостях следующее: news:[EMAIL PROTECTED] делала, а RELEASE со всеми оптимизациями по скорости - результат в разы быстрее! ;-). Приложение по прежнему однопоточное, гипертрединг по прежнему включён. Загрузка выше 52% не поднимается. :-) с гипертредингом-то - разумеется. Он же показывает одно ядро как 2 ядра, а на самом деле их ... эээ... где-то в сумме полтора, если не меньше. 1.25 примерно :-) Фазу сортировки можно подсократить, загрузив второе ядро ещё одним потоком, который, пока 1-й сортирует, будет подгружать очередной кусок данных и сортировать его. Придётся только сериализовать чтение входного файла - выходной файл для каждого куска свой. Процентов на 40-50 должно ускориться. В смысле, время сократится на треть где-то. :-)
Re: OFF: Разгон машины тьюринга :)))
Тогда не понятно в чём может быть затык. Ты бы лучше куски кода постил, а то телепатия нынче редкость. На текущий момент - затык с диском. - Послушал как работает машина (в натуре на слух), и понял - нужно нафиг отключить буферизацию файловых операций. То бишь указал флаги FILE_FLAG_WRITE_THROUGH, FILE_FLAG_NO_BUFFERING Ага. Именно назад, к природе. А ты ещё на IBAPI бочку катил ;) Ну не равняйте этого с этой, пожалуйста. На самом деле FILE_FLAG_WRITE_THROUGH имеет смысл для увеличения надёжности и когда памяти в компе мало. Если памяти много, то этот флаг лучше не ставить. FILE_FLAG_NO_BUFFERING я вообше не понимаю чем тут может помочь. Я тоже. Но это работает и ладно. отказаться от мелких блоков, а перейти к блокам занимающим всю страницу целиком. Продолбенился над реализацией целый день. Получилось красиво. И - о чудо! У меня многопоточная реализация стала работать вровень с однопоточной. Ну что и следовало доказать. При увеличении размера блоков издержки на синхронизацию в процентном отношении падают. Знаешь, Алексей, что меня веселит. Все всё знают, но до сих пор никто не дал готовый шаблон кода для управления индексом со словами - вот тут подключи менеджер страниц, который дает вот такой набор методов. На текущий момент времени, я осознал что увеличение размера блоков и прямой доступ к памяти кэша - это только часть требований. Не только осознал, но и реализовал. Напомню, мне нужно построить уникальный индекс для (по последним прогнозам) 100 лимонов элементов вида (ID1, ID2). Максимум что я смог осилить - 20 лимонов. Что значит осилить? Какая цель то? Есть множество пар (ID1, ID2). Их общее число где-то 350 лимонов. Уникальных - 100 лимонов. Нужно получить это множество уникальных пар. ID это целые числа. Начинаются с 1 и заканчиваются, полагаю, в районе 100 лимонов. Есть ещё одно правило - ID1 строго меньше ID2. Которое, возможно, сможет оптимизировать конструкцию индекса. Я там про два часа говорил. Я не учел, что при том махании топором неизбежно возникнут баги :( Короче, я провел эксперимент. Из последних модернизаций движка, управляющего кэшем и работающего с файлом - ассинхронный чтение и запись. Но это так - чисто для успокоения души. Как я и предполагал - чтобы потоки генерации не забивали поток выгрузки модифицированных страниц, при добавлении новой комбинации нужно как можно меньше модифицировать страниц. В моем случае (хеш таблица со списками отсортированных блоков) это 1-2 страницы. Если поддерживать отсортированность сквозь все блоки списка - производительность резко падает (модифицируется много блоков + из-за разряженности быстрее жрется память) Вот статистика по проведенному эксперименту overflow [4] - число переполнений буфера входящих данных flush [4879] - число опустошений этого буфера words [102104] - число слов, из которых потом генерировались комбинации ip [17758789] - число уникальных комбинаций. Это то, что как раз помещается в индекс hit ip [11215320] - это число обращений к кэшу, которые нашли ранее сгенерированную комбинацию d_pages [30010] - число грязных страниц кэша c_pages [9] - число чисты страниц кэша BlockCapacity:127 - число элементов на блоке списка (короче на - на одной странице) Далее число блоков в списке / количество списков с такой длиной 13:14 14:5287 15:4681 16:18 Общее число списков в хеш-таблице - 1. Размер кэша 120010 страниц. Как видно -таблица заполняется равномерно. Скорость упала в районе 14.5 млн комбинаций. Это как раз кэш закончился. Упала с 25 тысяч комбинаций до 300-400 комбинаций (это финальная скорость). Ассинхронная работа с файлом не помогла - хотя работало 4 потока генерации. Сразу после того как кэш закончился, поток выгрузки модифицированных страниц, стаблизировал соотношение 30 тыс / 90 тыс, и оно не менялось до самого финиша (+/- 10 страниц). Последние три лимона генерировались свыше 7 часов. Начальные 14.5 лимонов - полтора часа. Вообщем движок есть. Я уже не знаю что туда можно прикрутить. Есть понимание - длина пути поиска должна быть как можно короче. Страницы должны заполняться как можно плотнее. Возможно это спорное утверждение. При вставке нужно модифицировать как можно меньше. Вопрос - как это все объединить? Я тут поприкладывал умную книгу к голове. Две вещи понравились Первая - так называемые DST. Digital Search Tree. Высота дерева не больше числа байт в ключе. В моем случае она не превысит восьми. Хотя, вообще говоря - ID у меня 64-битное. Вторая - Б-деревья. Первая, в силу своей интутивной понятности, мне нравится гораздо больше чем вторая. Не требует расшеплений узлов, балансировки. Не нужно хранить ключ - он вычисляется при переходах. И я вроде как понимаю как можно сделать параллельную работу с индексом. Для первых двух байт ключа можно поддерживать таблицу в памяти. То есть, высота сократится до 6 уровней. Вторая вещь моим опухшим моском понимается. Но с трудом. Люди, скажите что нибудь. Хотя бы такую вещь
Re: OFF: Разгон машины тьюринга :)))
Kovalenko Dmitry wrote: Люди, скажите что нибудь. Хотя бы такую вещь - FB может параллельно добавлять новые ключи в индексы? Может. Затык будет в менеджере блокировок на EX-локах, если параллельные потоки полезут на одну и ту же страницу. -- Дмитрий Еманов
Re: OFF: Разгон машины тьюринга :)))
Kovalenko Dmitry ... Тогда не понятно в чём может быть затык. Ты бы лучше куски кода постил, а то телепатия нынче редкость. На текущий момент - затык с диском. Я же говорил - пиши последовательно, а не абы как. И как можно бОльшими кусками ... Я тут поприкладывал умную книгу к голове. Две вещи понравились Первая - так называемые DST. Digital Search Tree. Высота дерева не больше числа байт в ключе. В моем случае она не превысит восьми. Хотя, вообще говоря - ID у меня 64-битное. 8 ??? Вторая - Б-деревья. Тут будет не более 4-х на твоих объёмах Люди, скажите что нибудь. Хотя бы такую вещь - FB может параллельно добавлять новые ключи в индексы? Конечно. Но имей в виду - одновременно на одну и ту же страницу конечно же никто не пишет Я уже начинаю верить, что в FB есть что-то нереальное, раз он в состоянии управлять индексами для таблиц размером больше 25 лимонов записей. :) Кстати - префиксная компрессия ключей в этом смысле очень даже рулит. Хотя кодировать это - ужас один -- Хорсун Влад
Re: OFF: Разгон машины тьюринга :)))
Спасибо, пацаны, что не забыли :) На текущий момент - затык с диском. Я же говорил - пиши последовательно, а не абы как. И как можно бОльшими кусками ... Видно деваться будет некуда. Щас буду пытаться систематизировать сделанные изменения, я же сломал все что только можно сломать. Потом начну смотреть. Большими кусками... У меня в кэше сегменты, находящиеся рядом на диске, могут находиться в разных частях кэша. То есть нахаляву состыковать их в памяти не удасться. Тут выход - либо копировать их в линейный буфер (маразм?) либо упорядочивать выдачу команд на запись ... Читать-то все равно только по одной странице за раз надо ? Опять же - поток который пишет он спит. 3/4 кэша были чистые ... Текущие траблы из-за того что много промахов мимо кэша. У меня писатель на самом низком приоритете работает. И видно, что когда начинаются запросы на чтение с диска запись замирает на достаточно длительные интервалы времени. Но это опять же - такое поведение для текущей реализации индекса Первая - так называемые DST. Digital Search Tree. Высота дерева не больше числа байт в ключе. В моем случае она не превысит восьми. Хотя, вообще говоря - ID у меня 64-битное. 8 ??? Ага. Я как посмотрел на количество (я их раньше приводил) комбинаций, так и ... прибалдел. число объектов: 1100403 14786203 92189456 - две слова 380927263 - три слова 1137077468 2618853571 4870046956 7588537049 1028171 12670250189 15072709841 [54726933567] Кстати, всего получается надо сгенерировать не 350 млн, а 470 млн. Но, думаю, уникальных будет не больше 100 млн. Вторая - Б-деревья. Тут будет не более 4-х на твоих объёмах При 4 килобайтной странице ... У меня 4-х байтный идентификатор страницы. Ключ, считай, 16-байтный. Данные, которые нужно привязаны к ключу - 8 байт (это тот же ID, только для пары целиком). Люди, скажите что нибудь. Хотя бы такую вещь - FB может параллельно добавлять новые ключи в индексы? Конечно. Но имей в виду - одновременно на одну и ту же страницу конечно же никто не пишет А разве алгоритм Б-дерева обратно по дереву не поднимается? Если поднимается - то может же возникнуть блокировка ... Кстати - префиксная компрессия ключей в этом смысле очень даже рулит. Хотя кодировать это - ужас один Я дальше отбрасывания ведущих нулевых байт для DST не собирался сжимать. Поэтому и говорил про 4 байта (при 8 максимум). ... Значит все таки практикующие акушеры рекомендуют Б-дерево. Коваленко Дмитрий.
Re: OFF: Разгон машины тьюринга :)))
Oleg LOA ... Horsun Vlad ... Кстати - префиксная компрессия ключей в этом смысле очень даже рулит. Хотя кодировать это - ужас один А чего-нибудь гтового OS на эту тему нету случаем? Смеёсся ? Напомнить, где btr.cpp лежит ? :) А то вдруг мы туту велосипед проектируем :-):-):-) Точно смеёсся, бу-га-га ;))) -- Хорсун Влад
Re: OFF: Разгон машины тьюринга :)))
Kovalenko Dmitry ... Спасибо, пацаны, что не забыли :) Тебя забудешь ;) На текущий момент - затык с диском. Я же говорил - пиши последовательно, а не абы как. И как можно бОльшими кусками ... Видно деваться будет некуда. Щас буду пытаться систематизировать сделанные изменения, я же сломал все что только можно сломать. Потом начну смотреть. Большими кусками... У меня в кэше сегменты, находящиеся рядом на диске, могут находиться в разных частях кэша. То есть нахаляву состыковать их в памяти не удасться. А в памяти и не надо. См. WriteFileGather API (в posix'е, кстати, оно на порядок удобнее). Главное тут - последовательно. Если удастся большими кусками - тем лучше (ибо они по-определению последовательны), но главное - последовательно. Тут выход - либо копировать их в линейный буфер (маразм?) либо упорядочивать выдачу команд на запись ... Второе, конечно. У тебя нет наших проблем с precedence, поэтому ты волен писать страницы в любом удобном для тебя порядке Читать-то все равно только по одной странице за раз надо ? Почему ? Опять же - поток который пишет он спит. 3/4 кэша были чистые ... Он и должен почти всегда спать - диск работает ;) Текущие траблы из-за того что много промахов мимо кэша. У меня писатель на самом низком приоритете работает. А не нада трогать приоритеты потоков. Пусть писатель просыпается когда ему есть что делать и делает это частями, но не все сразу. ... Вторая - Б-деревья. Тут будет не более 4-х на твоих объёмах При 4 килобайтной странице ... У меня 4-х байтный идентификатор страницы. Ключ, считай, 16-байтный. Данные, которые нужно привязаны к ключу - 8 байт (это тот же ID, только для пары целиком). Я вообще-то FB-шные индексы имел в виду и страницу в 8-16К. Люди, скажите что нибудь. Хотя бы такую вещь - FB может параллельно добавлять новые ключи в индексы? Конечно. Но имей в виду - одновременно на одну и ту же страницу конечно же никто не пишет А разве алгоритм Б-дерева обратно по дереву не поднимается? Если поднимается - то может же возникнуть блокировка ... Кури btr.cpp - как там все сделано в смысле блокировок. При вставке в индекс никогда не блокируется более одной страницы одновременно, даже во время расщепления. При удалении блокируется до 4-х страниц, из них на запись только одна. Всё в строгом порядке, есс-но, так что дедлоков быть не может Кстати - префиксная компрессия ключей в этом смысле очень даже рулит. Хотя кодировать это - ужас один Я дальше отбрасывания ведущих нулевых байт для DST не собирался сжимать. Поэтому и говорил про 4 байта (при 8 максимум). А ты обрати внимание на среднюю длину ключа в индексе FB и на кол-во занимаемых страниц. Тебе понравится ;) ... Значит все таки практикующие акушеры рекомендуют Б-дерево. Шо знаем, то и рекомендуем :) -- Хорсун Влад
Re: OFF: Разгон машины тьюринга :)))
Вот статистика по проведенному эксперименту overflow [4] - число переполнений буфера входящих данных flush [4879] - число опустошений этого буфера words [102104] - число слов, из которых потом генерировались комбинации ip [17758789] - число уникальных комбинаций. Это то, что как раз помещается в индекс hit ip [11215320] - это число обращений к кэшу, которые нашли ранее сгенерированную комбинацию d_pages [30010] - число грязных страниц кэша c_pages [9] - число чисты страниц кэша BlockCapacity:127 - число элементов на блоке списка (короче на - на одной странице) Далее число блоков в списке / количество списков с такой длиной 13:14 14:5287 15:4681 16:18 Общее число списков в хеш-таблице - 1. Размер кэша 120010 страниц. Как видно -таблица заполняется равномерно. Скорость упала в районе 14.5 млн комбинаций. Это как раз кэш закончился. Упала с 25 тысяч комбинаций до 300-400 комбинаций (это финальная скорость). Ассинхронная работа с файлом не помогла - хотя работало 4 потока генерации. Сразу после того как кэш закончился, поток выгрузки модифицированных страниц, стаблизировал соотношение 30 тыс / 90 тыс, и оно не менялось до самого финиша (+/- 10 страниц). Я наверное не понимаю чего-то... Эти ID1, ID2 ты ж ведь из базы выбираешь. Почему их нельзя выбирать в нужном порядке? Так чтоб страницы твоей HashTable последовательно заполнялись. Тогда просто заполнилась очередная страница и встала в очередь на запись... With b/r. Gleb.
Re: OFF: Разгон машины тьюринга :)))
А в памяти и не надо. См. WriteFileGather API (в posix'е, кстати, оно на порядок удобнее). Вот ... падла. Я про Рихтера. Влад, спасибо. Я и не знал про эту пару функций. Читать-то все равно только по одной странице за раз надо ? Почему ? А что я могу за два раза прочитать? Если только сдвоеные страницы для каталога индекса использовать... А ведь в натуре, блин... чего я на одной странице, как дэбел, все ютюся. Пляя Слушай, я вот все не фтыкаю. Как вы работает на 75 страницах классика? Это же ахтунг натуральный. Вторая - Б-деревья. Тут будет не более 4-х на твоих объёмах При 4 килобайтной странице ... У меня 4-х байтный идентификатор страницы. Ключ, считай, 16-байтный. Данные, которые нужно привязаны к ключу - 8 байт (это тот же ID, только для пары целиком). Я вообще-то FB-шные индексы имел в виду и страницу в 8-16К. Последовательно идущие две-четыре страницы? Влад, если я начал думать в правильную сторону, то твои подсказки - это первая реальная помощь за все это время. Великого LOA, который сподвигул меня к OVERLAPPED-операциям, в расчет не берем - он вне конкуренции :) Кури btr.cpp - как там все сделано в смысле блокировок. При вставке в индекс никогда не блокируется более одной страницы одновременно, даже во время расщепления. При удалении блокируется до 4-х страниц, из них на запись только одна. Всё в строгом порядке, есс-но, так что дедлоков быть не может Пасибо! Кстати - префиксная компрессия ключей в этом смысле очень даже рулит. Хотя кодировать это - ужас один Я дальше отбрасывания ведущих нулевых байт для DST не собирался сжимать. Поэтому и говорил про 4 байта (при 8 максимум). А ты обрати внимание на среднюю длину ключа в индексе FB и на кол-во занимаемых страниц. Тебе понравится ;) Не сомневаюсь :) ... Значит все таки практикующие акушеры рекомендуют Б-дерево. Шо знаем, то и рекомендуем :) Еще раз, большое человеческое спасибо! Коваленко Дмитрий.
Re: OFF: Разгон машины тьюринга :)))
Я наверное не понимаю чего-то... Эти ID1, ID2 ты ж ведь из базы выбираешь. Часть выбираю - это идентификаторы слов. Часть генерирую внутрях - слова комбинируются в пары и этой паре назнается ID. То есть я - беру слова из базы - их внешние идентификаторы тификаторы отображаю на внутренние идентификаторы - потом эти внутренние идентификаторы комбинирую. Если получается уникальная комбинация - назначаю её другой внутренний идентификатор. - идентификатор пары может использоваться в другой паре (состоящей из 3,4 ... слов) - потом комбинации регистрируются в базе. Почему их нельзя выбирать в нужном порядке? Так чтоб страницы твоей HashTable последовательно заполнялись. Тогда просто заполнилась очередная страница и встала в очередь на запись... Дык я так и делал. Я же статистику привел - таблица заполняется равномерно. Списки для каждого Hash значения до 16 страниц получаются. А в памяти максимум 12-страничные списки влазят. И диск начинает клинить. Я же по всего навсего по 4K читаю-пишу... Коваленко Дмитрий.
Re: OFF: Разгон машины тьюринга :)))
Kovalenko Dmitry [EMAIL PROTECTED] wrote in message
Слушай, я вот все не фтыкаю. Как вы работает на 75 страницах классика?
Это же ахтунг натуральный.
Гм, там вообще-то файловый кэш ОС во всю работает. Никакаими граблями там и не
пахнет ;-)
сподвигул меня к OVERLAPPED-операциям, в расчет не берем - он вне
конкуренции :)
Вот мне бы кто помог рассчитать задачку: какую мощность я могу передать на
насос НШ-32 со шкива колневала при заданном количестве ручьёв ремня и усилии на
натяжителе?! Вот в чём вопрос, а у тя всё просто ;-) ;-) ;-) ;-) ;-) ;-)
Пасибо!
Пивом тока запасись :-). Код там местами трудный.а в дятле вообще
нечитаемый ;-)
Айм рыдал, бился головй ап стену но продолжал жрать команды асма когда этот
алгоритм отлаживал. Будешь делать компрессию - будет тоже самое, тока сначала
на сях ;-);-);-)
BTN BTR_find_leaf (
BTR bucket,
KEY *key,
UCHAR *value,
UCHAR *return_value,
int descending,
BOOLEAN retrieval)
{
/**
*
* B T R _ f i n d _ l e a f
*
**
*
* Functional description
* Locate and return a pointer to the insertion point.
* If the key doesn't belong in this bucket, return NULL.
* A flag indicates the index is descending.
*
**/
#if defined _M_IX86 !defined IGNORE_NULL_IDX_KEY defined MSC_OPTIMIZE1
UCHAR *p;
_asm
{
cld
mov ecx, bucket
lea ebx, [ecx]bucket.btr_nodes ;node = bucket-btr_nodes, now EBX is node
mov edx, key ;now EDX is key
lea esi, [edx]KEY.key_data;p = key-key_data, now ESI is p
cmp byte ptr [ecx]BTR.btr_level, 0 ;if (bucket-btr_level
setnz al
cmp byte ptr [ebx]BTN.btn_length, 0 ;!node-btn_length
setz ah
and al, ah
cmp descending, 0 ;descending
setnz ah
and al, ah
jz L1
movzx edi, [ebx]BTN.btn_length
lea ebx, [ebx]BTN.btn_data
add ebx, edi ;node = (BTN) (node-btn_data + node-btn_length);
L1: movzx edx, word ptr[edx]KEY.key_length ;key-key_length
add edx, esi;now EDX is key_end = p +
key-key_length
xor eax, eax ;prefix = 0, now EAX is prefix
cmp descending, 0
jz M1
;while (1) if (descending)
cmp retrieval, 0
jz L2
L0: ;while (1) if (descending retrieval)
mov edi, value ;if(value
test edi, edi
jz L3
movzx ecx, [ebx]BTN.btn_length ; (l=node-btn_length))
test ecx, ecx
jz L3
mov p, esi;{ save p
movzx esi, [ebx]BTN.btn_prefix
add edi, esi ; r = value + node-btn_prefix
lea esi, [ebx]BTN.btn_data ; q = node-btn_data
rep movsb ; do *r++ = *q++; while (--l), movsd
optimization ???
mov esi, p ;}
L3: cmp dword ptr[ebx+2], -1;if ((*(int*)node-btn_number) ==
-1) goto done;
jz DN
mov cl, [ebx]BTN.btn_prefix
cmp cl, al ;if (node-btn_prefix prefix) goto done;
jb DN
jnz L4 ;if (node-btn_prefix == prefix)
movzx ecx, [ebx]BTN.btn_length ;node_end - q
mov edi, edx ;key_end
sub edi, esi ;key_end - p
cmp ecx, edi ;node_end - q ? key_end - p
jbe L6
mov ecx, edi
L6: lea edi, [ebx]BTN.btn_data;q = node-btn_data, now EDI is q
repe cmpsb
jbe DN ;q == node_end || p == key_end || *p++ *q++
dec esi ;*p *q
mov edi, key
mov eax, esi
lea edi, [edi]KEY.key_data
sub eax, edi ;prefix = p - key-key_data
L4: cmp dword ptr[ebx+2], -2;if ((*(int*)node-btn_number) ==
-2)
jz LN ;return NULL
movzx edi, [ebx]BTN.btn_length
lea ebx, [ebx]BTN.btn_data
add ebx, edi ;node = (BTN) (node-btn_data + node-btn_length);
jmp L0
L2: ;while (1) if (descending !retrieval)
mov edi, value ;if(value
test edi, edi
jz K3
movzx ecx, [ebx]BTN.btn_length ; (l=node-btn_length))
test ecx, ecx
jz K3
mov p, esi;{ save p
movzx esi, [ebx]BTN.btn_prefix
add edi, esi ; r = value + node-btn_prefix
lea esi, [ebx]BTN.btn_data ; q = node-btn_data
rep movsb ; do *r++ = *q++; while (--l), movsd
optimization ???
mov esi, p ;}
K3: cmp dword ptr[ebx+2], -1;if ((*(int*)node-btn_number) ==
-1) goto done;
jz DN
mov cl, [ebx]BTN.btn_prefix
cmp cl, al ;if (node-btn_prefix prefix) goto done;
jb DN
jnz K4
movzx ecx, [ebx]BTN.btn_length
test ecx, ecx ;node-btn_length 0 ;node_end - q
jz K9
mov edi, edx ;key_end
sub edi, esi ;key_end - p
cmp ecx, edi ;node_end - q ? key_end - p
jbe K8
mov ecx, edi
lea edi, [ebx]BTN.btn_data;q = node-btn_data, now EDI is q
repe cmpsb
jb DN ;*p++ *q++
dec esi ;*p *q || p == key_end
K9: mov edi, key
mov eax, esi
lea edi, [edi]KEY.key_data
sub eax, edi ;prefix = p -
Re: OFF: Разгон машины тьюринга :)))
Oleg LOA пишет: _asm маньяк, однозначно. Это с нуля писалось, или дисассемблер обточенный-оптимизированный? -- Кочмин Александр
Re: OFF: Разгон машины тьюринга :)))
Я так понимаю что после отсеивания уникальных ключей еще нужно потом по этим ключам искать? Поиск осуществляется и во время отсеивания. Когде генерируется комбинации для трех слов, нужно знать идентификаторы комбинаций для двух слов ((wordID1,wordID2),(wordID2,wordID3)) - (pairID1,pairID2) wordID1wordID2wordID3 pairID1pairID2 Коваленко Дмитрий.
Re[2]: OFF: Разгон машины тьюринга :)))
Привет! число объектов: 1100403 14786203 92189456 - две слова 380927263 - три слова 1137077468 2618853571 4870046956 7588537049 1028171 12670250189 15072709841 [54726933567] Кстати, всего получается надо сгенерировать не 350 млн, а 470 млн. Но, думаю, уникальных будет не больше 100 млн. Пляя, ну и трава у вас тут растет... Дим, кстати, а ты вообще все-все слова юзаешь (т.е. все склонения) или только начальные формы? Вроде бы использование начальных форм слегка уменьшит количество комбинаций... -- Best regards, Sergeymailto:[EMAIL PROTECTED]
Re: OFF: Разгон машины тьюринга :)))
Кстати, всего получается надо сгенерировать не 350 млн, а 470 млн. Но, думаю, уникальных будет не больше 100 млн. Пляя, ну и трава у вас тут растет... Тут такая трава, что кто вдохнет - сразу кончает от радужных перспектифф... Уборщица потом косо смотрит на пятна. Только злобного Коваленко все это уже не вдохновляет. Генераторов идей много - с исполнителями беда. Дим, кстати, а ты вообще все-все слова юзаешь (т.е. все склонения) или только начальные формы? Вроде бы использование начальных форм слегка уменьшит количество комбинаций... Да пока все в лоб хочу сделать. Что ввели, то и проиндексировали. Потом, возможно, можно будет прикрутить псевдонимы. Тут для начала стоп-слова нужно будет прикручивать. Мам, сколько еще делать надо что бы потом юзер просто и незатейливо нашел что нибуть в БД. Коваленко Дмитрий.
Re: OFF: Разгон машины тьюринга :)))
Да пока все в лоб хочу сделать. Что ввели, то и проиндексировали. Фи, батенька, да вы мазохист. Прикрути словарик - у тебя задача проще, Сережа, я за последний месяц уже столько вещей прикрутил - что крутилка требует перерыва :) Легко рассуждать о вещах, которые уже сделал :) Коваленко Дмитрий.
Re: OFF: Разгон машины тьюринга :)))
Фи, батенька, да вы мазохист. Прикрути словарик - у тебя задача проще, тебе явно только для русского языка делать надо. Возьми от опенофиса - он нашару и довольно-таки полный. У нас с дохлым словариком от ispell для русского и румынского языков для 70к документов (примерно 700 метров чистого неформатированного текста) получилось 12 с хвостиком лимонов индексных записей. При использовании влоб - было бы больше. Сейчас новый словарик прикрутим - посмотрим, что получится. Запросы работают шустро, народ слегка в ауе, коммерческая прога, которая делает аналогичные вещи, тормознутее примерно в 60 раз и полнотекстового поиска в ней нету :)) А идея вашей проги такая же как у Димы? Т.е. если идет поиск по фразе, то делается джойн таблицы на себя саму? Или же немного хитрее? Роман
Re[2]: OFF: Разгон машины тьюринга :)))
Привет! А идея вашей проги такая же как у Димы? Т.е. если идет поиск по фразе, то делается джойн таблицы на себя саму? Или же немного хитрее? Ща спою :) Так вот, вкратце о задаче: имеется база нормативных актов (ну вообще-то это типа эталон, но у меня волосы дыбом встали, когда я увидел данные, которые надо было импортировать). Всего в базе около 7 тысяч документов (примерно по 35к на каждом языке). Общий объем текстовых данных - с выкинутым форматированием HTML - около 700 метров, с форматированием - почти полтора гига. Документы имеют кучу всяких признаков - эмитент, источник публикации (не знаю как у вас, а у нас закон вступает в силу только после публикации в особом журнале - Официальном Мониторе), дату вступления в силу (он может вступать в силу через год, например) и кучу всяких параметров (гораздо больше, чем это выставленно наружу). Но самая большая проблема до сих пор была в том, что поиск по ключевым фразам делался только в заголовке и строго по введенному слову - т.е. там был обычный фуллскан на containing в заголовке (на мускуле). Перед нами была поставлена задача прикрутить туда полнотекстовый поиск (с некоторыми ограничениями, об этом ниже). Сейчас это все работает в тестовом режиме ( по адресу http://lex.justice.md/ можно увидеть, только переключить язык не забудьте). Сразу скажу, почему не прикрутили MnogoSearch - дело в том, что помимо вебовского интерфейса нам надо сделать прогу, с такой же мордой, но которую можно было бы юзать независимо от Инета - хотя обновляться, разумеется, по нему родимому придется. Прога под винду. Mnogosearch под винду во-первых платный (я хочу посмотреть, как наши госконторы заплатят за непонятно какую лицензию), во-вторых мы бы явно не влезли в бюджет, в-третьих я боялся, что мы банально не успеем прикрутить тот же MnogoSearch. Как решили. Взяли словарики румынского и русского языков (сейчас от ispell) и загнали их в базу - т.е. конструкция типа президент президента президенту президентом и т.д. была побита на пары (NF, WF1), (NF, WF2), ... где NF - контрольная сумма (CRC32) начальной формы (президент), а WFn - это контрольные суммы всех производных от начальной формы, допустимых по правилам конкретного языка. Итого, в словарике имеем почти миллион записей. Затем парсер разбивает очищенный документ на слова, слова меньше 3-х символов игнорируются (таким образом бОльшая часть слов-связок в румынском просто пропускается). Как непаханное поле для оптимизации мы оставили выкидывание всяких слов, которые не несут смысловой нагрузки, но больше 3-х символов (для русского языка, это будет например, потому и т.д.). После этого, все варианты слов заменяются на нормальную форму для данного слова - разумеется, то, что не попадает в словарик (какой-нибудь специфический термин или слово, написанное с АшиПкой) - считается нормальной формой самого себя. Так как нам не требовалось хранить ВСЕ вхождения ВСЕХ слов во ВСЕ документы, то для каждого документа мы во-первых храним лишь количество таковых вхождений и первые три вхождения - позиции слов - чтобы можно было выкусывать цитаты. Это слегка позволило сэкономить количество поисковых индексов - всего, например, для документов на русском языке в телах документов содержится 15 768 228 слов (для румынского языка 18 528 190, но там слов-связок много больше) (имеется ввиду все вхождения - и нормальных форм и их производных), тогда как всего индексных записей - чуть более 12 000 000 для обоих языков - т.е. почти троекратная экономия за счет некоторого упрощения функциональности, которая в нашем случае нафиг не нужна. ФФсе, полнотекстовый поиск готов. Да, а где временные виртуальные таблицы? ;-) А вот где. Когда пользователь вводит ключевые слова, для каждого ключевого слова ищется его нормальная форма. В результате имеется набор чисел. И строится вот такой простой запрос (в качестве ключевых слов использовалось президенту республики молдова - регистр значения не играет), запрос уже с подставленными значениями, привожу первый из запросов, второй ничем, кроме списка полей вместо count() не отличается, кому интересно - гляньте в исходники страницы после выдачи результатов, они идут в виде комментариев: Подсчет количества найденных документов (ну вот захотелось им такую фичу и все): select count(d.id) from t_documents d, (select w.document_id, count(1) as cnt from t_search_words w, ( select 2624961196 as wrd from rdb$database union select 1902388292 as wrd from rdb$database union select 1228066714 as wrd from rdb$database ) t1 where w.lang_id=2 and w.flag=1 and w.word=t1.wrd group by 1 order by 2 desc ) idx where d.lang_id=2 and d.published_when='01.07.2002' and d.published_when='02.07.2007' and d.publisher_id =36149 and d.id=idx.document_id and idx.cnt=3 Тут все просто - виртуальную табличку, в которой содержатся слова для поиска объединяем с поисковыми индексами, а результат объединения - объединяем с таблицей с документами. Указание
Re: OFF: Разгон машины тьюринга :)))
Sergey Mereutsa wrote: З.Ы. 2 ДЕ или Влад - а лимит на количество записей в одной таблице сейчас какой? Большой. Очень :-) Единственная реальная проблема - после 2 млрд записей завернется результат count-а, который пока еще 4-байтовый. -- Дмитрий Еманов
Re: OFF: Разгон машины тьюринга :)))
А идея вашей проги такая же как у Димы? Т.е. если идет поиск по фразе, то делается джойн таблицы на себя саму? Или же немного хитрее? Ща спою :) ... Спасибо! Вопрос - ты считал количество колизий для CRC32? Большое оно? Если кто сможет указать более оптимальный вариант запроса - и такой же понятный - буду очень признателен. См. сюда - http://www.intelligententerprise.com/011024/416analytic1_2.jhtml поиск делается с помощью SELECT a.docid FROM index a, query b WHERE a.term = b.term GROUP BY a.docid HAVING COUNT(*) = tand value т.е. твое решение такое же как там, так что думаю, что твой запрос оптимален. Роман
Re: OFF: Разгон машины тьюринга :)))
On 2 июл, 16:58, Kovalenko Dmitry [EMAIL PROTECTED] wrote: Есть множество пар (ID1, ID2). Их общее число где-то 350 лимонов. Уникальных - 100 лимонов. Нужно получить это множество уникальных пар. ID это целые числа. Начинаются с 1 и заканчиваются, полагаю, в районе 100 лимонов. Есть ещё одно правило - ID1 строго меньше ID2. Которое, возможно, сможет оптимизировать конструкцию индекса. Звучит как отсортировать 350М 64-битных значений и выкинуть дубликаты - я правильно понял? Сейчас сгенерил 4ГБ файл, отсортировал его кусками по 512М (на машине у меня всего гиг стоит :-((( ) и слил куски с одного винчестера на другой, получил 50 минут (если не считать генерацию файла). Машина PIV 4 GHz с включёным гипертредингом. Можно параллельно закачивать и сортировать в памяти 2 куска, а в процессе записи сливать их в один гигабайтный файл. Процентов на 30 время сократится. Или задача именно поддерживать индекс отсортированным в процессе генерации пар?
Re: OFF: Разгон машины тьюринга :)))
Есть множество пар (ID1, ID2). Их общее число где-то 350 лимонов. Уникальных - 100 лимонов. Звучит как отсортировать 350М 64-битных значений и выкинуть дубликаты - я правильно понял? Нет не правильно. Точнее правильно, но не совсем. Для пар слов - так оно и есть. Для комбинаций из трех слов, сначало формируется две пары (WordID1,WordID2), (WordID2,WordID3) потом этим парам назначается идентификатор pairID1, pairID2 эти идентификаторы объединяются в новую пару - (pairID1,pairID2) и она снова добавляется в индекс. Если добавилась, значит пара уникальная - и ей присваивается индекс pairID3. Если не добавилась - значит такая комбинация из трех слов уже была и берется существующий индекс. Конечно, эту последовательность можно свести к сортировке. Но тогда потребуется два прохода по всем объектам. А этого хочется избежать. Реально, конечно, можно вообще забить на тот клиентский индекс, который я хочу построить - просто регистрировать пары в базе и не парится. К этому, кажется все и идет :) ... детей не люблю, но сам процесс ... Или задача именно поддерживать индекс отсортированным в процессе генерации пар? Ага. Коваленко Дмитрий.
Re: OFF: Разгон машины тьюринга :)))
Машина PIV 4 GHz с включёным гипертредингом. ~~~ Гы. А штатная частота какая? Коваленко Дмитрий.
Re: OFF: Разгон машины тьюринга :)))
Kovalenko Dmitry wrote: Я бы сделал работу следующим образом: поток-читатель считывает из базы блок данных и передаёт его на обработку второму потоку через PostThreadMessage (по старинке) или QueueUserAPC (по современному). Размер блока данных подбирается чтобы его обработка занимала примерно полсекунды. Я это сделал через буфер обмена, защищенным критческой секцией. Тогда не понятно в чём может быть затык. Ты бы лучше куски кода постил, а то телепатия нынче редкость. - Послушал как работает машина (в натуре на слух), и понял - нужно нафиг отключить буферизацию файловых операций. То бишь указал флаги FILE_FLAG_WRITE_THROUGH, FILE_FLAG_NO_BUFFERING Ага. Именно назад, к природе. А ты ещё на IBAPI бочку катил ;) На самом деле FILE_FLAG_WRITE_THROUGH имеет смысл для увеличения надёжности и когда памяти в компе мало. Если памяти много, то этот флаг лучше не ставить. FILE_FLAG_NO_BUFFERING я вообше не понимаю чем тут может помочь. отказаться от мелких блоков, а перейти к блокам занимающим всю страницу целиком. Продолбенился над реализацией целый день. Получилось красиво. И - о чудо! У меня многопоточная реализация стала работать вровень с однопоточной. Ну что и следовало доказать. При увеличении размера блоков издержки на синхронизацию в процентном отношении падают. Напомню, мне нужно построить уникальный индекс для (по последним прогнозам) 100 лимонов элементов вида (ID1, ID2). Максимум что я смог осилить - 20 лимонов. Что значит осилить? Какая цель то? -- --- Home Page http://ok.novgorod.net/ap ---
Re: OFF: Разгон машины тьюринга :)))
Смотря какая природа у этого варианта. У меня сейчас два потока работают - один грузит данные из базы - второй эти данные обрабатывает. В идеале первый поток не нужен. Странные у тебя идеалы :) Я бы сделал работу следующим образом: поток-читатель считывает из базы блок данных и передаёт его на обработку второму потоку через PostThreadMessage (по старинке) или QueueUserAPC (по современному). Размер блока данных подбирается чтобы его обработка занимала примерно полсекунды. Я это сделал через буфер обмена, защищенным критческой секцией. проблема в том, что первый успевает насытить буфер с исходными данными под завязку, а второй пашет как ненормальный что бы этот буфер освободить, но очень редко когда его опустошает. А проблема то в чем? Конечно, при любых алгоритмах нужно приостанавливать фетч если данные обрабатываются медленно. Он у меня приостанавливается :) У меня даже фоновый поток выгрузки модифицированных страниц может завершаться, когда у него нет работы. Правда, работой его по самую макушку заваливают. И ещё, получается что у тебя обработка данных занимает времени намного больше чем их выкачка из базы. В такой ситуации выигрышь от распараллеливания невелик в процентом отношении. Иногда буфер все таки опустошается. Это когда сервер начинает чухаться с подгрузкой нужной части данных в свой кэш. --- Вообщем, текущее положение дел с машиной тьюринга такое. - Я прикрутил фоновый поток выгрузки модифицированных страниц. - Послушал как работает машина (в натуре на слух), и понял - нужно нафиг отключить буферизацию файловых операций. То бишь указал флаги FILE_FLAG_WRITE_THROUGH, FILE_FLAG_NO_BUFFERING - Это потребовало заюзать память, выделяемую через VirtualAlloc. Типа, как завещал Великий LOA :) - Гудение винтов стало равномерным :) (кстати пару раз слышал странные щелчки) - Посмотрев на это дело, я понял что бежать больше некуда и надо доделывать менеджер кэша - в него писать не через read/write функции, а напрямую. И переделать управление хеш-таблицей - отказаться от мелких блоков, а перейти к блокам занимающим всю страницу целиком. Продолбенился над реализацией целый день. Получилось красиво. И - о чудо! У меня многопоточная реализация стала работать вровень с однопоточной. Более того - может это меня заглючило (в 3 часа ночи) - даже немного быстрее. Вообщем, системные затраты стали очень маленькими и диспетчер задач светился радостным зеленым цветом. Одним из забавных моментов была при обработке какой-то порции данных, когда общая нагрузка на процессор (HT включен) плавно поднималась с 50 до 100, там держалась, а потом плавно опускалась. Возможно это связано с увеличением числа попаданий в локальные кэши каждого потока. Хотя по правде - шайтан его знает, с чем это связано. -- Но, плят, щастье длится ровно столько сколько заполняется кэш. Напомню, мне нужно построить уникальный индекс для (по последним прогнозам) 100 лимонов элементов вида (ID1, ID2). Максимум что я смог осилить - 20 лимонов. Сейчас, для построения индекса элементов, юзаю хеш-таблицу. По формуле (ID1+ID2)/HashTableSize определяю элемент таблицы. В элементе хранится указатель на упорядоченный блочный список. Блок списка равен размеру страницы (4K). Фоновый поток выгружает самые старые модифицированные страницы. Но, судя по индикации счетчиков размеров списков чистых и грязных страниц, в эти очищенные страницы сразу же срут и они возвращаются в очередь грязных страниц. Скорость генерации очень высокая - программа только начинает работать, а уже сразу выжирает под 30-40 тысяч страниц. И дальше очень интенсивно гадит в каждую из них. После заполнения кэша (я эксперементирую с кэшем на 120 тыс четырех килобайтных страниц) производительность падает до копеечных размеров. Я пробовал останавливать потоки генерации, что бы дать выгружателю сбросить все на диск - эффект мизерный. После того как генераторы возобновляют работу - производительность не повышается и очередь грязных страниц неулонно растет. Это зарезало мою идею уменьшать приоритет генераторов при катастрофическом загрязнении кэша. Пробовал играть и с размером страниц и c HashTableSize - общая картина не улучшается. -- Мне кажется что проблема все таки в самой hash-таблице. Точнее в стоимости добавления нового элемента в существующий список. Если программа способна генерировать свыше 20 тыс уникальных комбинаций в секунду, и каждая из них попадает в свой список хеш-таблицы, то тут ничего не спасет. Я же, блин, постарался - отсортированность поддерживаю. Так что тут еще и уже заполненные блоки списков могут модифицироваться... Сейчас буду прикладывать к голове умную книжку с описанием конструкции Б-деревьев. -- Не, но многоточность я таки победил. Честное пионерское :) ... Как сложно делать простые вещи. И какими сложными они потом оказываюся :( Коваленко Дмитрий.
Re: OFF: Разгон машины тьюринга :)))
Kovalenko Dmitry ... После заполнения кэша (я эксперементирую с кэшем на 120 тыс четырех килобайтных страниц) производительность падает до копеечных размеров. Грязные страницы на диск идут в каком порядке ? Как попало ? -- Хорсун Влад
Re: OFF: Разгон машины тьюринга :)))
После заполнения кэша (я эксперементирую с кэшем на 120 тыс четырех килобайтных страниц) производительность падает до копеечных размеров. Грязные страницы на диск идут в каком порядке ? Как попало ? Угу. - Беру последнюю страницу из очереди грязных страниц. - Блокирую её от записи - Пишу на диск - Убираю из списка грязных страниц - Начинаю с начала Возможно упорядочивание как-то поможет. Это значит я должен заблокировать группу страниц, упорядочить, выгрузить... Но, кажется, проблема не в этом. Нужно компоновать данные так, что бы заполненные блоки списков хеш-таблицы больше не модифировались. Это увеличит время проверки - после заполнения кэша, возникнут ситуации с загрузкой всех блоков какого-то списка. Но модифицироваться будет только последний блок. Остальные потом вытесняться из кэша без накладных расходов. Внутри блоков поддерживать упорядоченность. Длину списков можно регулировать увеливая HashTableSize. Цена проверки гипотезы - пара часов, не больше :) (сказал русский программист, гы) Коваленко Дмитрий.
Re: OFF: Разгон машины тьюринга :)))
Oleg LOA wrote: Kovalenko Dmitry [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] как завещал Великий LOA :) Недождётесь :-) Оффну слегонца. Ты, помнится, пару раз на работу людей брал. Не сдашь координаты двойки-тройки лучших из худщих, в смысле непрошедших отбор? У меня тут, похоже, потихоньку наклёвывается вакансия. Ну по профилю - FB-Delphi, документооборот, бюстгальтэрия, планирование-буджетирование... Здешние-то, знакомые, все при делах скорей всего, а искать свободным поиском влом - это ж десятки перебрать придётся. -- Regards. Ded.
Re: OFF: Разгон машины тьюринга :)))
Oleg LOA wrote: Бюджет-то какой? Может кого сам порекомендую из знакомых. 3 месяца испытательного - $800, потом - 1500 с гарантированным ростом в обозримое время по успехам. Если всё пойдёт - до 2000 точно, а дальше уже будет зависеть не только от успешности деятельности и от меня, а и от настырности и гибкости самого человека в отношениях с боссом. Работа будет тяжелая - без ТЗ, на слух, и внутренняя дока по действующему по нулям. На вопросы по мере возможности отвечаем. Если вспоминаем. -- Regards. Ded.
Re: OFF: Разгон машины тьюринга :)))
Kovalenko Dmitry wrote: Смотря какая природа у этого варианта. У меня сейчас два потока работают - один грузит данные из базы - второй эти данные обрабатывает. В идеале первый поток не нужен. Например, если коннектится к серверу через асинхронный сокет, то достаточно обрабатывать сообщения о поступлении новых данных. Т.е. в событии OnRead сокета запрашиваем фетч следующей порции данных, обрабатываем полученную и ждём новых сообщений. Но, при работе с gds32.dll такое невозможно. Я бы сделал работу следующим образом: поток-читатель считывает из базы блок данных и передаёт его на обработку второму потоку через PostThreadMessage (по старинке) или QueueUserAPC (по современному). Размер блока данных подбирается чтобы его обработка занимала примерно полсекунды. У этих потоков одна точка соприкосновения - буфер обмена, в которых каждый проводит не очень много времени. Дело не во времени, а сколько раз в секунду происходит обращение к объектам синхронизации типа мьютеков. Даже если мьютекс свободен это достаточно дорого. проблема в том, что первый успевает насытить буфер с исходными данными под завязку, а второй пашет как ненормальный что бы этот буфер освободить, но очень редко когда его опустошает. А проблема то в чем? Конечно, при любых алгоритмах нужно приостанавливать фетч если данные обрабатываются медленно. И ещё, получается что у тебя обработка данных занимает времени намного больше чем их выкачка из базы. В такой ситуации выигрышь от распараллеливания невелик в процентом отношении. -- --- Home Page http://ok.novgorod.net/ap ---
Re: OFF: Разгон машины тьюринга :)))
Чую, без тюнера, не одалею я демона :) Угу, смотри профайлером кто в ожидании толкается. Вот еще одно интересное наблюдение. Прескотт 2.8 (стартует с 318408 уникальных комбинаций за 5 сек) работает медленее чем обычный P4-2.8 (у этого - 342917). Его не спасает даже мегабайтный кэш (у обычного 512). Я уже физически начинаю ощущать влияние сбросов конвеера процессора. Двухпоточный вариант на обычном 2.8 стартует с 178247 уникальных комбинаций. Это перекрывает желания двухдневной давности, но ну никак не соизмеримо с текущими достижениями однопоточного варианта. На реальной двухпроцессорной машине - результаты такие же. В однопоточный генератор работает быстрее двухпоточного. Я биться головой ап стену. Ускорение было достигнуто за счет локального in-memory кэшей, сохраняющих результаты генерации для последних N-объектов, для каждого потока генерации. Реально помогает. Вообщем, пока я решил пока остановиться на однопоточном генераторе и продолжить движение вперед - нужно наконец начать прикручивать фоновый поток выгрузки модифицированных страниц. Без него, как я уже писал, программа уходит в ступор при переполнении кэша. Возможно, позже я найду какую нибуть злю критичекую секцию которая и портит общую картину. Коваленко Дмитрий.
Re: OFF: Разгон машины тьюринга :)))
Kovalenko Dmitry wrote: Двухпоточный вариант на обычном 2.8 стартует с 178247 уникальных комбинаций. Это перекрывает желания двухдневной давности, но ну никак не соизмеримо с текущими достижениями однопоточного варианта. На реальной двухпроцессорной машине - результаты такие же. В однопоточный генератор работает быстрее двухпоточного. Я биться головой ап стену. На одном проце по определению однопоточный вариант будет выигрывать. Когда много процов затраты на синхронизацию достаточно велики, т.к. любая операция синхронизация требует блокировки шины и сооветственно сброса кэша. По идее пользу от многопроцевости надо реализовывать в другом месте - в параллельном выполнении запросов пользователей. -- --- Home Page http://ok.novgorod.net/ap ---
Re: OFF: Разгон машины тьюринга :)))
On Sat, 23 Jun 2007 15:23:46 +0400, Dmitri Kuzmenko [EMAIL PROTECTED] wrote: perfmon, разумеется. включаешь показ загрузки каждого проца, и смотришь. Т.е. признак только один - что оба проца загружены на 50% ? -- Сергей Смирнов.
Re: OFF: Разгон машины тьюринга :)))
Hello, WildSery! WildSery wrote: On Sat, 23 Jun 2007 15:23:46 +0400, Dmitri Kuzmenko [EMAIL PROTECTED] wrote: perfmon, разумеется. включаешь показ загрузки каждого проца, и смотришь. Т.е. признак только один - что оба проца загружены на 50% ? признак пилообразной загрузки обоих ядер/процессоров от 40 до 60%. и по графику загрузки процов видно, что загрузка перескакивает с одного на другой. Пилообразный такой график. правда, если честно, вот сейчас у себя попробовал, что-то FB суперсервер никак не хочет перескакивать, все время одно ядро грузит. -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Re: OFF: Разгон машины тьюринга :)))
Dmitri Kuzmenko wrote: правда, если честно, вот сейчас у себя попробовал, что-то FB суперсервер никак не хочет перескакивать, все время одно ядро грузит. У него же affinity по дефолту включен. -- Дмитрий Еманов
Re: OFF: Разгон машины тьюринга :)))
правда, если честно, вот сейчас у себя попробовал, что-то FB суперсервер никак не хочет перескакивать, все время одно ядро грузит. У него же affinity по дефолту включен. Хитрый Еманов :) Коваленко Дмитрий.
Re: OFF: Разгон машины тьюринга :)))
Hello, Dmitry! Dmitry Yemanov wrote: правда, если честно, вот сейчас у себя попробовал, что-то FB суперсервер никак не хочет перескакивать, все время одно ядро грузит. У него же affinity по дефолту включен. дык я аффинити менял на 1, 2 и 3. все время только одно ядро занято. правда, я на count проверял. может в этом дело. или нынче xp sp2 + двухядерники амд стали дуже вумные. -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Re: OFF: Разгон машины тьюринга :)))
Kovalenko Dmitry [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] правда, если честно, вот сейчас у себя попробовал, что-то FB суперсервер никак не хочет перескакивать, все время одно ядро грузит. У него же affinity по дефолту включен. Хитрый Еманов :) Дима этой фичи сто лет в обед ;-)
Re: OFF: Разгон машины тьюринга :)))
У него же affinity по дефолту включен. Хитрый Еманов :) Дима этой фичи сто лет в обед ;-) Да понятно, понятно. Это я так, стебаюсь... в перерывах между сражениями. Вчера вечером, на домашнем компе (прескотт 2.8) добился генерации 170 тыс комбинаций за первые 5 сек. Утром на работе на (обычный P4 2.4) довел до 150 тыс за то зе время. Потом ради интереса попробовал на соседнем компьютере (обычный P4 2.8, там же стоит и сервер), и обалдел - 270 тыс. (На самом первом варианте машины тьюринга я довольствовался 50-70 тысячами) Но, блин, везде, как только второй поток запускаешь - производительность падает в 1.5-2 раза. Кто-то, где-то проваливается на уровень системы, пока ждет :( Чую, без тюнера, не одалею я демона :) Коваленко Дмитрий.
Re: OFF: Разгон машины тьюринга :)))
Гы-гы-гы. В 99 мой товарищ защищал диплом по теме Параллельные алгоритмы. Ему 1 балл сняли за неактуальность и отсутствие практических применений непосредственно в области информационных технологий - он выпуклую оболочку в тредах считал. Это типичная проблема, когда люди не могут объяснить - а на хрена это все надо? Суть хохмы в том, что в _следующем_ году был введен в универе курс Параллельные Алгоритмы. На той же кафедре. Курс обязательный. Вот такие вот делы... :) Ну значит не пропал его тяжкий труд :) Коваленко Дмитрий.
Re: OFF: Разгон машины тьюринга :)))
Hello, Sergey! Sergey Mereutsa wrote: Назови хоть одну игру, которая использует ДВА ядра или процессора. Сталкер - и тот только 1 проц юзает. Это проблемы Сталкера. У нормальных игр в среднем 7-11 потоков. У нас пока 7 :) У клиента. я имел в виду совсем другие игры - action, fps, tps и так далее. З.Ы. Кстати, квака третья была чуть ли не первой игрой, которая могла юзать 2 проца. Контра сурсовая может. :) контра - не может. только что запустил - перебрасывается с одного проца на другой, аки суперсервер. макс загрузка каждого проца - ~50%. и опять же. наличие тредов, как известно, не говорит о том что доп. ядра или процессоры будут использоваться полноценно. назови мне хоть одну массовую динамическую игру с хорошей графикой, которая будет 1. грузить одно из ядер на 100% 2. грузить второе ядро хотя бы на 10%. -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Re[2]: OFF: Разгон машины тьюринга :)))
Привет! я имел в виду совсем другие игры - action, fps, tps и так далее. З.Ы. Кстати, квака третья была чуть ли не первой игрой, которая могла юзать 2 проца. Контра сурсовая может. :) контра - не может. только что запустил - перебрасывается с одного проца на другой, аки суперсервер. макс загрузка каждого проца - ~50%. Там 16 тредов. Ты точно сурсовую запустил? Которая на HL2? и опять же. наличие тредов, как известно, не говорит о том что доп. ядра или процессоры будут использоваться полноценно. Согласен. Это зависит, чего они в этих тредах делают. назови мне хоть одну массовую динамическую игру с хорошей графикой, которая будет 1. грузить одно из ядер на 100% 2. грузить второе ядро хотя бы на 10%. Хммм, а разве это не задача операционки - размазать нагрузку равномерно по всем имеющимся вычислительным мощностям? И, кстати, как ты смотришь, что тред скачет с одного проца на другой? Вернее, чем смотришь? -- Best regards, Sergeymailto:[EMAIL PROTECTED]
Re: OFF: Разгон машины тьюринга :)))
Т.е. у нас SS на Linux/Solaris нормально поддерживает SMP? Просто он там плохо скалируется? Он никак не скалируется :-) Всегда один активный поток на всех платформах. Называть отсутствие пинг-понга между камнями поддержкой SMP я бы не стал :-) Хммм... а где этот мистический scheduler живет? Это наши любимые THREAD_EXIT() и THREAD_ENTER()?
Re: OFF: Разгон машины тьюринга :)))
Dmitry Yemanov wrote: Roman Rokytskyy wrote: Т.е. у нас SS на Linux/Solaris нормально поддерживает SMP? Просто он там плохо скалируется? Он никак не скалируется :-) Всегда один активный поток на всех платформах. Называть отсутствие пинг-понга между камнями поддержкой SMP я бы не стал :-) Да на нынешних линуксах я бы и об абсолютном отсутствии пинг-понга уверенно говорить не стал, всё течёт, всё изменяется. Понаблюдал я тут как-то малехо в top за поведением системы, когда ей нехрен делать, то есть, работает один сиротливый процесс классики, а три камня скучают. Лижет, зараза, себе ети, лижет. Не так чтоб гоняет его, как вшивого по бане, но раз в минуту-две перекидывает таки его с одного камня на другой. Под нагрузкой вроде нет такого. -- Regards. Ded.
Re: OFF: Разгон машины тьюринга :)))
Hello, Sergey! Sergey Mereutsa wrote: контра - не может. только что запустил - перебрасывается с одного проца на другой, аки суперсервер. макс загрузка каждого проца - ~50%. Там 16 тредов. Ты точно сурсовую запустил? Которая на HL2? натюрлих. у меня она уже давно купленная, именно вместе с HL2 . Может ты путаешь с сервером? я еще раз подчеркиваю - в супере FB тоже дохренища тредов. Толку-то? Мультитредовость и SMP - необязательно одинаковые вещи. назови мне хоть одну массовую динамическую игру с хорошей графикой, которая будет 1. грузить одно из ядер на 100% 2. грузить второе ядро хотя бы на 10%. Хммм, а разве это не задача операционки - размазать нагрузку равномерно по всем имеющимся вычислительным мощностям? да. это ее задача. вопрос ведь в синхронизации тредов. Возьми пример из дельфей про сортировки в тредах - он будет распараллеливаться на 100%, и работать строго на разных процах. Это ведь тот же самый вопрос, который я задавал по поводу реализации доступа к одному коннекту из разных тредов в IBProvider. В общем случае такая задача бессмыслена, т.к. все упрется в синхронизацию доступа к коннекту, и аналогичное происходит в супере FB, играх и т.п. Разве что сталкер не перебрасывается по процам, а сидит на одном, оставляя второй свободным. И, кстати, как ты смотришь, что тред скачет с одного проца на другой? Вернее, чем смотришь? perfmon, разумеется. включаешь показ загрузки каждого проца, и смотришь. разумеется, смотришь, если у тебя 2 монитора. :-) У меня DualView, поэтому я могу перфмон положить на один монитор, а кс и т.п запускать на другом :-) -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Re: OFF: Разгон машины тьюринга :)))
Roman Rokytskyy wrote: Хммм... а где этот мистический scheduler живет? Это наши любимые THREAD_EXIT() и THREAD_ENTER()? Именно. Сам код в /jrd/sch.cpp. -- Дмитрий Еманов
Re: OFF: Разгон машины тьюринга :)))
ИГРЫ. ты совсем забыл про игры. Вот им 4 ядра уже хорошо. и как раз вот в играх-то до сих пор разрабам не совсем ясно, чего можно распараллеливать. Были когда-то эксперименты, еще при появлении двухпроцессорных машин, доступных для десктопов. И то разрабы отказались. Необходимость синхронизации убивает всю распараллеливаемость. Я так понимаю, параллельные вычисления ИГР переместиласть на уровень видеокарт... Коваленко Дмитрий.
Re: OFF: Разгон машины тьюринга :)))
On Fri, 22 Jun 2007 10:14:28 +0400, Kovalenko Dmitry [EMAIL PROTECTED] wrote: Я так понимаю, параллельные вычисления ИГР переместиласть на уровень видеокарт... AI и физику пока видеокарты не считают. -- Сергей Смирнов.
Re: OFF: Разгон машины тьюринга :)))
Я так понимаю, параллельные вычисления ИГР переместиласть на уровень видеокарт... AI и физику пока видеокарты не считают. Я про обсчет графики. Коваленко Дмитрий.
Re: OFF: Разгон машины тьюринга :)))
Отследить такое не сложно. Но вопрос - а что делать? Формально это Видал в логе IB сообщения от блокировщика о то что жопа ;-), вот и ты также пиши в лог. Вот еще вопросик по существу ... Я так понимаю, в архитектуре супер сервера нет жесткой привязки потока к коннекту. То бишь, если поток простаивает (клиент уснул на пару часов), сервер может его заюзать под другого (например, нового, клиента). Как следствие, если старый клиент оживился, то ему могут отдать совершенно другой поток? Это я к чему. Если - клиент заблокировал некий ресурс внутрях сервера (поток A) (поток1) - потом пошел курить - вернулся к работе (поток2) то использование мьютексов (которые имеют внутреннюю привязку к потоку) для долгоиграющих блокировок ресурсов категорически запрещено... То есть владелеца ресурса нужно определять на логическом уровне - ID- клиента, а не ID-потока. Коваленко Дмитрий.
Re: OFF: Разгон машины тьюринга :)))
А я вот как эту проблему озвучу. Кто получал высшее образование по IT-специальностям. Сколько часов в соответствующих предметах было посвящено архитектуре сиситем ориентированных на параллельное выполнение задач? Вот то-то и оно (С). Параллельные вычисления - 34 Нейрокомпьютерные системы и параллельные вычисления - 36 Параллельное программирование - 42
Re: OFF: Разгон машины тьюринга :)))
Kovalenko Dmitry wrote: Я так понимаю, в архитектуре супер сервера нет жесткой привязки потока к коннекту. Привязка есть, но только на время обработки конкретного API-вызова. То бишь, если поток простаивает (клиент уснул на пару часов), сервер может его заюзать под другого (например, нового, клиента). Как следствие, если старый клиент оживился, то ему могут отдать совершенно другой поток? Так точно. владелеца ресурса нужно определять на логическом уровне - ID- клиента, а не ID-потока. Лок-менеджер так и делает. -- Дмитрий Еманов
Re: OFF: Разгон машины тьюринга :)))
On Fri, 22 Jun 2007 12:04:20 +0400, Kovalenko Dmitry [EMAIL PROTECTED] wrote: Я так понимаю, параллельные вычисления ИГР переместиласть на уровень видеокарт... AI и физику пока видеокарты не считают. Я про обсчет графики. Хочешь сказать, что других параллельных вычислений, кроме графики, в играх нет? -- Сергей Смирнов.
Re: OFF: Разгон машины тьюринга :)))
Я так понимаю, в архитектуре супер сервера нет жесткой привязки потока к коннекту. Привязка есть, но только на время обработки конкретного API-вызова. Слушай, а где у нас проблема с многопоточностью, т.е. с тем, что Птицу надо к конкретному процессору привязывать? Роман
Re: OFF: Разгон машины тьюринга :)))
Oleg LOA wrote: А я вот как эту проблему озвучу. Кто получал высшее образование по IT-специальностям. Сколько часов в соответствующих предметах было посвящено архитектуре сиситем ориентированных на параллельное выполнение задач? Вот то-то и оно (С). Примерно... мнее... в одна тысяча девятьсот семдесят третьем году... мнее... один преподаватель, ну, скажем, мнее... Полуэкт... помнится, минут эдак... мнее... десять... что-то говорил про этот... мнее... Крей... -- Regards. Ded.
Re: OFF: Разгон машины тьюринга :)))
Я так понимаю, параллельные вычисления ИГР переместиласть на уровень видеокарт... AI и физику пока видеокарты не считают. Я про обсчет графики. Хочешь сказать, что других параллельных вычислений, кроме графики, в играх нет? Я хочу сказать про кучу конвееров графического процессора. Коваленко Дмитрий.
Re: OFF: Разгон машины тьюринга :)))
Oleg LOA [EMAIL PROTECTED] сообщил/сообщила в новостях следующее: news:[EMAIL PROTECTED] Dmitry Voroshin [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] А я вот как эту проблему озвучу. Кто получал высшее образование по IT-специальностям. Сколько часов в соответствующих предметах было посвящено архитектуре сиситем ориентированных на параллельное выполнение задач? Вот то-то и оно (С). Параллельные вычисления - 34 Нейрокомпьютерные системы и параллельные вычисления - 36 Параллельное программирование - 42 Вот то-то и оно (с). Что можно наизучать за столько часов ;-);-);-) Да тут даже дело не в количестве часов, а в квалификации преподавателей. Разве квалифицированный специалист будет прподавать за такую зарплату? Даже если часы в 5 раз увеличить - результат то-же будет. Только воды в курсе прибавится...
Re: OFF: Разгон машины тьюринга :)))
Hello, WildSery! WildSery wrote: On Fri, 22 Jun 2007 10:14:28 +0400, Kovalenko Dmitry [EMAIL PROTECTED] wrote: Я так понимаю, параллельные вычисления ИГР переместиласть на уровень видеокарт... AI и физику пока видеокарты не считают. Даже если вспомнить провальную пока Ageia, то все равно абстрактный параллельный обсчет физики никому не нужен. Допустим, нечто на экране взрывается. Мало того что физику надо обсчитать. Это же надо еще и показать. Поэтому обсчет получается сильно дискретный или сильно синхронизируемый. Это примерно то же самое что и распараллеливание запросов. Например, два запроса в union мы можем раскидать по разным процессорам. Но. Если запрос 1 выполняется много быстрее запроса 2, то один из процов будет в простое. И если это UNION а не UNION ALL, то опять же все упрется в конечную сортировку результата. То есть, эффективно распараллеливать такие задачи можно только когда есть какие-то вычисления, которые могут выполняться фоном и не требуют частой синхронизации с основной частью приложения. Например в СУБД. -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Re: OFF: Разгон машины тьюринга :)))
Roman Rokytskyy wrote: Слушай, а где у нас проблема с многопоточностью, т.е. с тем, что Птицу надо к конкретному процессору привязывать? Винда не знает о том, что у нас ручной шедулер, и бесполезно переключает потоки между камнями, несмотря на то, что только один поток активен в каждый момент времени. Привязка к конкретному процу эту бяку обходит. На линухе такой проблемы не наблюдалось. -- Дмитрий Еманов
Re: OFF: Разгон машины тьюринга :)))
Hello, WilSery! WildSery wrote: Я так понимаю, параллельные вычисления ИГР переместиласть на уровень видеокарт... AI и физику пока видеокарты не считают. физику уже считают. на картах NVidla уже можно считать распространение звуковых волн и др. задачи. Причем в десятки если не в сотни раз быстрее чем на нынешних процах. -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Re[2]: OFF: Разгон машины тьюринга :)))
Привет! Я так понимаю, параллельные вычисления ИГР переместиласть на уровень видеокарт... AI и физику пока видеокарты не считают. По поводу AI - да, а по поводу физики мусье глубоко заблуждается :) -- Best regards, Sergeymailto:[EMAIL PROTECTED]
Re[2]: OFF: Разгон машины тьюринга :)))
Привет! ИГРЫ. ты совсем забыл про игры. Вот им 4 ядра уже хорошо. Назови хоть одну игру, которая использует ДВА ядра или процессора. Сталкер - и тот только 1 проц юзает. Это проблемы Сталкера. У нормальных игр в среднем 7-11 потоков. У нас пока 7 :) У клиента. З.Ы. Кстати, квака третья была чуть ли не первой игрой, которая могла юзать 2 проца. Контра сурсовая может. :) -- Best regards, Sergeymailto:[EMAIL PROTECTED]
Re[2]: OFF: Разгон машины тьюринга :)))
Привет! А я вот как эту проблему озвучу. Кто получал высшее образование по IT-специальностям. Сколько часов в соответствующих предметах было посвящено архитектуре сиситем ориентированных на параллельное выполнение задач? Вот то-то и оно (С). Гы-гы-гы. В 99 мой товарищ защищал диплом по теме Параллельные алгоритмы. Ему 1 балл сняли за неактуальность и отсутствие практических применений непосредственно в области информационных технологий - он выпуклую оболочку в тредах считал. Суть хохмы в том, что в _следующем_ году был введен в универе курс Параллельные Алгоритмы. На той же кафедре. Курс обязательный. Вот такие вот делы... :) -- Best regards, Sergeymailto:[EMAIL PROTECTED]
Re: OFF: Разгон машины тьюринга :)))
Слушай, а где у нас проблема с многопоточностью, т.е. с тем, что Птицу надо к конкретному процессору привязывать? Винда не знает о том, что у нас ручной шедулер, и бесполезно переключает потоки между камнями, несмотря на то, что только один поток активен в каждый момент времени. Привязка к конкретному процу эту бяку обходит. Хммм... понятно, что ничего непонятно :) Ну значит будет повод тебе в Праге пиво купить, чтоб ты мне это на бумажке нарисовал :) На линухе такой проблемы не наблюдалось. Т.е. у нас SS на Linux/Solaris нормально поддерживает SMP? Просто он там плохо скалируется? Роман
Re: OFF: Разгон машины тьюринга :)))
Roman Rokytskyy wrote: Т.е. у нас SS на Linux/Solaris нормально поддерживает SMP? Просто он там плохо скалируется? Он никак не скалируется :-) Всегда один активный поток на всех платформах. Называть отсутствие пинг-понга между камнями поддержкой SMP я бы не стал :-) -- Дмитрий Еманов
Re: OFF: Разгон машины тьюринга :)))
Hello, Oleg! Oleg LOA wrote: и много сейчас софта, написанного правильно и могущего использовать многопроцессорность? ну или хотя бы такого, которому многопроцессорность не мешает. Да вагон. У меня вот моя вот художествами занимается на компе. Специальну купил последний многоядерник - так достаточно оказалось программ кторые эффективно используют всё это дело. художества - может быть. А вот у меня на компе вообще ничего нет кроме IB/FB что могло бы многоядерность использовать. -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Re: OFF: Разгон машины тьюринга :)))
Hello, Oleg! Oleg LOA wrote: Dmitri Kuzmenko [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] художества - может быть. А вот у меня на компе вообще ничего нет кроме IB/FB что могло бы многоядерность использовать. Word тоже не используешь совсем :-) с какого рожна он два ядра будет использовать? -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Re: OFF: Разгон машины тьюринга :)))
Dmitri Kuzmenko wrote: Word тоже не используешь совсем :-) с какого рожна он два ядра будет использовать? От скорости тайпинга сильно зависит. Сам видишь - у Олега по три очепятки в предложении минимум, 3500 знаков в минуту - эт те не хрен собачий ;) -- Regards. Ded.
Re: OFF: Разгон машины тьюринга :)))
художества - может быть. А вот у меня на компе вообще ничего нет кроме IB/FB что могло бы многоядерность использовать. Word тоже не используешь совсем :-) с какого рожна он два ядра будет использовать? Чтобы врагу не достались :) Коваленко Дмитрий.
Re: OFF: Разгон машины тьюринга :)))
Hello, Aleksey! Aleksey Karyakin wrote: А у тебя одно ядро на сколько процентов используется, интегрально за сутки? у меня то оба на 100% используются круглые сутки :-) потому что у меня работает boinc, считает seti_at_home и Эйнштейна. кроме того, система ведь треды и приложения кидает на ядра как попало. собственно, у меня до этого был AMD 3500, который 2200мгц, разогнанный до 2535мгц. Сейчас AMD X2 5200, тактовая 2600мгц. Т.е. по частоте недалеко. Кэш понятно в 2 раза больше, у каждого ядра. И фокус в том, что особого повышения производительности я не заметил (этого в общем следовало ожидать). Винды (XP Prof) грузятся примерно с той же скоростью. Все приложения работают примерно так же. Могу повторить backupspeed тест просто чтобы проверить насколько ускорилось. Ну а там можно и скорость бэкапа на двух ядрах проверить - gbak + fbserver. но я это к тому, что на десктопе загрузить оба ядра пока реально нечем (кроме всяких видео-дел). А на десктоп уже по 4 ядра суют. и кто их будет грузить, я вообще не понимаю. Ясное дело что можно запустить какой-нибудь рендеринг, бэкап, архивацию, и спокойно работать дальше. Хотя про спокойно - это я зря. Спокойно будет если эти процессы не упираются в один диск. У меня-то их ТРИ. А на стандартном десктопе он ОДИН. Тут у меня знакомый, не рубящий в компах, хотел купить себе систему. Заказал пальцато - проц за 7к руб, и т.п., и ОДИН диск SATA. Он собрался видеомонтажом на этом компе заниматься. Вовремя успели втолковать ему про диски... -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Re: OFF: Разгон машины тьюринга :)))
Hello, Oleg LOA said the following on 20.06.2007 12:36: Пример - криво написанный супер не может использваоть многопроцессорыне мощности. А правильная лаба по сортировке на потоках может :-):-):-) Плохому программисту ядра мешают... -- Oleg
Re: OFF: Разгон машины тьюринга :)))
Dmitri Kuzmenko пишет: но я это к тому, что на десктопе загрузить оба ядра пока реально нечем (кроме всяких видео-дел). А на десктоп уже по 4 ядра суют. и кто их будет грузить, я вообще не понимаю. ИГРЫ. ты совсем забыл про игры. Вот им 4 ядра уже хорошо. -- Кочмин Александр
Re: OFF: Разгон машины тьюринга :)))
Oleg Deribas wrote: Плохому программисту ядра мешают... А у хорошего, вона, 24 часа в сутки работают 8-O -- Regards. Ded.
Re: OFF: Разгон машины тьюринга :)))
Hello, Alexandr! Kochmin Alexandr wrote: но я это к тому, что на десктопе загрузить оба ядра пока реально нечем (кроме всяких видео-дел). А на десктоп уже по 4 ядра суют. и кто их будет грузить, я вообще не понимаю. ИГРЫ. ты совсем забыл про игры. Вот им 4 ядра уже хорошо. Александр, вот честное слово, не грубости ради, а только для красоты эпитета - ты с дуба рухнул? :-) Назови хоть одну игру, которая использует ДВА ядра или процессора. Сталкер - и тот только 1 проц юзает. -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Re: OFF: Разгон машины тьюринга :)))
Hello, Alexandr! Kochmin Alexandr wrote: ИГРЫ. ты совсем забыл про игры. Вот им 4 ядра уже хорошо. и как раз вот в играх-то до сих пор разрабам не совсем ясно, чего можно распараллеливать. Были когда-то эксперименты, еще при появлении двухпроцессорных машин, доступных для десктопов. И то разрабы отказались. Необходимость синхронизации убивает всю распараллеливаемость. -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34 --~--~-~--~~~---~--~~ Данное сообщение отправлено Вам, так как Вы являетесь подписчиком группы gmane.comp.db.firebird.russian на группах Google. Для того, чтобы отправить сообщение в эту группу, пошлите его по адресу ru-firebird@googlegroups.com Чтобы отменить подписку на эту группу, отправьте сообщение по адресу: [EMAIL PROTECTED] Дополнительные варианты находятся на странице группы http://groups.google.com/group/ru-firebird?hl=ru -~--~~~~--~~--~--~---
Re: OFF: Разгон машины тьюринга :)))
Hello, Oleg! You wrote on Thu, 21 Jun 2007 12:30:36 +0400: OL Осталось найти точную границу между обычной и необычной OL работой, и наступит эра сплошного телевидения. :) OL Обычная работа, это работа без постоянного изменения OL метаданных. Помоему в контексте обсуждения кэша OL метаданных это очевидно. Ну да, слона-то я... -- Удач Alexander A. Venikov, Tobolsk, Russia
Re: OFF: Разгон машины тьюринга :)))
Привет. Отследить такое не сложно. Но вопрос - а что делать? Формально это Видал в логе IB сообщения от блокировщика о то что жопа ;-), вот и ты также пиши в лог. Посколько в этой ветке только ты (да DED) не отговаривают меня возится с этой затеей, собственно с тобой и буду делиться мыслями :)) Я тут оценил красоту управления многопоточностью через менеджеры блокировки. Оказывается, для безблокировочной работы кэша нужно как минимум два менеджера - первый для блокировки элемента кэша. Это типа фундамент, координирующий внешнюю работу. - второй для блокировки индекса страницы, пока она привязывается к элементу кэша. Если два потока одноврененно начнут биндиться к одному сегменту, то их нужно снхронизировать. второй менеджер обеспечивает параллельный поиск двух сегментов в кэше. Может это я загнался ... хотя если страница в кэше не найдена и начинает грузиться из файла, то второй поток (которому нужна другая страница) в принципе сможет продолжать работать с кэшем. Формально, можно даже параллельно грузить разные страницы в разные части кэша. Так вот. Я тут накатал каркас кода управляющего кода. И меня привлекла одна вещь - нет никаких проблем с параллельной выгрузкой модифицированных страниц на диск. То есть служебных потоков, которые возятся с выгрузкой, может быть больше одного! Им всего-то нужен еще один менеджер блокировок. А глобально получаем, что есть пул объектов чтения-записи файла (каждый со своим персональным file_handle). И когда нам нужно прочитать-записать - мы просто берем из этого пула свободный объект. В натуре это выглядит как классик-сервер на потоках :))) Короче, я в восторге. Это еще раз укрепило мою уверенность, в том что мой следующий домашний агрегат будет как минимум четырех-ядерный :)) Коваленко Дмитрий.
