Re[9]: Java vs C# vs C++
От: alex_public  
Дата: 26.09.15 02:49
Оценка:
Здравствуйте, gandjustas, Вы писали:

_>>Кроме отсутствия автовекторизации, C# (а точнее .net) обладает ещё целым букетом замедляющих факторов, происходящих из самого устройства платформы. Это не говоря уже о просто слабом оптимизаторе.

G>Это уже твои фантазии. Таких "замедляющих факторов" в любом языке полно, даже в c++. Более того, почти любые гарантии со стороны языка небесплатны. Супер оптимальный код будет супер небезопасным. А достаточно надежный код будет иметь "букет замедляющих факторов".

Что-то я не понял этого твоего высказвания) В первом предложение ты выступаешь против моего тезиса, а в следующих 4-ёх излагаешь подтверждающие его аргументы. )))

Да, а насчёт компромисса скорость/безопасность я собственно и не спорил. Хотя такое всё же не всегда происходит. К примеру такие вещи как "все функции виртуальные" и отсутствие полноценных нессылочных типов явно не приводят к какому-то увеличению безопасности... )
Re[10]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 26.09.15 05:46
Оценка:
Здравствуйте, alex_public, Вы писали:


_>Да, а насчёт компромисса скорость/безопасность я собственно и не спорил. Хотя такое всё же не всегда происходит. К примеру такие вещи как "все функции виртуальные" и отсутствие полноценных нессылочных типов явно не приводят к какому-то увеличению безопасности... )

А где это в .Net "все функции виртуальные"? Ты с Java не спутал?
Другое дело, что С++ может больше использовать инлайн, что может приводить к ускорении при частом вызове таких функций.
и солнце б утром не вставало, когда бы не было меня
Re[10]: Java vs C# vs C++
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 26.09.15 05:50
Оценка:
Здравствуйте, alex_public, Вы писали:

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


_>>>И какое это имеет отношение к автовекторизации? )

S>>К авто не имеет, а к векторизации полное.

_>Ну так тогда и код не будет одинаковым, даже близко. ))) В C++ останется изначальный простенький цикл, а в C# надо будет нагородить всяких ужасов. А в вопросе речь шла об одинаковом коде.


А зачем городить? Наоборот для решения конкретной задачи свой инструмент.
S>>

S>> Вектор поддержкой SIMD типы, такие как Vector4, Matrix3x2, Plane, и Quaternion.

S>>Если тебе нужно решать задачу работы с матрицами выбирай нужные типы
S>>http://www.cyberforum.ru/post7461490.html
S>>http://habrahabr.ru/post/219841/

_>Это всё было в C++ (в виде библиотек) лет 15 назад и от этого уже давно уходят к совсем другим решениям. А в C# только сейчас к этому пришли. Поздравляю. )))


Это не C#, это .Net. Рано или поздно придут и к другим решениям и бОльшей оптимизации компилятора. Пока для Net куча других задач, а главное быстрота и удобство и безопасность программирования.
и солнце б утром не вставало, когда бы не было меня
Re[7]: Java vs C# vs C++
От: PM  
Дата: 26.09.15 07:57
Оценка:
Здравствуйте, alexzz, Вы писали:

A>Я написал свой вариант на C#, работает ещё быстрее оригинала, в 2,3 раза: http://pastebin.com/v2ZMRu86


A>original: 9881

A>optimized: 4342

Это хорошо, только вы ведь использовали internal unsafe class Program и fixed указатели для обработки массива. Немного волшебства и в этом соревновании двух бегунов C# пришел к финишу вторым, а С++ предпоследним

A>У меня давно сложилось и продолжает укрепляться подозрение, что C++ ощутимо (хотя бы раза в два) быстрее C# только там, где повезёт и задачу можно векторизовать, и компилятор C++ сумеет при этом применить свою векторизовальную магию. А если не повезёт, то быстрее может и вообще не получиться.


PM>>По ссылкам в новости о ScyllaDB написано, как получился такой результат. Разработчики решали конкретные проблемы, а не сравнивали результаты синтетических тестов.


A>Про то, что ускорение в 10 раз вызвал именно переход с Java на C++, упоминается лишь в желтушном заголовке новости.


Ок, если вам интересно как сравнивали Cassandra и Scylla, то разработчики этого не скрывают — http://www.scylladb.com/technology/cassandra-vs-scylla-benchmark/

В заголовок новости не поместилась информация о том, что они:
У меня есть сомнения, что первые 2 пункта легко реализуемы в управляемых средах (не знаю, добавили ли уже в Java value types)
Re[10]: Java vs C# vs C++
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 26.09.15 12:27
Оценка: :)
Здравствуйте, alex_public, Вы писали:

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


_>>>Кроме отсутствия автовекторизации, C# (а точнее .net) обладает ещё целым букетом замедляющих факторов, происходящих из самого устройства платформы. Это не говоря уже о просто слабом оптимизаторе.

G>>Это уже твои фантазии. Таких "замедляющих факторов" в любом языке полно, даже в c++. Более того, почти любые гарантии со стороны языка небесплатны. Супер оптимальный код будет супер небезопасным. А достаточно надежный код будет иметь "букет замедляющих факторов".

_>Что-то я не понял этого твоего высказвания) В первом предложение ты выступаешь против моего тезиса, а в следующих 4-ёх излагаешь подтверждающие его аргументы. )))


Специально для тебя повторю — замедляющих факторов полно в любом языке. Даже в С++ (одни смартпоинтеры чего стоят). А дальше логичный вывод — чем безопаснее программа, тем больше "замедляющих факторов" будет.

_>Да, а насчёт компромисса скорость/безопасность я собственно и не спорил. Хотя такое всё же не всегда происходит. К примеру такие вещи как "все функции виртуальные" и отсутствие полноценных нессылочных типов явно не приводят к какому-то увеличению безопасности... )

Это ты про Java надо полагать? Или решил показать незнание?
Так вот Java умеет девиртуализировать вызовы и размещать объекты на стеке. Руками не контролируется, делается путем анализа кода в JIT. Именно поэтому Java в математике весьма неплохо себя показывает. Так что недостаток языка вполне может быть (и на практике будет) скомпенсирован рантаймом. А вот когда дело касается реальной безопасности то, здравствуй "букет замедляющих факторов", независимо от языка.
Re[11]: Java vs C# vs C++
От: alex_public  
Дата: 26.09.15 13:42
Оценка: +1
Здравствуйте, Serginio1, Вы писали:

_>>Да, а насчёт компромисса скорость/безопасность я собственно и не спорил. Хотя такое всё же не всегда происходит. К примеру такие вещи как "все функции виртуальные" и отсутствие полноценных нессылочных типов явно не приводят к какому-то увеличению безопасности... )

S> А где это в .Net "все функции виртуальные"? Ты с Java не спутал?

Это было про языки программирования в целом. Тем более, что у нас как раз такой сабж. )

S>Другое дело, что С++ может больше использовать инлайн, что может приводить к ускорении при частом вызове таких функций.


Да, совершенно верно верно. Это один из главных причин. А другая главная причина — это уменьшение косвенности (которую ненавидят кэши процессора).
Re[11]: Java vs C# vs C++
От: alex_public  
Дата: 26.09.15 13:44
Оценка:
Здравствуйте, Serginio1, Вы писали:

_>>Это всё было в C++ (в виде библиотек) лет 15 назад и от этого уже давно уходят к совсем другим решениям. А в C# только сейчас к этому пришли. Поздравляю. )))

S> Это не C#, это .Net. Рано или поздно придут и к другим решениям и бОльшей оптимизации компилятора. Пока для Net куча других задач, а главное быстрота и удобство и безопасность программирования.

Кстати, в C++ от этого уходили когда-то исключительно из-за неудобства такой работы для программиста. Но сейчас актуальны и другие причины. К примеру на современных компьютерах при таком подходе необходимо использовать уже vector8, а не vector4. А в ближайшем будущем понадобится уже и vector16. )))
Re[11]: Java vs C# vs C++
От: alex_public  
Дата: 26.09.15 13:52
Оценка: +1
Здравствуйте, gandjustas, Вы писали:

_>>Что-то я не понял этого твоего высказвания) В первом предложение ты выступаешь против моего тезиса, а в следующих 4-ёх излагаешь подтверждающие его аргументы. )))

G>Специально для тебя повторю — замедляющих факторов полно в любом языке. Даже в С++ (одни смартпоинтеры чего стоят). А дальше логичный вывод — чем безопаснее программа, тем больше "замедляющих факторов" будет.

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

Ну и насчёт смартпоинтеров... Интересно глянуть где ты там найдёшь замедление скажем у std::unique_ptr (основной современный инструмент для таких целей).

_>>Да, а насчёт компромисса скорость/безопасность я собственно и не спорил. Хотя такое всё же не всегда происходит. К примеру такие вещи как "все функции виртуальные" и отсутствие полноценных нессылочных типов явно не приводят к какому-то увеличению безопасности... )

G>Это ты про Java надо полагать? Или решил показать незнание?

И Java и многие другие. )

G>Так вот Java умеет девиртуализировать вызовы и размещать объекты на стеке. Руками не контролируется, делается путем анализа кода в JIT. Именно поэтому Java в математике весьма неплохо себя показывает. Так что недостаток языка вполне может быть (и на практике будет) скомпенсирован рантаймом. А вот когда дело касается реальной безопасности то, здравствуй "букет замедляющих факторов", независимо от языка.


Да, для меня было весьма неожиданно, что жабка обошла C# (хотя и совсем на копейки) в обсуждаемом выше тесте. Но до реального быстродействия ей всё равно далеко.
Re[8]: Java vs C# vs C++
От: alexzz  
Дата: 26.09.15 17:05
Оценка:
Здравствуйте, alex_public, Вы писали:

A>>У меня давно сложилось и продолжает укрепляться подозрение, что C++ ощутимо (хотя бы раза в два) быстрее C# только там, где повезёт и задачу можно векторизовать, и компилятор C++ сумеет при этом применить свою векторизовальную магию. А если не повезёт, то быстрее может и вообще не получиться.


_>Это неверное подозрение. Что очевидно и из практики (см. ссылку выше, там есть цифры для C++ без simd) и из общетеоретических соображений. Кроме отсутствия автовекторизации, C# (а точнее .net) обладает ещё целым букетом замедляющих факторов, происходящих из самого устройства платформы. Это не говоря уже о просто слабом оптимизаторе.


Но ведь твоя таблица как раз подтверждает мои подозрения: C++ no-simd — 3,5 c, мой код на C# — 4,6 с. Разница в 1,3 раза. Не в два и даже не в полтора. Это как 1,3 vs 1,0 с (и то, и другое быстро) или 130 vs 100 с (и то, и другое медленно). Ощутимо быстрее C++ стал, только когда компилятор сумел что-то векторизовать. Я об этом и говорил — С++ становится ощутимо быстр, если повезёт с векторизацией; если нет, то С++ либо незначительно быстрее, либо вообще не быстрее.

Кстати, можно посмотреть бинарники C++, которые показывают 1,3 и 0,6 с? Мне любопытно посмотреть, что там наколдовано.

И ещё, пользуясь случаем, вопросы не в тему:
— Код делает HDR-blur? Если нет, то почему int[], а не byte[]?
— Зачем там условие внутри циклов?
Re[8]: Java vs C# vs C++
От: alexzz  
Дата: 26.09.15 17:19
Оценка:
Здравствуйте, PM, Вы писали:

A>>original: 9881

A>>optimized: 4342

PM>Это хорошо, только вы ведь использовали internal unsafe class Program и fixed указатели для обработки массива.


Это же штатный функционал. Надо — используешь, не надо — не используешь. Я давно заметил, что у некоторых товарищей (обычно в основном пишущих на C++) имеется фобия на указатели в C#, но ни я, ни C# в этом не виноваты
Re[9]: Java vs C# vs C++
От: xRAZORx  
Дата: 26.09.15 18:05
Оценка:
Здравствуйте, alexzz, Вы писали:

A>Но ведь твоя таблица как раз подтверждает мои подозрения: C++ no-simd — 3,5 c, мой код на C# — 4,6 с. Разница в 1,3 раза. Не в два и даже не в полтора. Это как 1,3 vs 1,0 с (и то, и другое быстро) или 130 vs 100 с (и то, и другое медленно). Ощутимо быстрее C++ стал, только когда компилятор сумел что-то векторизовать. Я об этом и говорил — С++ становится ощутимо быстр, если повезёт с векторизацией; если нет, то С++ либо незначительно быстрее, либо вообще не быстрее.


То есть получается, что джава вообще в хвосте плетется как всегда, да?
Re[9]: Java vs C# vs C++
От: alex_public  
Дата: 26.09.15 21:02
Оценка: 18 (1)
Здравствуйте, alexzz, Вы писали:

_>>Это неверное подозрение. Что очевидно и из практики (см. ссылку выше, там есть цифры для C++ без simd) и из общетеоретических соображений. Кроме отсутствия автовекторизации, C# (а точнее .net) обладает ещё целым букетом замедляющих факторов, происходящих из самого устройства платформы. Это не говоря уже о просто слабом оптимизаторе.

A>Но ведь твоя таблица как раз подтверждает мои подозрения: C++ no-simd — 3,5 c, мой код на C# — 4,6 с. Разница в 1,3 раза. Не в два и даже не в полтора. Это как 1,3 vs 1,0 с (и то, и другое быстро) или 130 vs 100 с (и то, и другое медленно). Ощутимо быстрее C++ стал, только когда компилятор сумел что-то векторизовать. Я об этом и говорил — С++ становится ощутимо быстр, если повезёт с векторизацией; если нет, то С++ либо незначительно быстрее, либо вообще не быстрее.

Ну во-первых твой код — это не C#, а unsafe C#, что существенно. Причём даже не просто unsafe (в смысле модификатора), а ещё и дико страшный из-за необходимости обхода всех штатных тормозов. Т.е. писать так код постоянно — это убиться. ))) А во-вторых для подобных циклов компилятору C++ "повезёт" всегда. Т.е. эти 3,5 секунды — это исключительно для полноты теста, а на практике их никогда не будет.

A>Кстати, можно посмотреть бинарники C++, которые показывают 1,3 и 0,6 с? Мне любопытно посмотреть, что там наколдовано.


Эмм, так код для варианта 3,5 секунды и 1,3 секунды абсолютно одинаковый. Разница только в опциях компилятора. И этот код я уже показывал в том обсуждение: http://rsdn.ru/forum/flame.comp/6072279.1
Автор: alex_public
Дата: 09.06.15


Что касается варианта с 0,6 секунды, то его сейчас под рукой нет, но я могу его описать: там уже используется ручная векторизация (intrinsics), а не автовекторизация. И да, код там уже не такой симпатичный, но зато выжимает из процессора всю теоретически допустимую мощь (в расчёте на ядро).

A>И ещё, пользуясь случаем, вопросы не в тему:

A>- Код делает HDR-blur? Если нет, то почему int[], а не byte[]?

Ну вообще то изначально этот код был просто специально для теста выбран (до него кстати в тесте был другой, с плавающей точкой, но там возникли большие неоднозначности в сравнения разных языков). Но у него естественно есть реальный прообраз. И нет, это естественно не blur (зачем может быть blur настолько многократный?), а одна из разновидностей клеточного автомата. Кстати, сразу замечу, что подобные автоматы — это не обязательно весёлая игрушка программистов. К примеру подобный код может моделировать различные физические процессы (соответствующие диф. уравнения совпадают), скажем распространения тепла в твёрдом теле. Ну и в любом случае, даже без понимания сути процессов, таким образом можно получать весьма любопытные картинки. Т.е. вот даже та жалкая тысяча итераций из нашего теста даёт вот такое:
  Скрытый текст
А если сделать в 100 раз больше итерация, то пойдут уже весьма сюрреалистичные картинки. )

A>- Зачем там условие внутри циклов?


1. С точки зрения теста хотелось что посложнее (данный if сильно гадит оптимизатору в любом языке).
2. С точки зрения клеточного автомата это означает, что белые точки (задаются в изначальном изображение) немодифицируемы.
3. С точки зрения моделирования процессов (того же тепла в твёрдом теле) это означает наличие источников тепла с фиксированной температурой.
Re[10]: Java vs C# vs C++
От: alexzz  
Дата: 26.09.15 23:45
Оценка:
Здравствуйте, alex_public, Вы писали:

_>Ну во-первых твой код — это не C#, а unsafe C#, что существенно. Причём даже не просто unsafe (в смысле модификатора), а ещё и дико страшный из-за необходимости обхода всех штатных тормозов.


Не понял конец фразы. Тормоза, связанные с закреплением объектов в памяти, они как Лохнесское чудовище — все про них слышали, но никто не видел. Надо просто соблюдать рекомендации.

_>Т.е. писать так код постоянно — это убиться. )))


Навскидку для 90% кода скорость вообще не важна — делаешь его красивым и удобным в обслуживании. Для ещё 9% просто используешь быстрый алгоритм, подходящие типы коллекций, многопоточность. В оставшихся случаях можно пошаманить:
— самодельные специфические коллекции,
— unsafe,
— Mono.Simd / System.Numerics,
— вызов нативного кода (самый неудобный вариант).

Короче, такого кода, где unsafe имеет смысл, надо пол-процента (если вообще надо). И пофиг, как он выглядит. Ты же не пишешь весь свой код интринзиками.

_>Ну вообще то изначально этот код был просто специально для теста выбран (до него кстати в тесте был другой, с плавающей точкой, но там возникли большие неоднозначности в сравнения разных языков). Но у него естественно есть реальный прообраз. И нет, это естественно не blur (зачем может быть blur настолько многократный?), а одна из разновидностей клеточного автомата.


Прикольно. Я свой вариант кода без изменений взял из моего старого исходника блюра Но раз это не он, то у меня надо заменить
var buffer = new int[image.Length];
на
var buffer = (int[])image.Clone();

Впрочем, на скорость расчётов это не влияет.

Имхо, с тысячами итераций тебе бы надо на GPU перейти, а не мучить С++.
Отредактировано 26.09.2015 23:46 alexzzzz . Предыдущая версия .
Re[3]: Java vs C# vs C++
От: uncommon Ниоткуда  
Дата: 27.09.15 01:58
Оценка: :))
Здравствуйте, alexzz, Вы писали:

A>Новость из реальной жизни — переписывание проекта с C++ на C# дало ускорение в 10 раз: http://blogs.msdn.com/b/jonathanh/archive/2005/05/20/optimizing-managed-c-vs-native-c-code.aspx

A>

A>Не, потом C++ разогнали с пятой попытки до скорости C#, но посмотрите, какой ценой!


О! Rico Mariani. Знаем, знаем. Пустослов известный. Больше всего он любит пи31415деть о процессе организации процесса улучшения процесса оптимизации процесса.
Re[11]: Java vs C# vs C++
От: alex_public  
Дата: 27.09.15 02:53
Оценка: 36 (1) +1
Здравствуйте, alexzz, Вы писали:

_>>Ну во-первых твой код — это не C#, а unsafe C#, что существенно. Причём даже не просто unsafe (в смысле модификатора), а ещё и дико страшный из-за необходимости обхода всех штатных тормозов.

A>Не понял конец фразы. Тормоза, связанные с закреплением объектов в памяти, они как Лохнесское чудовище — все про них слышали, но никто не видел. Надо просто соблюдать рекомендации.

Нет, здесь речь шла о том, что ты используешь *array вместо array[], чтобы обойти штатные тормоза из-за проверки границ массива. И это явно не способствует красоте кода. )))

_>>Т.е. писать так код постоянно — это убиться. )))

A>Навскидку для 90% кода скорость вообще не важна — делаешь его красивым и удобным в обслуживании. Для ещё 9% просто используешь быстрый алгоритм, подходящие типы коллекций, многопоточность. В оставшихся случаях можно пошаманить:
A>- самодельные специфические коллекции,
A>- unsafe,
A>- Mono.Simd / System.Numerics,
A>- вызов нативного кода (самый неудобный вариант).
A>Короче, такого кода, где unsafe имеет смысл, надо пол-процента (если вообще надо). И пофиг, как он выглядит. Ты же не пишешь весь свой код интринзиками.

Всё верно. И на C# и на C++ можно создать решение как в красивом и удобном стиле, так и в страшном и неудобном, но зато где-то в 2 раза более быстром (хотя для C++ это уже верно только для случаев с SIMD, т.к. в других случаях штатный оптимизатор круче любого спеца по ассемблеру). Только есть один нюанс: красивое решение на C# более чем в 6 раз медленнее красивого решения на C++.

Ну точнее если говорить по честному, то в 6+ раз оно будет быстрее только на подобном коде (с обработкой массивов и т.п.), а в обычном коде скорее всего будет 2+ раза. Но это тоже совсем не мало. ))) Да и обработка массивов тоже частенько встречается. )

A>Имхо, с тысячами итераций тебе бы надо на GPU перейти, а не мучить С++.


Ну вообще то по реальным делам у меня скорее вещи типа blur'a возникают (причём в реальном времени), а не конечные автоматы. Только последние гораздо удобнее для подобного теста, при почти одинаковом коде.

Но вообще может и попробую здесь GPU в ближайшее время — с появлением openacc это стало настолько же тривиально, как и распараллеливания по ядрам CPU с помощью openmp.
Re[12]: Java vs C# vs C++
От: alexzz  
Дата: 27.09.15 12:39
Оценка:
Здравствуйте, alex_public, Вы писали:

_>Нет, здесь речь шла о том, что ты используешь *array вместо array[], чтобы обойти штатные тормоза из-за проверки границ массива. И это явно не способствует красоте кода. )))


Нифига, звёздочки в два раза красивее квадратных скобочек!
Имхо, это очень субъективно. Мне лично оригинал с кучей [] и вычислений индексов тоже сильно не нравится, как выглядит. Это скорее вопрос форматирования/оформления кода.
Re[4]: Java vs C# vs C++
От: alexzz  
Дата: 27.09.15 13:10
Оценка:
Здравствуйте, uncommon, Вы писали:

U>О! Rico Mariani. Знаем, знаем. Пустослов известный. Больше всего он любит пи31415деть о процессе организации процесса улучшения процесса оптимизации процесса.


Во-первых, там не пиздё%, а сплошные циферки.
Во-вторых, браузер Edge таки очень шустр.
Re[7]: Java vs C# vs C++
От: Evgeny.Panasyuk Россия  
Дата: 27.09.15 13:58
Оценка: 6 (1) -1
Здравствуйте, alexzz, Вы писали:

A>У меня давно сложилось и продолжает укрепляться подозрение, что C++ ощутимо (хотя бы раза в два) быстрее C# только там, где повезёт и задачу можно векторизовать, и компилятор C++ сумеет при этом применить свою векторизовальную магию. А если не повезёт, то быстрее может и вообще не получиться.


1. Возьми тест из обсуждаемой статьи и сделай нормальный интерфейс для сортировки (например как у std::sort) — позволяющий сортировать последовательности из разных типов контейнеров, с разными типами элементов, и с разными предикатами сравнения, задаваемыми например замыканиями. Для пущей уверенности выключи любую автовекторизацию при замерах.

2. Посмотри вот этот пример
Автор: Evgeny.Panasyuk
Дата: 23.12.14
— оптимизаторы C++ щёлкают такой код на раз-два, выдавая ASM код идентичный ручной низкоуровневой версии.

3. Ещё такой пример
Автор: Evgeny.Panasyuk
Дата: 20.06.15
: высокоуровневый код C++ скомпилированный в JavaScript почти в два раза быстрее аналога на C# в своей родной среде.
JavaScript, в веб-браузере, Карл!

Во всех случаях никакой векторизации
Отредактировано 27.09.2015 14:04 Evgeny.Panasyuk . Предыдущая версия .
Re[2]: Java vs C# vs C++
От: airatsa Россия  
Дата: 28.09.15 04:38
Оценка: +1
Здравствуйте, lpd, Вы писали:

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


RAZ>>Тут читал на хабре статью по сравнению производительности C# и C++. Сам джаву знаю плохо, но, может быть, кто-то производил замеры сам? Было бы интересно посмотреть сравнение, тем более везде говорят, что шарп и джава одинаковые по скорости.


lpd>Однажды скомпилировал на Java целочисленные вычисления(БПФ), написанные на C++. Разница была в 8 раз.


В чью сторону?
Re[6]: Java vs C# vs C++
От: vdimas Россия  
Дата: 28.09.15 08:36
Оценка:
Здравствуйте, Nikе, Вы писали:

DR>>Встречал в сортировке по прозрачности, когда предметов в неправильном порядке мало и они идут друг за другом.

N>Сортировка вставками?

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