Программирование[10]

Grohuf написал 1 минуту назад:

Теперь возьмем реализацию без списков или реализацию, где первый элемент списка лежит в самой таблице.

УРА

ТЫ ПЕРЕИЗОБРЕЛ ВЕКТОР АЛЛИЛУЯ

Только проблема в том что там где элементов нет ты все равно занимаешь место и сосешь по памяти и сосешь где-то раза в 2.7 насколько помню

ШООООООООООООК БЛЯЯЯЯ

Vova написал 1 минуту назад:

besteady написал 13 минут назад:

Даже взять сайт, с которого ты взял график std сосет во всем у остальных хэш мап https://tessil.github.io/2016/08/29/benchmark-hopscotch-map.html

Std берут как бейс лайн и заменяют, если нужно

 

For speed efficiency. A hash map using an open addressing scheme should be your choice and I would recommend either hopscotch hashing with tsl::hopscotch_map or linear robin hood hashing with tsl::robin_map or ska::flat_hash_map.

 

For memory efficiency. If you are storing small objects (< 32 bytes) with a trivial key comparator, tsl::sparse_map should be your go to hash map. Even though it is quite slow on insertions, it offers a good balance between lookup speed and memory usage, even at low load factor. It is also faster than both google::sparse_hash_map and spp::sparse_hash_map while providing more functionalities.

 

For strings as key. If you are using strings as key, the above recommendations still hold true but you may also want to try tsl::array_map. It offers one of the best lookup speed on large strings while having the lowest memory usage. 

 

Класс

 

Я должен использовать миллиард разных мап для разных целей чтобы всегда быть лучше std

 

Охуеть

Блять я и говорю, что ты не умеешь читать. Что сейчас, что раньше 

Речь шла в презентации, и дальше в топане об "for speed efficiency". Std имплементация для этого не используется, потому что она говно

Пруф об скорости - гуглобенчи. Ты же на это отвечаешь "ну я щас из unordered_set сделаю вектор". Ну это просто идиотское утрирование, к чему оно вообще нахуй?

Только путаешь и разводишь на посты 

Vova написал 1 минуту назад:

Grohuf написал 6 минут назад:

Теперь возьмем реализацию без списков или реализацию, где первый элемент списка лежит в самой таблице.

 

УРА

 

ТЫ ПЕРЕИЗОБРЕЛ ВЕКТОР АЛЛИЛУЯ

 

Только проблема в том что там где элементов нет ты все равно занимаешь место и сосешь по памяти и сосешь где-то раза в 2.7 насколько помню

 

ШООООООООООООК БЛЯЯЯЯ

Для вовы шок, что хэш-таблица по сути вектор? Даже для твоей тупости это слишком.

besteady написал Только что:

Vova написал 6 минут назад:

besteady написал 18 минут назад:

Даже взять сайт, с которого ты взял график std сосет во всем у остальных хэш мап https://tessil.github.io/2016/08/29/benchmark-hopscotch-map.html

Std берут как бейс лайн и заменяют, если нужно

 

For speed efficiency. A hash map using an open addressing scheme should be your choice and I would recommend either hopscotch hashing with tsl::hopscotch_map or linear robin hood hashing with tsl::robin_map or ska::flat_hash_map.

 

For memory efficiency. If you are storing small objects (< 32 bytes) with a trivial key comparator, tsl::sparse_map should be your go to hash map. Even though it is quite slow on insertions, it offers a good balance between lookup speed and memory usage, even at low load factor. It is also faster than both google::sparse_hash_map and spp::sparse_hash_map while providing more functionalities.

 

For strings as key. If you are using strings as key, the above recommendations still hold true but you may also want to try tsl::array_map. It offers one of the best lookup speed on large strings while having the lowest memory usage. 

Показать больше  

 

Класс

 

Я должен использовать миллиард разных мап для разных целей чтобы всегда быть лучше std

 

Охуеть

Блять я и говорю, что ты не умеешь читать. Что сейчас, что раньше 

Речь шла в презентации, и дальше в топане об "for speed efficiency". Std имплементация для этого не используется, потому что она говно

Пруф об скорости - гуглобенчи. Ты же на это отвечаешь "ну я щас из unordered_set сделаю вектор". Ну это просто идиотское утрирование, к чему оно вообще нахуй?

Только путаешь и разводишь на посты 

Я тебе уже раз 5 написал что разделять скорость и память НЕТ СМЫСЛА

Ты ебешься в глаза? Гугл мапа может занимая столько же памяти быть быстрее? очень похоже что нихуя

Vova написал Только что:

besteady написал 2 минуты назад:

Vova написал 7 минут назад:

besteady написал 19 минут назад:

Даже взять сайт, с которого ты взял график std сосет во всем у остальных хэш мап https://tessil.github.io/2016/08/29/benchmark-hopscotch-map.html

Std берут как бейс лайн и заменяют, если нужно

 

For speed efficiency. A hash map using an open addressing scheme should be your choice and I would recommend either hopscotch hashing with tsl::hopscotch_map or linear robin hood hashing with tsl::robin_map or ska::flat_hash_map.

 

For memory efficiency. If you are storing small objects (< 32 bytes) with a trivial key comparator, tsl::sparse_map should be your go to hash map. Even though it is quite slow on insertions, it offers a good balance between lookup speed and memory usage, even at low load factor. It is also faster than both google::sparse_hash_map and spp::sparse_hash_map while providing more functionalities.

 

For strings as key. If you are using strings as key, the above recommendations still hold true but you may also want to try tsl::array_map. It offers one of the best lookup speed on large strings while having the lowest memory usage. 

Показать больше  

 

Класс

 

Я должен использовать миллиард разных мап для разных целей чтобы всегда быть лучше std

 

Охуеть

Блять я и говорю, что ты не умеешь читать. Что сейчас, что раньше 

Речь шла в презентации, и дальше в топане об "for speed efficiency". Std имплементация для этого не используется, потому что она говно

Пруф об скорости - гуглобенчи. Ты же на это отвечаешь "ну я щас из unordered_set сделаю вектор". Ну это просто идиотское утрирование, к чему оно вообще нахуй?

Только путаешь и разводишь на посты 

 

Я тебе уже раз 5 написал что разделять скорость и память НЕТ СМЫСЛА

 

Ты ебешься в глаза? Гугл мапа может занимая столько же памяти быть быстрее? очень похоже что нихуя

Этот дурачок думает, что если увеличить unordered_set до размера гугловской, то скорость будет такой же. Клинический.

Vova написал Только что:

besteady написал 2 минуты назад:

Vova написал 8 минут назад:

besteady написал 20 минут назад:

Даже взять сайт, с которого ты взял график std сосет во всем у остальных хэш мап https://tessil.github.io/2016/08/29/benchmark-hopscotch-map.html

Std берут как бейс лайн и заменяют, если нужно

 

For speed efficiency. A hash map using an open addressing scheme should be your choice and I would recommend either hopscotch hashing with tsl::hopscotch_map or linear robin hood hashing with tsl::robin_map or ska::flat_hash_map.

 

For memory efficiency. If you are storing small objects (< 32 bytes) with a trivial key comparator, tsl::sparse_map should be your go to hash map. Even though it is quite slow on insertions, it offers a good balance between lookup speed and memory usage, even at low load factor. It is also faster than both google::sparse_hash_map and spp::sparse_hash_map while providing more functionalities.

 

For strings as key. If you are using strings as key, the above recommendations still hold true but you may also want to try tsl::array_map. It offers one of the best lookup speed on large strings while having the lowest memory usage. 

Показать больше  

 

Класс

 

Я должен использовать миллиард разных мап для разных целей чтобы всегда быть лучше std

 

Охуеть

Блять я и говорю, что ты не умеешь читать. Что сейчас, что раньше 

Речь шла в презентации, и дальше в топане об "for speed efficiency". Std имплементация для этого не используется, потому что она говно

Пруф об скорости - гуглобенчи. Ты же на это отвечаешь "ну я щас из unordered_set сделаю вектор". Ну это просто идиотское утрирование, к чему оно вообще нахуй?

Только путаешь и разводишь на посты 

 

Я тебе уже раз 5 написал что разделять скорость и память НЕТ СМЫСЛА

 

Ты ебешься в глаза? Гугл мапа может занимая столько же памяти быть быстрее? очень похоже что нихуя

Бля

Ты ебанутый?

Ты можешь в ту или иную сторону трейдиться, памяти или скорости, с этим никто не спорил. Просто std говно в обоих этих случаях

https://github.com/abseil/abseil-cpp/blob/master/absl/container/flat_hash_set.h

Эта реализация уверяет, что она лучше реализации STL и по памяти, и по скорости.

Grohuf написал 1 минуту назад:

Vova написал 3 минуты назад:

Grohuf написал 8 минут назад:

Теперь возьмем реализацию без списков или реализацию, где первый элемент списка лежит в самой таблице.

 

УРА

 

ТЫ ПЕРЕИЗОБРЕЛ ВЕКТОР АЛЛИЛУЯ

 

Только проблема в том что там где элементов нет ты все равно занимаешь место и сосешь по памяти и сосешь где-то раза в 2.7 насколько помню

 

ШООООООООООООК БЛЯЯЯЯ

Для вовы шок, что хэш-таблица по сути вектор? Даже для твоей тупости это слишком.

Вообще то я предложил вектор тут первым в топане

Твоя имплементация сосет еще больше по "кэшу" для больших объектов тк тупо занимает больше места

Ты снова отсосал

Ура

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

besteady написал 2 минуты назад:

Просто std говно в обоих этих случаях

Но я тебе скинул график показывающий что нет

Vova написал Только что:

Grohuf написал 5 минут назад:

Vova написал 6 минут назад:

Grohuf написал 11 минут назад:

Теперь возьмем реализацию без списков или реализацию, где первый элемент списка лежит в самой таблице.

 

УРА

 

ТЫ ПЕРЕИЗОБРЕЛ ВЕКТОР АЛЛИЛУЯ

 

Только проблема в том что там где элементов нет ты все равно занимаешь место и сосешь по памяти и сосешь где-то раза в 2.7 насколько помню

 

ШООООООООООООК БЛЯЯЯЯ

Для вовы шок, что хэш-таблица по сути вектор? Даже для твоей тупости это слишком.

 

Вообще то я предложил вектор тут первым в топане

 

Твоя имплементация сосет еще больше по "кэшу" для больших объектов тк тупо занимает больше места

 

Ты снова отсосал

 

Ура

Ага, ага  Слился тиктокер.

Grohuf написал 1 минуту назад:

Ага, ага  Слился тиктокер.

Нет я не сливался никуда

Я конкретно ответил почему твоя идея сосет

Vova написал Только что:

besteady написал 3 минуты назад:

Просто std говно в обоих этих случаях

 

Но я тебе скинул график показывающий что нет

А я открыл страницу, откуда ты взял график, и автор статьи не предлагает std::unorder_set ни в случае "for speed efficiency", ни в случае "for memory efficiency"

Кого ты пытаешься наебать?

Grohuf написал 6 минут назад:

Этот дурачок думает, что если увеличить unordered_set до размера гугловской, то скорость будет такой же. Клинический.

Это лишь твои додумки

https://martin.ankerl.com/2019/04/01/hashmap-benchmarks-04-03-result-RandomFind_500000/

Бенчмарки с памятью. unordered_map сосет у flat_hash_map по скорости при такой же памяти.

besteady написал Только что:

Vova написал 3 минуты назад:

besteady написал 5 минут назад:

Просто std говно в обоих этих случаях

 

Но я тебе скинул график показывающий что нет

А я открыл страницу, откуда ты взял график, и автор статьи не предлагает std::unorder_set ни в случае "for speed efficiency", ни в случае "for memory efficiency"

Кого ты пытаешься наебать?

Постой

Мы начали с того что я сказал что std::unordered_map лучше чем std::map если порядок не важен в ответ на бред от Грохуфа

Потом стал спорить с тем что гугл мапа якобы лучше std::unordered_map во всем

А теперь я должен уже спорить с тем в каждом частном случае нету мапы которая в этом частном случае была бы лучше std::unordered_map

Прикол

Я на такое не подписывался

Vova написал Только что:

Мы начали с того что я сказал что std::unordered_map лучше чем std::map если порядок не важен в ответ на бред от Грохуфа

Пошли маняврирования

Vova написал 3 минуты назад:

Потом стал спорить с тем что гугл мапа якобы лучше std::unordered_map во всем

Я могу тебе только ещё раз повторить: учись читать чужие посты прежде, чем отвечать на них

Поставлю тебе 5 в профиль, если ты найдёшь, где я писал про гугл мапу (только ты про неё все время пишешь, у меня она была только как один из вариантов в графике и то речь шла о скорости, а не он памяти) и тем более, что гугл мапа лучше ВО ВСЕМ.

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

Grohuf написал 3 минуты назад:

Vova написал 4 минуты назад:

Мы начали с того что я сказал что std::unordered_map лучше чем std::map если порядок не важен в ответ на бред от Грохуфа

Пошли маняврирования

Я не маняврирую и готов ответить за все свои отверждения

Ты мне не ответил нихуя по поводу претензии к твоему улучшению "кэша"

besteady написал Только что:

Vova написал 7 минут назад:

Потом стал спорить с тем что гугл мапа якобы лучше std::unordered_map во всем

Я могу тебе только ещё раз повторить: учись читать чужие посты прежде, чем отвечать на них

Поставлю тебе 5 в профиль, если ты найдёшь, где я писал про гугл мапу (только ты про неё все время пишешь, у меня она была только как один из вариантов в графике и то речь шла о скорости, а не он памяти) и тем более, что гугл мапа лучше ВО ВСЕМ.

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

Ладно хорошо

Ты утверждал что хуево использовать std::unordered_map в проде

Нет не хуево тк использовать миллион разных хуево для читабельности

Vova написал 7 минут назад:

Нет не хуево тк использовать миллион разных хуево для читабельности

Что это вообще должно значить?

У тебя есть такие куски кода, где надо сразу разные по трейдоффу хэшмапы нужны? Ты сам себе такое можешь представить?