199 ответов в теме

[JesDarkJewel]

Символ текста - 8 или 16 бит.
1024 бита - зачем нужно такое извращение - не понятно, просто Трим опять, что называется, ляпнул, а вы повелись обсуждать

для порядкового номера атома во вселенной 1024 битные ID пригодятся.

[Yaponiz]

Но если бы было однозначно выгоднее иметь один уникальный ид на все типы объектов - так была бы спроектирована любая БД. Я такого, в основном, не наблюдал.

Единственные исключения когда разные типы объектов разделяли общий ид:
1. Наследование. Ид на личность - разделяют иды сотрудников и клиентов.
2. Метапрограммирование - когда база строится под хранение заранее неизвестных типов объектов. Но нагрузки там... ого-ого. =)

Как видно из девблога - поменяли ID не для типов объектов, а ID вообще всех объектов существующих в Еве в данный момент времени. Зачем они хранят такой большой отдельный список всех объектов, а не разделили его на множество поменьше мы можем только гадать. Может и не выгоднее так, но вариант с более быстрым поиском объекта вполне возможен.

Символ текста - 8 или 16 бит.

А гугл ищет по одному символу или все таки по группе?

Только поиск по иду в 1024 будет очень медленным. Или нужен 1024-битный процессор. Про такие пока не слыхал. =)

Для скорости нужен 1024-битный процессор? Или Вы думаете что скорость вычеслений сильно уменьшится, если складывать два 1024-битных числа на 32-битном процессоре?

Тем что сравнивать 64-битную переменную можно за одну операцию на 64-битном регистре, чего не скажешь о 1024.

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

К тому же не думаю что в базе данных эти ID не отсортированы.

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

А математический сопроцессор стал иметь большую разрядность чем обычный? Или все таки не в разрядности дело?

[mypuk]

закройте тему уже)

[Psihius]

Теоретики мля...
Реально закройте уже тему, а то моё среднее и высшее образование по компъюторным наукам надорвёт щас живот или вынудит накатать такую простыню текста, что получу РО за оффтоп...

Сообщение отредактировал Psihius: 27 October 2010 - 15:49

[Takeshi Ryuu]

Правильные алгоритмы поиска подстроки в строке работают даже с текстом в UTF-8, где одному символу может соответствовать от одного до четырёх байт,

но это имеет весьма слабое отношение к тому, как ищет гугл, поисковые алгоритмы которого уже давно вышли за пределы простого поиска подстроки,

и еще меньшее отношение к теме 64-битных идентификаторов внутри таблицы в базе данных,

которые слабо связаны с битностью процессоров.


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

[Lantitudia]

Расскажите мне как связаны битность переменной и битность процессора?
а попутно можете рассказать чем отличается 32-битный проц от 64-битного.
(может пока будете рассказывать найдете свою ошибку)

едит: очепятка

Битность переменной и процессора прямо не связаны. Я говорил про скорость поиска и разрядность процессора.

64-х битный процессор вынимает в 64-х битный регистр 64-битную переменную за одну операцию обращения к шине данных. И сравнивает с другим идом тоже за одну операцию.

Если иды сделать 1024 бита - то сравнение будет гораздо медленне - на операцию сравнения будет уходить несколько операций процессора.

Читай внимательнее.

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

Это называется в данном контексте составной ключ. Ищет база данных. Никакие алгоритмы тут использовать не надо.

К тому же не думаю что в базе данных эти ID не отсортированы.

Так мы про производительность БД и говорим. Или по твоему БД сортирует иды в индексах мгновенно ? Вы рассуждаете о том, чего не знаете. Не думает он видите ли... =)))

Любая БД на 64 разрядном процессоре индекс 64-х битных идов отсортирует гораздо быстрее чем в случае 1024 бита на ид. Тоже и с поиском.

[Yaponiz]

Битность переменной и процессора прямо не связаны. Я говорил про скорость поиска и разрядность процессора.

64-х битный процессор вынимает в 64-х битный регистр 64-битную переменную за одну операцию обращения к шине данных. И сравнивает с другим идом тоже за одну операцию.

Если иды сделать 1024 бита - то сравнение будет гораздо медленне - на операцию сравнения будет уходить несколько операций процессора.

Читай внимательнее.

Сравнение будет медленнее, но врядли сравнение является основной операцией используемой при работе с ID.

Так мы про производительность БД и говорим. Или по твоему БД сортирует иды в индексах мгновенно ? Вы рассуждаете о том, чего не знаете. Не думает он видите ли... =)))

Любая БД на 64 разрядном процессоре индекс 64-х битных идов отсортирует гораздо быстрее чем в случае 1024 бита на ид. Тоже и с поиском.

А разве они не пытаются просто добавлять все данные в конец БД? Вместо того чтобы сортировать тем скриптом который у них используется сейчас.

[Slotos]

А разве они не пытаются просто добавлять все данные в конец БД? Вместо того чтобы сортировать тем скриптом который у них используется сейчас.

"Конец БД" - это сильно. Приму на вооружение.

[Lantitudia]

Сравнение будет медленнее, но врядли сравнение является основной операцией используемой при работе с ID.

Что бы эффективно искать по иду - БД должна построить индекс - т.е. (упрощая) отсортировать иды.

При поиске - основная операция - это сравнение идов.

При построении индекса - не только сравнение идов, конечно. Еще нужно переставлять местами комбинацию [ид + указатель блока данных на который ид указывает (упрощая)].

А разве они не пытаются просто добавлять все данные в конец БД? Вместо того чтобы сортировать тем скриптом который у них используется сейчас.

Ты говоришь только про добавление, да, они "просто добавляются в конец БД" (условно). Но добавление случается гораздо реже поиска. Поиск - основная операция. И тут начинает ролять, что бы битность переменной не превышала битность процессора.

А по теории "добавлять в конец БД" - бессмысленная фраза. В реаляционных базах данных (SQL) нет такого понятия "позиция записи (кортежа)". Нельзя "добавить в конец БД или в начало". Как нельзя массу тела умножать на количество постов на еве-ру - это бессмысленная операция.

Т.е. ид (ключ) в БД гарантирует что у каждой строки-записи уникальный ид, но это не имеет отношения к порядку записей. Конец, начало или середина.

Но это уже теория.

[7fox7]

Пока не ввели 64, можно устроить небольшой флешмоб. Массово всем сервером, сделать всем своим вещам анстекинг(каждый патрон, руду, минерал отдельным итемом а не группой). И может наступить кирдык.

По поводу рассуждений, на счет эффективности ввода расширенной размерности индекса. У вас есть какие либо вменяемые и эффективные альтернативы для решения проблемы заполненности индекса на MS SQL? Нету? О чем разговор тогда.

Сообщение отредактировал 7fox7: 28 October 2010 - 1:25

[Yaponiz]

Но это уже теория.

Antonn за меня ответил.

[Slotos]

флуд

Дописывание данных в конец файла таблицы/БД. Такое понятие есть, но оперируют им далеко не все программисты
Операция вполне осмысленная, зависит от методов работы с таблицей и поиском. Если таблица редко фрагментируется, то автоинкрементное поле (будучи индексом) имеет почти отсортированное состояние (при необходимости идущие подряд смежные блоки могут читаться за "раз" без перемещения указателя по файлу). Притянуто за уши, но вот...

умным_не_читать

И между всем этим сидит как минимум кеш файловой системы.

[Psihius]

умным_не_читать

который, конечно же, без проблем разрулит большие нагрузки с чтением на гигабайтных файлах базы =)

умным_не_читать

Да вообще, софт такой, сцука, умный, что сам себя проектирует!

Посмеялись, а теперь надо завязывать. А то придут модераторы и выдадут РО.
Тема вроде обсосана, обсуждать больше нечего.

Сообщение отредактировал Psihius: 28 October 2010 - 17:43

[Lantitudia]

Antonn за меня ответил.

Собственно что он ответил ?

На 64-х битном процессоре поиск по 1024-х битному иду остался порядково медленне чем по 64-х битному иду.

А теория с точки зрения стандарта на язык SQL о "невозможности добавить в конец БД" осталась верна.

Сообщение отредактировал Lantitudia: 28 October 2010 - 20:30

[palar]

А математический сопроцессор стал иметь большую разрядность чем обычный? Или все таки не в разрядности дело?

ты не поверишь, но таки да.