Статья :
Экология Программирования

Автор(ы): Антон Злыгостев
Дата: 21.02.2003

Авторы :
Антон Злыгостев

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

Я терпеливо следил за дискуссиями на эту тему, пока один ужасающий факт не привлек мое внимание.

Я не понял, это шутка?
Сколько лет нужно, чтобы все guid'ы перелопатить?

В начале статьи "Версия текста: {5DCEB4BA-2DCC-4de3-AB06-EED88875A68F}"

Хм... Действительно бага!
Этот GUID был возвращен еще в марте...

Поздравляю, Антон, у Вас налицо утечка GUID'а.

Павел.

Этот же GUID будет использоваться для последующих версий текста.

Здравствуйте, Sergeem, Вы писали:

S>Я не понял, это шутка?

Нет, это докторская диссертация Антона, запощеная в "Коллеги улыбнитесь!" (видимо по ошибке).
Голосуйте за перенос в форум "О жизни GUID'ов".

D>Этот же GUID будет использоваться для последующих версий текста.

Ай-ай-ай! Этот GUID будет использоваться для ссылки на данную версию текста. Для последующих будут использованы новые GUID'ы. Кроме того, данный труд есть объект глобальный, возврату оные GUID'ы подлежать не будут, наравне с IID интерфейса IUnknown, ввиду собственной великой значимости для экологического движения.

Здравствуйте, Антон Злыгостев, Вы писали:

Крэйзи! Полный бред сивой кобылы...
Надеюсь это была шутка.

Дейл Роджерсон, "Основы COM" :

Теория GUID
GUID по определению уникален "в пространстве и во времени". Для обеспечения "географической" уникальности каждый GUID использует 48-битовое значение, уникальное для компьютера, на котором он генерируется. Обычно в качестве такого значения берется адрес сетевой платы. Такой подход гарантирует, что любой GUID, полученный на моем компьютере, будет отличаться от любого, сгенерированного на Вашем компьютере. Для тех компьютеров, в которых не установлен сетевой адаптер, используется другой алгоритм генерации уникальных значений. В каждом GUID 60 битов отведено для указания времени. Туда заносится число 100-наносекундных интервалов, прошедших с 00:00:00:00 15 октября 1582 года. Используемый в настоящее время алгоритм генерации GUID начнет выдавать повторяющиеся значения примерно в 3400 году.

...
GUID придумали толковые ребята из Open Source Foundation; правда они использовали термин UUID (Universally Unique IDentifiers). UUID разработали для использования в среде распределенных вычислений (DCE, Distributed Computing Environment). Вызовы удаленных процедур DCE используют для идентификации вызываемого...

Здравствуйте, 9Val, Вы писали:

V>Туда заносится число 100-наносекундных интервалов, прошедших с 00:00:00:00 15 октября 1582 года. Используемый в настоящее время алгоритм генерации GUID начнет выдавать повторяющиеся значения примерно в 3400 году.

V>GUID придумали толковые ребята из Open Source Foundation; правда они использовали термин UUID (Universally Unique IDentifiers). UUID разработали для использования в среде распределенных вычислений (DCE, Distributed Computing Environment). Вызовы удаленных процедур DCE используют для идентификации вызываемого...

Ну прям как маленькие.
Когда это придумывали, компьютеры были слабенькими... 100 нан это всего 10MHz, а у меня комп сейчас 3GHz -> 300 раз быстрее!
Значит и ресурсы GUID'ов закончатся в 300 раз быстрее. А мощность компов все всремя растет, так что прогнозы весьма пессиместичные.
Объем обрабатываемой информации растет в геометрической прогрессии. Просто для того, чтобы все это обработать потребуется колоссальное количество GUID'ов, а значит и генерится они будут не раз в 100 нсек, а гораздо чаще! Не то чтобы до 3400, до 2010 года бы дожить.
Уже было несколько статей посвященных этой проблеме. Проблеме 2010 года. Поищи в гугле, наверняка найдешь.

Здравствуйте, UGN, Вы писали:

UGN>Ну прям как маленькие.
UGN>Когда это придумывали, компьютеры были слабенькими... 100 нан это всего 10MHz, а у меня комп сейчас 3GHz -> 300 раз быстрее!
UGN>Значит и ресурсы GUID'ов закончатся в 300 раз быстрее. А мощность компов все всремя растет, так что прогнозы весьма пессиместичные.
Повторюсь: "Туда заносится число 100-наносекундных интервалов, прошедших с 00:00:00:00 15 октября 1582 года. "

Мощность тут абсолютно непричем. Будь у тебя 10Гц — все равно с 1582 года пройдет тот же промежуток времени

UGN>Уже было несколько статей посвященных этой проблеме. Проблеме 2010 года.
Проблема 2010 — это несколько другая проблема, а точнее — продолжение проблемы 2K


Валерий Артемьев о 2010 (полная версия статьи здесь):
"Решена ли проблема окончательно?

В долгосрочной перспективе нас и наших потомков ожидает еще много малых и больших неприятностей, связанных с календарем. Некоторые программистские решения проблемы 2000 года (такие, как, например, специфические методы кодирования и метод фиксированного окна для интерпретации односимвольного представления года) имеют ограниченные сроки годности — до 2005 или 2010 года! Другие будут корректно работать, например, до 2030 года. Возможно, это были прагматичные временные решения, но теперь их нужно вовремя скорректировать. Но, даже если использован метод скользящего окна для интерпретации двухразрядных годов или полный формат представления дат, то проблемы будут поджидать в другом месте. Так, системные часы персональных компьютеров смогут работать только до 2035 года, часы операционных систем Unix и программ на Си — до 2037 года."

Думаю, к тому времени что-нибудь придумаем

Здравствуйте, Копейка, Вы писали:

К>Здравствуйте, Антон Злыгостев, Вы писали:

К>Крэйзи! Полный бред сивой кобылы...
К>Надеюсь это была шутка.

Название форума читать не пробовали?

Здравствуйте, 9Val, Вы писали:

V>Повторюсь: "Туда заносится число 100-наносекундных интервалов, прошедших с 00:00:00:00 15 октября 1582 года. "

V>Мощность тут абсолютно непричем. Будь у тебя 10Гц — все равно с 1582 года пройдет тот же промежуток времени

Да, но 100 нсек было достаточно тогда, а сейчас этого мало!!!

GUID'ов требуется все больше и больше, а взять их неоткуда!

Допустим, GUID используется для придания уникальности пакету с данными, транзакции

тогда получается, что нельзя отправлять пакеты чаще, чем раз в 100 нсек!!!

А это, как я уже писал -- всего 10 MHz!

Т.е. следствием является искусственное ограничение объема передаваемых данных.

Если не возвращать GUID'ы, то уже довольно скоро у нас будут большие проблемы!

Об этом Антон и писал в своей статье.

Здравствуйте, Антон Злыгостев, Вы писали:

АЗ>Авторы :
АЗ>Антон Злыгостев

...А я вот подумал, что многоуважаемый Антон во многом прав...
Дело в том что есть такая поганая штука как "Парадокс дней рождения".
Он гласит что "Если в одной комнате соберутся более 22 человек,
то с вероятностью более 0.5 у двцх из них дни рождения совпадут".

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

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

Здравствуйте, TepMuHyc, Вы писали:

TMH>Здравствуйте, Антон Злыгостев, Вы писали:

АЗ>>Авторы :
АЗ>>Антон Злыгостев

TMH>...А я вот подумал, что многоуважаемый Антон во многом прав...
Никто не повелся... А я надеялся что счас начнется и будет весело...

Здравствуйте, TepMuHyc, Вы писали:

TMH>>...А я вот подумал, что многоуважаемый Антон во многом прав...
TMH> Никто не повелся... А я надеялся что счас начнется и будет весело...

Мы перевариваем ...

UGN>Когда это придумывали, компьютеры были слабенькими... 100 нан это всего 10MHz, а у меня комп сейчас 3GHz -> 300 раз быстрее!
UGN>Значит и ресурсы GUID'ов закончатся в 300 раз быстрее. А мощность компов все всремя растет, так что прогнозы весьма пессиместичные.


Во-первых, в документации к функциям, генерирующим GUID прямо предлагается без сетевой карты на глобальые GUID не надеяться. Так что реально, этих самых GUID при правильном их использовании хватит еще надолго — сетевые карты еще не научились штамповать со скоростью миллион штук в секунду.


А вот если кто-то использует GUID для уникальной идентификации полей БД, пакетов данных итп в достаточно производитлеьных и одновременно нагруженных средах скоро столкнется с проблемой, которая теме форума никак не соответствует.

Как вы думаете, чему равно running_time после выполнения следующего кода на моей уже устаревшей системе Athlon1200 SDRAM PC133 WinXPSP1?

GUID* g_GUIDs = 0;
const int size = 500000;
g_GUIDs    = new GUID[size];
    
DWORD start_time = GetTickCount();
for(int i = 0; i < size; ++i)
{
    UuidCreateSequential(&g_GUIDs[i]);
}
DWORD running_time = GetTickCount() - start_time;

Ответ: 50.

Зато можно порадоваться, что в виндах имеется еще один недокументированный споосб точного отмеривания 100 наносекундных интервалов...

здесь

Автор: Kupaev
Дата: 27.08.03

Здравствуйте, UGN, Вы писали:

UGN> здесь

Автор: Kupaev
Дата: 27.08.03

Кстати, несмотря на на название форума, многие программисты SQLServer этот тип поля часто используют. Могу себе представить хранимую процедуру, которая переносит данные из одной таблицы в другую, создавая автоматом новый GUID для каждой записи.
Соответственно, даже если поставить туда террагерцовый процессор и 1 террабайтный флеш-драйв, скорость переноса данных будет не более 1 поля в 100 наносекунд.

Мы это уже проходили с 640кб памяти для доса, и с 12-13 мб свободной виртуальной памяти для PocketPC, и с 25-30 мб для новомодного PocketPC2003.

Здравствуйте, Антон Злыгостев, Вы писали:

АЗ>Экология Программирования

Правильно ! Поэтому предлагается всем срочно переходить на Linux,
где нет никаких GUIDов. Срочно ! Пока GUIDы не кончились.