Где вы увидели что уделывает? Во всех тестах, что мне попались на глаза по этой ссылке, я вижу сишечку на первом месте

У меня на экране Си даже не попал в некоторые.

Потому что его там банально никто не тестировал, наверное?

Тормозит не язык, тормозит код, который вы на нём написали. У дотнета есть ряд преимуществ перед плюсами по перфе, и наоборот тоже справедливо, зависит от задачи. Можно на ассемблере напилить идеальных инструкций, но на одном процессоре они будут быстрее, на другом медленнее, чем дотнетовские PGO+OSR. Вопрос не имеет смысла, так как выводов из него никаких нет.

А C вообще какой-нибудь язык обгоняет?

А как тогда правильно сравнивать быстродействие?

Быстродействие чего?

@FAQ, "А C вообще какой-нибудь язык обгоняет?" Язык ассемблера иногда.

"А был ли мальчик?" Я что-то просто не вижу в большинстве тестов С... Какой конкретно бенчмарк вы имеете в виду?

"А C вообще какой-нибудь язык обгоняет?" - нет никаких языков, все языки испаряются на этапе компиляции. А вот дальше как оно работает - это вопрос. В сишняке можно сильно "помочь" компилятору, т.е. написать такой код, который будет максимально эффективен на выходе. А в дот.нете такое в принципе невозможно. Но дот.нет не для максимальной эффективности. Дот.нет про другое. При этом, дот.нет весьма эффективен. Если в нём заюзать гибридный подход. Быстрые собственные аллокаторы например. В чём дот.нет точно проигрывает - это в памяти.

Всё что есть - это подготовленные данные, и алгоритмы над ними. Как вы это всё организуете - так оно и будет работать. И ничего другого - нет, и не будет. Если вы это всё организовываете плохо - оно и на сишняке будет тормозить. А если вы это всё организовываете хорошо - оно и на дот.нете взлетит. Первична эта самая "организация". Это архитектура, вменяемые подготовленные данные под алгоритмы, вменяемый мемори-менеджмент, вменяемые железяки, и знание того как это всё вместе работает. Это сложно.

Дот.нет - это рантайм+фреймворк. Рантайм дотнета весьма не плох, хотя некоторые вопросы к рантайму всё равно остаются. А вот фреймворк - ужасен. Рантайм дот.нета писали как будто бы гении, а фреймворк писали совершенно другие люди, пусть студенты полуподвальные. Именно потому никто не пользует набор стандартных библиотек дот.нета - это и есть фреймворк. Он [этот набор] убожественный. Пример - есть стандартный словарь, он отдаёт элементы за некое X. И есть вменяемая реализация словаря, она работает на порядок быстрее. И весь фреймворк такой. Т.е. никакущщий.

Это я к тому, что некие программки на дот.нете - ЭТО ЧТО? Это настолько широкое понятие, что сходу дать определение этому - весьма затруднительно. А вы пытаетесь производительность этому всему обозначить. Ну да ну да. :)

А где Вы берёте нормальные коллекции?

"Сами" пишем. Они из "ниоткуда" не возьмутся.

Дот.нет - это же Майкрософт, а значит по-определению - никогда толком не доделано. Хорошо это или плохо? Ну с одной стороны - плохо. Как можно за 25 лет в базовую библиотеку так и не вкарячить нормальный набор разнообразных словарей? Оказывается можно. Майкрософт жеж. Этим всё сказано. Однако же те кто знают как накарячить вменяемые реализации - всегда выиграют у тех, кто не знает. Получается так, что "не-дописанное" - для кого то плохо, а кому то наоборот - хорошо. А в общем то - всем плевать. Ну работает оно как то, и работает. Кому нужно быстрее - всегда сделают быстрее, чем в "стандарте".

@InterceptorTSK Обожжите, что именно не так со стандартным словарём .NET? И при каких условиях? Вы GetHashCode не забывали переопределять? )

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

Если вы сильно подумаете, то в цепочку можно впихнуть 10000 элементов, чисто паржать. Затем запросить Александровича, который там где то в конце цепочки. Коллизии всегда можно подобрать, ВСЕГДА. И ваш недосирвак ляжет. Это называется "прапердолинг" через хеш-таблицы. Которых у вас полно. И так как "у вас всё нормально" - то вас можно "пердолить" по полной программе. У вас хеш-таблицы общего назначения, вы упорно [или упорото] этого не понимаете. А ещё вы не понимаете банальность, хеш-таблица - непредсказуема. И банальность в том, что она непредсказуема не только для атакующего, НО И ДЛЯ ВАС.

@InterceptorTSK Ну, бывают коллизии, да, но прям чтобы ВСЕГДА - это нужно очень плохую хэш функцию написать. Разрешения коллизий бывают разные, список - ну, нормальный вариант, если коллизий не много, не знаю, что вы так прямо возбудились.

Причём здесь хеш-функции? На любые хеш-функции всегда найдутся "плохие данные", которые всё переломают. Пишите любые хеш-функции - и это вас не спасёт. Спасёт прямое управление словарём. Например жёсткое ограничение на длину цепочек. А оно есть? Неа. :) У меня - есть. А у вас - нет. И уж тем более нет ничего, что "сигнализирует" атаку по словарю. Вообще ничего такого нет. А так то конечно "словарь общего назначения" очень хорош. :) Ну да ну да. И цепочки вообще то не нужны. Прямая адресация [опять с ручным управлением] с ограничением по смещениям спасёт. Что бы не терялась локальность.

Только тут проблемка есть. Такой словарь с жесточайшим ограничением по параметрам, коих двадцать параметров - строится две секунды. Это на 10000 элементов. Перебирается настолько много вариантов построения словаря, что вы даже себе не представляете насколько хорошо всё оптимизируется. Но на это нужно гигантское время. А две секунды на 10000 - это абсолютно гигантское время. Оно замечательно подходит для статических словарей. А в общем математическом смысле проблема построения почти-идеального словаря за разумное время - не решаема. Или же узкие реализации. Чюдес не бывает, и не будет.

@InterceptorTSK Любой инструмент хорош для решения конкретных задач. Можно, конечно, и под микроскопом гвозди забивать, но для большинства задач это не нужно. Ну хорошо, навострились вы делать оптимальные словари для конкретных задач - ну и отлично. Но это не делает стандартные словари .NET чем-то ужасным. Я видел в промышленной среде, как их используют для вполне критичных по времени задач и для довольно больших данных. И они вполне себе справлялись.