Что быстрее - Java или C# (или старый добрый C)? [закрытый]

Касательно; "Мои сравнительные тесты до сих пор показывают Java, и C о наравне друг с другом"

Затем Ваши сравнительные тесты сильно испорчены...

C ВСЕГДА будет заказами величин быстрее затем и C# и Java, если Вы не сделаете что-то серьезно неправильно...!

PS! Заметьте, что это не попытка попытаться не запугать ни C#, ни Java, мне нравятся и Java и C#, и существуют другие причины, почему Вы были бы для многих проблем выбирать Java или C# instead of C. Но ни Java, ни C# не были бы в корректные записанные тесты НИКОГДА не смочь работать с той же скоростью как C...

Отредактированный из-за чистого количества комментариев, приводящих доводы против моей риторики

Сравните эти двух педерастов...

C#

public class MyClass
{
   public int x;

   public static void Main()
   {
      MyClass[] y = new MyClass[1000000];
      for( int idx=0; idx < 1000000; idx++)
      {
          y[idx] = new MyClass();
          y[idx].x = idx;
      }
   }
}

против этого (C)

struct MyClass
{
   int x;
}

void Main()
{
   MyClass y[1000000];
   for( int idx = 0; idx < 1000000; idx++)
   {
      y[idx].x = idx;
   }
}

Версия C#, в первую очередь, должна сохранить свой массив на "куче". Версия C хранит массив на стеке. Сохранить материал на стеке просто изменяет значение целочисленного значения, в то время как сохранить материал на "куче", означает находить достаточно большой блок памяти и потенциально означает пересекать память в течение довольно долгого времени.

Теперь главным образом C# и Java выделяют огромные блоки памяти, которую они продолжают тратить, пока это не отсутствует, который заставляет эту логику выполниться быстрее. Но даже затем сравнить это с изменением значения целого числа похоже на F16 против нефтяного танкера speedwise...

Второй из всех в версии C, так как все те объекты уже находятся на стеке, мы не должны явно создавать новые объекты в цикле. Все снова и снова для C# это, "ищут доступную операцию памяти", в то время как версией C является ZIP (ничего не сделайте операция),

Треть из всех является тем, что версия C автоматически удалит все эти объекты, когда у них закончится объем. Все снова и снова это - операция, которая ТОЛЬКО ИЗМЕНЯЕТ ЗНАЧЕНИЕ ЦЕЛОЧИСЛЕННОГО ЗНАЧЕНИЯ AN. Который был бы на большинстве архитектур ЦП брать между 1 и 3 циклами ЦП. Версия C# не делает этого, но когда Сборщик "мусора" умирает и должен собрать те объекты, мое предположение - то, что мы говорим приблизительно МИЛЛИОНЫ циклов ЦП...

Также версия C немедленно станет x86-кодом (на x86 ЦП), в то время как версия C# сначала стала бы кодом IL. Затем позже при выполнении это должен будет быть скомпилированный JIT, который, вероятно, один слушается величин более длительное время затем только выполнение версии C.

Теперь некоторый мудрый парень мог, вероятно, выполнить вышеупомянутый код и измерить циклы ЦП. Однако это не в основном никакой смысл вообще в выполнении, потому что математически доказано, что Управляемая версия, вероятно, взяла бы несколько миллионов раз количество циклов ЦП как версия C. Таким образом, мое предположение - то, что мы теперь говорим приблизительно 5-8 заказов величин медленнее в этом примере. И уверенный, это - "манипулируемый тест", в котором я "искал что-то для подтверждения моей точки зрения", однако я бросаю вызов тем, которые прокомментировали плохо против меня на этом сообщении для создания образца, который НЕ выполняется быстрее в C и который также не использует конструкции, которые Вы обычно никогда не использовали бы в C из-за "лучших альтернатив", существующих.

Обратите внимание, что C# и Java являются БОЛЬШИМИ языками. Я предпочитаю их по C ЛЮБОЕ ВРЕМЯ СУТОК. Но не потому что они БЫСТРЕЕ. Поскольку они не. Они ВСЕГДА медленнее затем C и C++. Если Вы не кодировали ослепленный в C или C++...

Править;

C#, конечно, имеют ключевое слово структуры, которое серьезно изменило бы скорость для вышеупомянутого версия C#, если бы мы изменили класс C# на тип значения при помощи структуры ключевого слова вместо класса. Ключевое слово структуры означает, что C# хранил бы новые объекты данного типа на стеке - который для вышеупомянутого образца увеличит скорость серьезно. Тем не менее вышеупомянутый образец происходит с, также показывают массив этих объектов.

Даже при том, что, если бы мы прошли и оптимизировали версию C# как это, мы все еще закончили бы с чем-то несколько заказов величин медленнее затем версия C...

Хорошая записанная часть кода C ВСЕГДА будет быстрее затем C#, Java, Python и whatever-managed-language-you-choose...

Как я сказал, я люблю C# и большую часть работы, которую я делаю сегодня C# и не C. Однако я не использую C#, потому что это быстрее затем C. Я использую C#, потому что мне не нужен выигрыш в быстродействии C, дает мне для большинства моих проблем.

И C# и Java то, хотя смехотворно медленнее затем C, и C++ в этом отношении...

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

Я пошел бы с C# (или Java), потому что Ваше время разработки, вероятно, будет намного быстрее, чем с C. Если Вы заканчиваете тем, что нуждались в дополнительной скорости затем, можно всегда переписывать раздел в C и называть его как модуль.

Если бы Вы используете очень многопоточный код, я рекомендовал бы Вам смотреть на предстоящую Библиотеку параллели задачи (TPL) для.NET и Параллельную библиотеку шаблона (PPL) для собственных приложений C++. Это сохранит Вас много проблем с потоком lockíng / мертвым lockíng и всеми другими проблемами, в которые Вы провели бы много времени, роя и решив для себя. Для моего сам, я действительно полагаю, что управление памятью в управляемом мире будет более эффективным и разобьет собственный код в долгосрочной перспективе.

Я сожалею, но это не простой вопрос. Это во многом зависело бы от того, что точно продолжалось. C#, конечно, не сутулятся, и Вам было бы трудно говорить, что "Java быстрее", или "C# быстрее". C является совсем другим зверем... он, возможно, имеет потенциал, чтобы быть быстрее - если Вы разбираетесь в нем; но в большинстве случаев это будет о том же, но намного тяжелее записать.

Это также зависит, как Вы делаете это - блокировка стратегий, как Вы делаете распараллеливание, основное тело кода, и т.д.

Ре JIT - Вы могли использовать NGEN для выравнивания этого, но да; при ударе того же кода, это должен быть JITted очень вначале.

Одна очень полезная функция C#/Java (по C) - то, что у них есть потенциал для лучше использования локальный ЦП (оптимизация и т.д.) без Вас имеющий необходимость волноваться об этом.

Также - с.NET, рассмотрите вещи как "Параллельные Расширения" (чтобы быть связанным в 4,0), который дает Вам намного более сильную историю поточной обработки (по сравнению с.NET без PFX).

Я честно удивлен теми сравнительными тестами.

В в вычислительном отношении интенсивном продукте я поместил бы большое пари в C для выполнения быстрее. Вы могли бы написать код, который пропускает память как решето и имеет связанные дефекты интересной поточной обработки, но это должно быть быстрее.

Единственная причина я мог думать, что Java или C# будут быстрее, происходит из-за продолжительности короткого промежутка времени на тесте. Если минимальный GC произошел, Вы избежите издержек фактического освобождения памяти. Если процесс является итеративным или параллельным, попытайтесь засунуть GC.Collect везде, где Вы думаете, что сделаны набор объектов (после установки в NULL вещей или иначе удаления ссылок).

Кроме того, если Вы имеете дело с терабайтами данных, мое мнение, Вы собираетесь быть очень более обеспеченными с детерминированным выделением памяти, которое Вы получаете с C. Если Вы освободите примерно близко к тому, когда Вы выделяете свою "кучу", останется в основном нефрагментированным. Со средой GC можно закончить с программой, использующей намного больше памяти после достойной продолжительности выполнения, чем Вы предположили бы, только из-за фрагментации.

Мне это походит на вид проекта, где C был бы соответствующим языком, но потребует небольшого количества дополнительного внимания к выделению памяти / освобождение. Моя ставка - то, что C# или Java приведут к сбою, если работается полный набор данных.

Это собирается зависеть очень от того, что Вы делаете конкретно. У меня есть код Java, который бьет код C. У меня есть код Java, который намного медленнее, чем код C++ (я не делаю, C#/.NET так не может говорить с теми).

Так, это зависит от того, что Вы делаете, я уверен, что можно найти что-то, что быстрее на языке X, чем язык Y.

Вы попытались выполнить код C# через профилировщика для наблюдения, где требуется большая часть времени (то же с Java и C, в то время как Вы в нем). Возможно, необходимо сделать что-то другое.

Java HotSpot VM является более сформировавшимся (корни его возвращающийся к, по крайней мере, 1994), чем.NET один, таким образом, это может свестись к способностям к генерации кода обоих для этого.

Если уже существует значительное количество наследия C код, который будет добавлен к системе затем почему перемещение к C# и Java?

В ответ на Ваше последнее редактирование о желании использовать в своих интересах любые улучшения скорости обработки.... затем Ваш лучший выбор состоял бы в том, чтобы придерживаться C, поскольку это работает ближе к аппаратным средствам, чем C# и Java, которые имеют издержки среды выполнения для контакта с. Чем ближе к аппаратным средствам можно добраться, тем быстрее необходимо смочь работать. Высокоуровневые языки, такие как C# и Java закончатся в более быстрое время разработки..., но C... или еще лучше блок закончатся в более быстрое время обработки..., но более длительное время разработки.

На самом деле это - 'Ассемблер'.

Зависит от того, какое приложение Вы пишете. Попробуйте Игру Сравнительных тестов языка программирования

http://shootout.alioth.debian.org/u32q/benchmark.php?test=all&lang=csharp&lang2=java&box=1 http://shootout.alioth.debian.org/u64/benchmark.php?test=all&lang=csharp&lang2=java&box=1

Ваш вопрос сформулирован плохо (или в наименее название), поскольку это подразумевает, что это различие является эндемичным и справедливо для всех случаев кода java / c # / c.

К счастью, основная часть вопроса сформулирована лучше, потому что она представляет достаточно подробное объяснение такого рода вещей. твой код делает. В нем не указано, какие версии (или провайдеры) используемых вами C # / Java-сред. Также не указывается целевая архитектура или машина, на которой будет выполняться код. Эти вещи имеют большое значение.

Вы сделали несколько тестов, это хорошо. Некоторые предложения объясняют, почему вы видите результаты, которые вы делаете:

• Вы не ' так же хорош в написании кода на языке C #, как и в java / c (это не критика или даже вероятность, но это реальная возможность, которую вы должны рассмотреть) очень быстро запирает Это может исказить все в вашу пользу (и особенно сравнение с используемыми вами примитивами потоков реализации c).
• Поскольку Java-код работает хорошо по сравнению с кодом C, вполне вероятно, что вы не сильно зависите от кучи. стратегия распределения (профилирование скажет вам это).
• Поскольку код на c # работает хуже, чем код на Java (и предполагается, что код сопоставим), существует несколько возможных причин: или даже вероятно, но это реальная возможность, которую вы должны рассмотреть)
• Более поздние версии JVM имеют некоторые серьезные оптимизации, чтобы сделать непреднамеренные блокировки чрезвычайно быстрыми. Это может исказить все в вашу пользу (и особенно сравнение с используемыми вами примитивами потоков реализации c).
• Поскольку Java-код работает хорошо по сравнению с кодом C, вполне вероятно, что вы не сильно зависите от кучи. стратегия распределения (профилирование скажет вам это).
• Поскольку код на c # работает хуже, чем код на Java (и предполагается, что код сопоставим), существует несколько возможных причин: или даже вероятно, но это реальная возможность, которую вы должны рассмотреть)
• Более поздние версии JVM имеют некоторые серьезные оптимизации, чтобы сделать непреднамеренные блокировки чрезвычайно быстрыми. Это может исказить все в вашу пользу (и особенно сравнение с используемыми вами примитивами потоков реализации c).
• Поскольку Java-код работает хорошо по сравнению с кодом C, вполне вероятно, что вы не сильно зависите от кучи. стратегия распределения (профилирование скажет вам это).
• Поскольку код на c # работает хуже, чем код на Java (и предполагается, что код сопоставим), существует несколько возможных причин: Это может исказить все в вашу пользу (и особенно сравнение с используемыми вами примитивами потоков реализации c).
• Поскольку Java-код работает хорошо по сравнению с кодом C, вполне вероятно, что вы не сильно зависите от кучи. стратегия распределения (профилирование скажет вам это).
• Поскольку код на c # работает хуже, чем код на Java (и предполагается, что код сопоставим), существует несколько возможных причин: Это может исказить все в вашу пользу (и особенно сравнение с используемыми вами примитивами потоков реализации c).
• Поскольку Java-код работает хорошо по сравнению с кодом C, вполне вероятно, что вы не сильно зависите от кучи. стратегия распределения (профилирование скажет вам это).
• Поскольку код на c # работает хуже, чем код на Java (и предполагается, что код сопоставим), существует несколько возможных причин:
  • Вы используете (без необходимости) виртуальные функции, которые JVM встроит, но CLR не сделает. манипуляции, время жизни которых связано со стеком
  • Только самые последние 32-битные CLR будут встроенными методами, включающими не примитивные структуры
  • Некоторые JVM JIT-компиляторы используют механизмы стиля горячих точек, которые пытаются обнаружить «горячие точки» кода и тратить больше усилий на -jiting их.

Без понимания того, на что тратит ваш код большую часть своего времени, невозможно сделать конкретные предложения. Я могу довольно легко написать код, который работает намного лучше в CLR из-за использования структур над объектами или нацеливание на специфические функции среды CLR, такие как непакетные генерики,это вряд ли поучительно как общее утверждение.

Чтобы повторить комментарий, вы должны использовать графический процессор, а не процессор, если вы выполняете арифметические научные вычисления. Matlab с плагинами CUDA был бы намного более крутым, чем Java или c #, если бы лицензирование Matlab не было проблемой. Документация по nVidia показывает, как скомпилировать любую функцию CUDA в mex-файл. Если вам нужно бесплатное программное обеспечение, мне нравится pycuda. ​​

Если, однако, графические процессоры не являются опцией, мне лично нравится C для многих подпрограмм, потому что оптимизации, которые делает компилятор, не так сложны, как JIT: вам не нужно беспокоиться о том, становится ли «класс» как «структура» или нет. По моему опыту, проблемы обычно можно разбить так, чтобы вещи более высокого уровня могли быть написаны на очень выразительном языке, таком как Python (богатые примитивы, динамические типы,

Don't worry about language; parallelize!

If you have a highly multithreaded, data-intensive scientific code, then I don't think worrying about language is the biggest issue for you. I think you should concentrate on making your application parallel, especially making it scale past a single node. This will get you far more performance than just switching languages.

As long as you're confined to a single node, you're going to be starved for compute power and bandwidth for your app. On upcoming many-core machines, it's not clear that you'll have the bandwidth you need to do data-intensive computing on all the cores. You can do computationally intensive work (like a GPU does), but you may not be able to feed all the cores if you need to stream a lot of data to every one of them.

I think you should consider two options:

1. MapReduce
   Your problem sounds like a good match for something like Hadoop, which is designed for very data-intensive jobs.

   Hadoop has scaled to 10,000 nodes on Linux, and you can shunt your work off either to someone else's (e.g. Amazon's, Microsoft's) or your own compute cloud. It's written in Java, so as far as porting goes, you can either call your existing C code from within Java, or you can port the whole thing to Java.

2. MPI
   If you don't want to bother porting to MapReduce, or if for some reason your parallel paradigm doesn't fit the MapReduce model, you could consider adapting your app to use MPI. This would also allow you to scale out to (potentially thousands) of cores. MPI is the de-facto standard for computationally intensive, distributed-memory applications, and I believe there are Java bindings, but mostly people use MPI with C, C++, and Fortran. So you could keep your code in C and focus on parallelizing the performance-intensive parts. Take a look at OpenMPI for starters if you are interested.

I participated in a few TopCoder's Marathon matches where performance was they key to victory.

My choice was C#. I think C# solutions placed slightly above Java and were slighly slower than C++... Until somebody wrote a code in C++ that was a order of magnitude faster. You were alowed to use Intel compiler and the winning code was full of SIMD insturctions and you cannot replicate that in C# or Java. But if SIMD is not an option, C# and Java should be good enough as long as you take care to use memory correctly (e.g. watch for cache misses and try to limit memory access to the size of L2 cache)

Некоторое время назад Раймонд Чен и Рико Мариани опубликовали серию постов в блоге, постепенно оптимизирующих загрузку файлов в инструмент словаря. Несмотря на то, что .NET был быстрее на раннем этапе (то есть его легко было сделать), подход C / Win32 в конечном итоге оказался значительно быстрее, но со значительной сложностью (например, с использованием пользовательских распределителей).

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

Первая и последняя записи в блоге о производительности:

Если каждый процент действительно сэкономит вам десятки тысяч долларов, то вам следует пригласить эксперта по домену, чтобы помочь с проектом. Хорошо разработанный и написанный код с учетом производительности на начальных этапах может быть на порядок быстрее, сэкономив вам 90% или 900 000 долларов. Недавно я обнаружил тонкий недостаток в коде, который ускорил процесс более чем в 100 раз. Мой коллега нашел алгоритм, который работал в O (n ^ 3), который он переписал, чтобы сделать его O (N log n). Как правило, именно в этом и заключается огромная экономия производительности.

Если проблема настолько проста, что вы уверены, что лучший алгоритм не сможет обеспечить значительную экономию, то C, скорее всего, ваш лучший язык.

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

Даже для кэша второго уровня большая программа, такая как Quake IV, получает повышение производительности на 10% с 4 МБ кэш-памяти уровня 2 по сравнению с 1 МБ кэш-памяти уровня 2 - http://www.tomshardware.com/reviews/cache-size-matter,1709-5.html

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

Следует отметить, что ЕСЛИ ваши заявки выиграют от ленивых вычислений a Функциональный язык программирования, такой как , Haskell , может дать ускорения совершенно другой величины, чем оптимально структурированный / OO-код, просто не оценивая ненужные ветви.

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

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

Оптимизация - это поиск и устранение узких мест.

Очевидным узким местом является пропускная способность для наборов данных. Учитывая размер данных, я предполагаю, что данные хранятся на сервере, а не на настольном компьютере. Вы не дали никаких подробностей об используемых вами алгоритмах. Время, затраченное алгоритмом, больше времени, затраченного на чтение / запись данных / результатов? Работает ли алгоритм на подмножествах общих данных?

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

У вас есть два сценария, которые необходимо рассмотреть:

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

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

В первом случае вам нужен разработчик, который может написать хороший код на ассемблере, чтобы получить максимальную отдачу от процессоров, которые вы используете, используя SIMD , Графические процессоры и многоядерные системы, если они доступны. Что бы вы ни делали, не просто увеличивайте количество потоков, потому что, как только количество потоков превышает количество ядер, ваш код замедляется! Это связано с дополнительными издержками переключения потоков. Другой вариант - использовать систему распределенной обработки, подобную SETI (сколько компьютеров в вашей организации используется для целей администрирования - подумайте обо всех этих запасных вычислительных мощностях!). C # / Java, как упоминалось в bh213, может быть на порядок медленнее, чем хорошо написанный C / C ++ с использованием SIMD и т. Д. Но в наши дни это нишевой навык.

В последнем случае, когда вы ограничены пропускной способностью Затем вам нужно улучшить сеть, соединяющую данные с процессором. Здесь убедитесь, что вы используете новейшее сетевое оборудование - 1 Гбит / с везде (карты ПК, коммутаторы, маршрутизаторы и т. Д.). Не используйте беспроводной, поскольку это медленнее. Если есть много другого трафика, рассмотрите выделенную сеть параллельно с офисной сетью. Рассмотрите возможность хранения данных ближе к клиентам - для каждых пяти или около того клиентов используйте выделенный сервер, подключенный непосредственно к каждому клиенту, который отражает данные с сервера.

Если экономия нескольких процентов времени обработки экономит «десятки тысяч долларов» «Тогда серьезно подумайте о привлечении консультанта, двух на самом деле - одного программного обеспечения, одной сети. Они должны легко окупить себя сделанными сбережениями. Я уверен, что здесь есть много подходящих для этого людей.

Но если конечной целью является снижение затрат, то рассмотрим подход Google - написать код, который удерживает ЦП ниже 100%. Это позволяет экономить энергию прямо и косвенно за счет снижения охлаждения, а значит, обходится дешевле. Вам понадобится больше отдачи, так что это снова C / C ++ - Java / C # имеют больше накладных расходов,

Я бы предпочел C или C ++, потому что я не отделен от машинного языка компилятором JIT.

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

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

Что бы я НЕ делал, если бы я был на вашем месте (или когда-либо), полагался на анекдотические обобщения о том, что один язык быстрее или медленнее другого. То, что я хотел бы сделать, - это несколько проходов интенсивной настройки производительности в соответствии с НАСТОЯЩИМ и НАСТОЯЩИМ и НАСТОЯЩИМ . Я делал подобные вещи много раз, и ключ в том, чтобы повторить цикл диагностики и ремонта, потому что каждый исправленный слизень делает более очевидными оставшиеся, пока вы буквально не сможете выжать еще один цикл из этой репы.

Удачи.

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

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

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

Кроме того, я обнаружил, что приложения C # имеют в некоторых областях производительность, которая несколько ниже оптимальной, многопоточность является одним. .NET постарается защитить вас от проблем с потоками (вероятно, это хорошо в большинстве случаев), но это вызовет проблемы вашего конкретного случая (для проверки: попробуйте написать простой цикл, который обращается к общему объекту с использованием большого количества потоков. Запустите его на одноядерном ПК, и вы получите лучшую производительность, чем если бы вы запускали его на многоядерном блоке - .net добавляет свои собственные блокировки, чтобы убедиться, что вы не испортили его) (я использовал синглтон Джона Скита Тест на статическую блокировку занял 1,5 с на моем старом ноутбуке, 8,5 с на сверхбыстром рабочем столе, версия с блокировкой еще хуже, попробуйте сами)

Следующий момент заключается в том, что с C вы, как правило, получаете доступ к памяти и данные напрямую - ничто не мешает, с C # / Java вы будете использовать некоторые из множества классов, которые предоставляются. В общем случае это будет хорошо, но вы ищете лучший и наиболее эффективный способ получить к нему доступ (который, в вашем случае, имеет большое значение для мульти-терабайт данных, эти классы не были разработаны с учетом этих наборов данных) , они были разработаны для общих случаев, которые все остальные используют), так что опять же,

Конечно, ответ - пойти и купить новейший ПК с максимальным количеством ядер / процессоров, которое вы можете себе позволить. Если вы купите один из новейших ПК с 2x4 ядрами, вы обнаружите, что он не только имеет вдвое больше ядер, чем четырехъядерный, но и работает на 25-40% быстрее, чем процессоры / машины предыдущего поколения.

Это даст вам примерно 150% ускорения. Намного больше, чем выбор Java / C # или C. и более того, вы получаете то же самое каждые 18 месяцев, если продолжаете покупать в новых коробках!

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

Улучшение качества / эффективности кода - это хорошо, но иногда средства на реализацию лучше потратить на что-то другое.

Написание на том или ином языке лишь немного ускорит выполнение большого объема работы. Чтобы действительно ускорить процесс, вы можете взглянуть на следующее:

1. Покупка новейшего самого быстрого оборудования.
2. Переход с 32-битной операционной системы на 64-битную.
3. Грид-вычисления.
4. CUDA / OpenCL.
5. Использование оптимизации компилятора, например векторизации.