Вы используете параллельные расширения?

Я использую TPL для выполнения вложенных Parallel.ForEach вызовов. Поскольку я обращаюсь к словарям из этих вызовов, я должен использовать ConcurrentDictionary. Хотя это приятно, у меня есть несколько проблем:

• Делегаты внутри ForEach мало работают, поэтому я не получаю особого параллелизма. Кажется, что система тратит большую часть времени на присоединение к потокам. Было бы неплохо, если бы был способ выяснить, почему параллелизм не улучшается, и улучшить его.

• Внутренние ForEach итерации превышают ConcurrentDictionary экземпляров, что заставило бы систему тратить большую часть своего времени на счетчики для словаря, если бы я не добавил кеш-счетчик.

• Многие из моих ConcurrentDictionary экземпляров на самом деле являются наборами, но нет ConcurrentSet, поэтому мне пришлось реализовать свой собственный с ConcurrentDictionary.

• ConcurrentDictionary не поддерживает синтаксис инициализации объекта, поэтому я не могу сказать var dict = new ConcurrentDictionary<char, int> { { 'A', 65 } };, что также означает, что я не могу назначать ConcurrentDictionary литералы членам класса.

• В некоторых местах мне нужно найти ключ в ConcurrentDictionary и вызвать дорогостоящую функцию для создания значения, если оно не существует. Было бы неплохо, если бы была перегрузка GetOrAdd, которая принимает addValueFactory, чтобы значение можно было вычислить, только если ключ не существует. Это можно смоделировать с помощью .AddOrUpdate(key, addValueFactory, (k, v) => v), но это добавляет накладные расходы на дополнительный вызов делегата для каждого поиска.

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

private static readonly char[] delimiters = { ' ', '.', ',', ';', '\'', '-', ':', '!', '?', '(', ')', '<', '>', '=', '*', '/', '[', ']', '{', '}', '\\', '"', '\r', '\n' };
private static readonly Func<string, string> theWord = Word;
private static readonly Func<IGrouping<string, string>, KeyValuePair<string, int>> theNewWordCount = NewWordCount;
private static readonly Func<KeyValuePair<string, int>, int> theCount = Count;

private static void Main(string[] args)
{
    foreach (var wordCount in File.ReadAllText(args.Length > 0 ? args[0] : @"C:\DEV\CountUniqueWords\CountUniqueWords\Program.cs")
        .Split(delimiters, StringSplitOptions.RemoveEmptyEntries)
        .AsParallel()
        .GroupBy(theWord, StringComparer.OrdinalIgnoreCase)
        .Select(theNewWordCount)
        .OrderByDescending(theCount))
    {
        Console.WriteLine(
            "Word: \""
            + wordCount.Key
            + "\" Count: "
            + wordCount.Value);
    }

    Console.ReadLine();
}

private static string Word(string word)
{
    return word;
}

private static KeyValuePair<string, int> NewWordCount(IGrouping<string, string> wordCount)
{
    return new KeyValuePair<string, int>(
        wordCount.Key,
        wordCount.Count());
}

private static int Count(KeyValuePair<string, int> wordCount)
{
    return wordCount.Value;
}

Я использую его в своем проекте MetaSharp. У меня есть конвейер компиляции на основе MSBuild для DSL, а одноэтапные типы - это этап от многих ко многим. На этапе M: M используется .AsParallel.ForAll (...).

Вот фрагмент:

protected sealed override IEnumerable<IContext> Process()
{
    if (this.Input.Count() > 1)
    {
        this.Input
            .AsParallel<IContext>()
            .ForAll(this.Process);
    }
    else if (this.Input.Any())
    {
        this.Process(this.Input.Single());
    }

    return this.Input.ToArray();
}

Мы не используем его широко, но он, безусловно, пригодился.

Мне удалось сократить время выполнения некоторых из наших более длительных модульных тестов примерно до 1/3 от исходного времени, просто заключив некоторые из наиболее трудоемких шагов в вызов Parallel.Invoke().

Мне также нравится использовать параллельные библиотеки для тестирования безопасности потоков. Я обнаружил и сообщил о нескольких проблемах с потоками в Ninject с примерно таким кодом:

var repositoryTypes = from a in CoreAssemblies
                    from t in a.GetTypes()
                    where t.Name.EndsWith("Repository")
                    select t;
repositoryTypes.ToList().AsParallel().ForAll(
    repositoryType => _kernel.Get(repositoryType));

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

Я использую ConcurrentDictionary, в котором хранится более 100 миллионов элементов. В данный момент мое приложение использует около 8 ГБ памяти. Затем ConcurrentDictionary решает, что он хочет расти на другом Add. И он, по-видимому, хочет значительно вырасти (какой-то внутренний алгоритм Prima), поскольку у него заканчивается память. Это на x64 с 32 ГБ памяти.

Поэтому я хотел бы, чтобы логическое значение блокировало автоматическое повторное создание / повторное хеширование (параллельного) словаря. Затем я бы инициализировал словарь при создании с фиксированным набором сегментов (это не то же самое, что фиксированная емкость!). И со временем это станет немного медленнее, так как в ведре будет все больше и больше предметов. Но это предотвратит повторное хеширование и слишком быстрое и ненужное вымывание из памяти.