ConcurrentDictionary не дает выгоды в производительности
От: igor-booch Россия  
Дата: 22.05.13 10:04
Оценка: :))) :))) :))
Задался вопросом: кто будет быстрее
обычный Dictionary на одном потоке
или ConcurrentDictionary на нескольких
Написал тест, результаты шокировали.
Даже на 8 ядерном процессоре Dictionary на одном потоке быстрее, чем ConcurrentDictionary на 8 потоках.
Ожидаемо самая высока производительность достигается при совпадении числа параллельных процессов с количеством ядер.
При дальнейшем увеличении количества параллельных процессов происходит деградация производительности.
Аномальные значения получаются при 2-х параллельных процессах, видимо на такое количество ядер оптимизированы механизмы синхронизации ConcurrentDictionary.

Вот тест:
using System;
using System.Collections.Concurrent;
using System.Collections.Generic;
using System.Diagnostics;
using System.Linq;
using System.Text;
using System.Threading;
using System.Threading.Tasks;

namespace DictionariesTest
{
    class Program
    {
        private const int _itarationsCount = 8000000;

        static void Main(string[] args)
        {
            Dictionary<int, string> dictionary = new Dictionary<int, string>();

            Console.WriteLine("Testing Dictionary in single thread...");
            Stopwatch stopwatch = new Stopwatch();
            stopwatch.Start();
            for (int i = 0; i < 8000000; i++)
            {
                dictionary.Add(i, i.ToString());
            }
            stopwatch.Stop();
            Console.WriteLine("Add: {0}", stopwatch.ElapsedMilliseconds);


            stopwatch.Reset();
            stopwatch.Start();
            for (int i = 0; i < 8000000; i++)
            {
                string s = dictionary[i];
            }
            stopwatch.Stop();
            Console.WriteLine("Get: {0}", stopwatch.ElapsedMilliseconds);
            Console.WriteLine(string.Empty);

            runConcurrentDictionaryTest(1);
            runConcurrentDictionaryTest(2);
            runConcurrentDictionaryTest(4);
            runConcurrentDictionaryTest(8);
            runConcurrentDictionaryTest(16);

            Console.ReadLine();
        }

        private static void runConcurrentDictionaryTest(int threadsCount)
        {
            ConcurrentDictionary<int, string> concurrentDictionary = new ConcurrentDictionary<int, string>();

            Console.WriteLine("Testing ConcurrentDictionary in {0} parallel treads...", threadsCount);

            Stopwatch stopwatch = new Stopwatch();
            stopwatch.Start();
            runInMultileThreads(threadsCount, i => concurrentDictionary.TryAdd(i, i.ToString()));
            stopwatch.Stop();
            Console.WriteLine("Add: {0}", stopwatch.ElapsedMilliseconds);

            stopwatch.Reset();
            stopwatch.Start();
            runInMultileThreads(threadsCount, i => {string result = concurrentDictionary[i];});
            stopwatch.Stop();
            Console.WriteLine("Get: {0}", stopwatch.ElapsedMilliseconds);

            Console.WriteLine(string.Empty);
        }

        private static void runInMultileThreads(int threadsCount, Action<int> iterationAction)
        {
            Thread[] threads = new Thread[threadsCount];
            int step = _itarationsCount / threadsCount;

            for (int threadNumber = 1; threadNumber <= threadsCount; threadNumber++)
            {
                int min = 1 + step * (threadNumber - 1);
                int max = step * threadNumber;
                Thread thread = new Thread(() =>
                {
                    for (int i = min; i <= max; i++)
                    {
                        iterationAction(i);
                    }
                });
                threads[threadNumber - 1] = thread;
            }

            foreach (Thread thread in threads)
            {
                thread.Start();
            }


            foreach (Thread thread in threads)
            {
                thread.Join();
            }

        }
    }
}



Результаты для Intel(R) Core(TM) i7-3770 @ 3.40GHz (8 логических ядра, 4 физических) процессора:

Testing Dictionary in single thread...
Add: 1959
Get: 103

Testing ConcurrentDictionary in 1 parallel treads...
Add: 5201
Get: 195

Testing ConcurrentDictionary in 2 parallel treads...
Add: 3787
Get: 102

Testing ConcurrentDictionary in 4 parallel treads...
Add: 4780
Get: 88

Testing ConcurrentDictionary in 8 parallel treads...
Add: 3425
Get: 70

Testing ConcurrentDictionary in 16 parallel treads...
Add: 5066
Get: 65

Здесь не понятны результаты для 2 параллельных процессов — выбиваются из тренда.




Результаты для Intel(R) Core(TM) i5-2400 (4 логических ядра, 4 физических):

Testing Dictionary in single thread...
Dictionary Add: 2606
Dictionary Get: 150

Testing ConcurrentDictionary in 1 parralel treads...
Add: 6448
Get: 359

Testing ConcurrentDictionary in 2 parallel treads...
Add: 4794
Get: 188

Testing ConcurrentDictionary in 4 parallel treads...
Add: 5239
Get: 279

Testing ConcurrentDictionary in 8 parallel treads...
Add: 6029
Get: 207

Testing ConcurrentDictionary in 16 parallel treads...
Add: 6500
Get: 294

Здесь не понятны результаты для 2 параллельных процессах — выбиваются из тренда.
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания
http://rsdn.ru/Info/rules.xml
Re: ConcurrentDictionary не дает выгоды в производительности
От: samius Япония http://sams-tricks.blogspot.com
Дата: 22.05.13 10:18
Оценка:
Здравствуйте, igor-booch, Вы писали:

IB>Задался вопросом: кто будет быстрее

IB>обычный Dictionary на одном потоке
IB>или ConcurrentDictionary на нескольких
IB>Написал тест, результаты шокировали.
IB>Даже на 8 ядерном процессоре Dictionary на одном потоке быстрее, чем ConcurrentDictionary на 8 потоках.
1. Может имеет смысл сравнивать результаты с одинаковым числом потоков и необходимой для Dictionary синхронизацией? Ведь ConcurrentDictionary прикручен не для того что бы обгонять Dictionary на 1-м потоке, а для того что бы не требовалась синхронизация потоков при доступе к Dictionary.
2. Может имеет смысл замерять без времени создания потоков?
Re[2]: ConcurrentDictionary не дает выгоды в производительности
От: igor-booch Россия  
Дата: 22.05.13 10:58
Оценка:
S>1. Может имеет смысл сравнивать результаты с одинаковым числом потоков и необходимой для Dictionary синхронизацией? Ведь ConcurrentDictionary прикручен не для того что бы обгонять Dictionary на 1-м потоке, а для того что бы не требовалась синхронизация потоков при доступе к Dictionary.
Тогда ConcurentDictionary будет быстрее конечно, у него механизмы синхронизации более низкоуровневные, чем в Monitor lock.
Такие тесты уже делались http://arbel.net/2013/02/03/best-practices-for-using-concurrentdictionary/
Я так понимаю что ConcurentDictionary нужен если программист выбирает между 2-мя следующими конструкциями:


lock (dictionary)
{
    dictionary.Add(key, value);
}



и


concurrentDictionary.TryAdd(key, value);



Здесь однозначно побеждает СoncurrentDictionary.

А если программист выбирает между

lock (locker)
{
    dictionary1.Add(key1, value1);
    dictionary2.Add(key2, value2);
    dictionary3.Add(key3, value3);
    dictionary4.Add(key4, value4);
    dictionary5.Add(key5, value5);
    dictionary6.Add(key6, value6);
    dictionary7.Add(key7, value7);
    dictionary8.Add(key8, value8);
    ...
}




и


concurrentDictionary1.TryAdd(key1, value1);
concurrentDictionary2.TryAdd(key2, value2);
concurrentDictionary3.TryAdd(key3, value3);
concurrentDictionary4.TryAdd(key4, value4);
concurrentDictionary5.TryAdd(key5, value5);
concurrentDictionary6.TryAdd(key6, value6);
concurrentDictionary7.TryAdd(key7, value7);
concurrentDictionary8.TryAdd(key8, value8);
...




то здесь скорей всего победит Dictionary.


S>2. Может имеет смысл замерять без времени создания потоков?

Сделал, результаты особо не изменились.
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания
http://rsdn.ru/Info/rules.xml
Re[3]: ConcurrentDictionary не дает выгоды в производительности
От: samius Япония http://sams-tricks.blogspot.com
Дата: 22.05.13 11:22
Оценка: +1
Здравствуйте, igor-booch, Вы писали:

S>>1. Может имеет смысл сравнивать результаты с одинаковым числом потоков и необходимой для Dictionary синхронизацией? Ведь ConcurrentDictionary прикручен не для того что бы обгонять Dictionary на 1-м потоке, а для того что бы не требовалась синхронизация потоков при доступе к Dictionary.

IB>Тогда ConcurentDictionary будет быстрее конечно, у него механизмы синхронизации более низкоуровневные, чем в Monitor lock.
Те же самые у него механизмы, тот же самый Monitor.Enter, только не весь контейнер блокируется эксклюзивно, а отдельные Bucket-ы + эксклюзивный GrowTable.
Кстати, именно эксклюзивным GrowTable можно объяснить увеличение времени работы на числе потоков > 2.

IB>Такие тесты уже делались http://arbel.net/2013/02/03/best-practices-for-using-concurrentdictionary/

IB>Я так понимаю что ConcurentDictionary нужен если программист выбирает между 2-мя следующими конструкциями:

Вот именно, назначение у ConcurrentDictionary другое. Это не быстрый словарь, это словарь, который в условиях многопоточности не нуждается в дополнительной синхронизации и работает быстрее чем обычный с синхронизацией.
И так как он использует те же самые Monitor.Enter для синхронизации, он по определению не сможет обогнать словарь без синхронизации на одном потоке. (если бы обогнал, то зачем бы нужен был Dictionary?).
Re: ConcurrentDictionary не дает выгоды в производительности
От: fddima  
Дата: 22.05.13 11:39
Оценка:
Здравствуйте, igor-booch, Вы писали:

Всё дело в тестовых данных я думаю, он не предназначен для такого синтетического теста и обязан проваливать его.
ConcurrentDictionary использует кучу блокировок, для того что бы лочить только часть таблицы на время блокировки.
Однако он делает это на основе хэш кода — hashCode % numberOfLocks.
В результате — когда добавляем целочисленные ключи 1...N — имеем наихудший сценарий, когда все потоки последовательно бегут по всем блокировкам, и скорее всего ещё и дерутся за них.
Re: ConcurrentDictionary не дает выгоды в производительности
От: 0x7be СССР  
Дата: 22.05.13 11:51
Оценка:
Здравствуйте, igor-booch, Вы писали:

IB>Написал тест, результаты шокировали.

Тест не корректен: при тестировании параллельного кода в замеры времени попадает создание потоков.
Re[4]: ConcurrentDictionary не дает выгоды в производительности
От: igor-booch Россия  
Дата: 22.05.13 11:56
Оценка:
S>Те же самые у него механизмы, тот же самый Monitor.Enter, только не весь контейнер блокируется эксклюзивно, а отдельные Bucket-ы + эксклюзивный GrowTable.
Да те же, чего-то мне показалось, что я там MemoryBarrier видел, наверное где-то в другом месте видел.


S>Кстати, именно эксклюзивным GrowTable можно объяснить увеличение времени работы на числе потоков > 2.

Можно поподробнее? Вот метод, который выполняется в начале GetRowTable:


    private void AcquireLocks(int fromInclusive, int toExclusive, ref int locksAcquired)
    {
      object[] objArray = this.m_tables.m_locks;
      for (int index = fromInclusive; index < toExclusive; ++index)
      {
        bool lockTaken = false;
        try
        {
          Monitor.Enter(objArray[index], ref lockTaken);
        }
        finally
        {
          if (lockTaken)
            ++locksAcquired;
        }
      }
    }


Почему они просто не написали, Monitor.Enter(this) для эксклюзивной блокировки?


S>И так как он использует те же самые Monitor.Enter для синхронизации, он по определению не сможет обогнать словарь без синхронизации на одном потоке. (если бы обогнал, то зачем бы нужен был Dictionary?).

Обгонял бы на 8 потоках, было бы с него больше толку.
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания
http://rsdn.ru/Info/rules.xml
Re[2]: ConcurrentDictionary не дает выгоды в производительности
От: igor-booch Россия  
Дата: 22.05.13 11:58
Оценка:
0>Тест не корректен: при тестировании параллельного кода в замеры времени попадает создание потоков.
На результаты влияет незначительно
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания
http://rsdn.ru/Info/rules.xml
Re[3]: ConcurrentDictionary не дает выгоды в производительности
От: 0x7be СССР  
Дата: 22.05.13 12:00
Оценка:
Здравствуйте, igor-booch, Вы писали:

0>>Тест не корректен: при тестировании параллельного кода в замеры времени попадает создание потоков.

IB>На результаты влияет незначительно
Верю, но тем не менее
Re: ConcurrentDictionary не дает выгоды в производительности
От: 0x7be СССР  
Дата: 22.05.13 12:01
Оценка:
Здравствуйте, igor-booch, Вы писали:

IB>Написал тест, результаты шокировали.

Попробуй заюзать Parallel.For
Re[2]: ConcurrentDictionary не дает выгоды в производительности
От: igor-booch Россия  
Дата: 22.05.13 12:04
Оценка:
0>Тест не корректен: при тестировании параллельного кода в замеры времени попадает создание потоков.
Если тест служит для выбора между одно поточной реализацией и многопоточной, то все корректно: создание потоков это издержки многопоточной реализации
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания
http://rsdn.ru/Info/rules.xml
Re[2]: ConcurrentDictionary не дает выгоды в производительности
От: igor-booch Россия  
Дата: 22.05.13 12:09
Оценка: -1
0>Попробуй заюзать Parallel.For
Медленней будет, Parallel.For каждую итерацию будет в отдельном потоке выполнять.
Хотя конечно используется пул потоков, но все-равно должно быть медленнее.
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания
http://rsdn.ru/Info/rules.xml
Re[3]: ConcurrentDictionary не дает выгоды в производительности
От: 0x7be СССР  
Дата: 22.05.13 12:13
Оценка:
Здравствуйте, igor-booch, Вы писали:

IB>Медленней будет, Parallel.For каждую итерацию будет в отдельном потоке выполнять.

IB>Хотя конечно используется пул потоков, но все-равно должно быть медленнее.
Рекомендую проверить экспериметном, поскольку есть сильное подозрение, что выделенное неверно.
Re[5]: ConcurrentDictionary не дает выгоды в производительности
От: samius Япония http://sams-tricks.blogspot.com
Дата: 22.05.13 12:14
Оценка:
Здравствуйте, igor-booch, Вы писали:

S>>Те же самые у него механизмы, тот же самый Monitor.Enter, только не весь контейнер блокируется эксклюзивно, а отдельные Bucket-ы + эксклюзивный GrowTable.

IB>Да те же, чего-то мне показалось, что я там MemoryBarrier видел, наверное где-то в другом месте видел.
Может там он и есть, но блокировки обычные Monitor.Enter

S>>Кстати, именно эксклюзивным GrowTable можно объяснить увеличение времени работы на числе потоков > 2.

IB>Можно поподробнее? Вот метод, который выполняется в начале GetRowTable:
Да, выполняется.

IB>Почему они просто не написали, Monitor.Enter(this) для эксклюзивной блокировки?

Monitor.Enter(this) — моветон. Во всем остальном я не берусь отвечать, почему они вызывают именно тот метод. Может быть потому что используют специальную таблицу объектов для блокировки, а не this.
И метод Monitor.Enter(object, bool) получает точно такую же эксклюзивную блокировку, как и Monitor.Enter(object).

S>>И так как он использует те же самые Monitor.Enter для синхронизации, он по определению не сможет обогнать словарь без синхронизации на одном потоке. (если бы обогнал, то зачем бы нужен был Dictionary?).

IB>Обгонял бы на 8 потоках, было бы с него больше толку.
Напишите такой что бы обгонял, предложите свою реализацию команде дотнета. Возможно скажут спасибо.
Re[6]: ConcurrentDictionary не дает выгоды в производительности
От: igor-booch Россия  
Дата: 22.05.13 12:40
Оценка:
S>Напишите такой что бы обгонял, предложите свою реализацию команде дотнета. Возможно скажут спасибо.
Здесь нужна будет более тонкая синхронизация (например с MemoryBarrier).
Даже если я напишу мне не поверят, что реализация надежная.
Мне кажется здесь нужно будет математически это будет доказывать.
А это уже сложная для меня задача.
А есть подобные реализации от сторонних производителей?
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания
http://rsdn.ru/Info/rules.xml
Re[7]: ConcurrentDictionary не дает выгоды в производительности
От: samius Япония http://sams-tricks.blogspot.com
Дата: 22.05.13 13:11
Оценка:
Здравствуйте, igor-booch, Вы писали:

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

IB>Здесь нужна будет более тонкая синхронизация (например с MemoryBarrier).
Lock free что ли? memory barrier сам по себе не есть средство синхронизации.
IB>Даже если я напишу мне не поверят, что реализация надежная.
IB>Мне кажется здесь нужно будет математически это будет доказывать.
IB>А это уже сложная для меня задача.
Сомневаюсь что есть какое-то доказательство для текущего кода из BCL.

IB>А есть подобные реализации от сторонних производителей?

Подобные чему? По поводу lock-free — не знаю, есть ли что-то стабильное, но вообще подобные ConcurrentDictionary должны быть.
Re[8]: ConcurrentDictionary не дает выгоды в производительности
От: igor-booch Россия  
Дата: 22.05.13 13:22
Оценка:
S>Сомневаюсь что есть какое-то доказательство для текущего кода из BCL.
Я думаю нужно не сначала писать код, а потом доказывать его стабильность,
а наоборот, сначала, создать алгоритм, доказать его стабильность,
и уж потом реализовать его, возможно при этом понадобится расширение BCL

S>Подобные чему? По поводу lock-free — не знаю, есть ли что-то стабильное, но вообще подобные ConcurrentDictionary должны быть.

Не обязательно lock-free, главное чтобы обгонял на 4 или 8 потоках однопоточную реализацию
Я не встречал нигде
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания
http://rsdn.ru/Info/rules.xml
Re[5]: ConcurrentDictionary не дает выгоды в производительности
От: pugv Россия  
Дата: 22.05.13 13:30
Оценка:
Здравствуйте, igor-booch, Вы писали:

IB>Почему они просто не написали, Monitor.Enter(this) для эксклюзивной блокировки?


Хотя бы потому, что lock(this) — зло. Так же как lock(typeof(this)) и любые публично доступные экземпляры.
Re[9]: ConcurrentDictionary не дает выгоды в производительности
От: samius Япония http://sams-tricks.blogspot.com
Дата: 22.05.13 13:44
Оценка:
Здравствуйте, igor-booch, Вы писали:

S>>Сомневаюсь что есть какое-то доказательство для текущего кода из BCL.

IB>Я думаю нужно не сначала писать код, а потом доказывать его стабильность,
IB>а наоборот, сначала, создать алгоритм, доказать его стабильность,
IB>и уж потом реализовать его, возможно при этом понадобится расширение BCL
Расширение BCL для своего алгоритма? Интересно. А что такого может понадобиться от BCL, чего нельзя написать самому?

S>>Подобные чему? По поводу lock-free — не знаю, есть ли что-то стабильное, но вообще подобные ConcurrentDictionary должны быть.

IB>Не обязательно lock-free, главное чтобы обгонял на 4 или 8 потоках однопоточную реализацию
На чтении стабильно обгоняет ConcurrentDictionary. Добавление — да, медленнее. Но оно и понятно. Попробуйте уменьшить GrowTable с помощью задания размера в конструкторе — и время приблизится к обычному словарю.
IB>Я не встречал нигде
А я не искал.
Re[6]: ConcurrentDictionary не дает выгоды в производительности
От: igor-booch Россия  
Дата: 22.05.13 13:44
Оценка:
IB>>Почему они просто не написали, Monitor.Enter(this) для эксклюзивной блокировки?
P>Хотя бы потому, что lock(this) — зло. Так же как lock(typeof(this)) и любые публично доступные экземпляры.
Это все понятно, не об этом топик.
Можно конечно:

private object _syncObject = new object();


Monitor.Enter(_syncObject)


Это что меняет суть вопроса? Зачем метод AcquireLocks для эксклюзивной блокировки (если она действительно эксклюзивная, как утверждает samius), если эксклюзивную блокировку можно написать как Monitor.Enter(_syncObject)?
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания
http://rsdn.ru/Info/rules.xml
Re[7]: ConcurrentDictionary не дает выгоды в производительности
От: samius Япония http://sams-tricks.blogspot.com
Дата: 22.05.13 13:48
Оценка:
Здравствуйте, igor-booch, Вы писали:

IB>Это что меняет суть вопроса? Зачем метод AcquireLocks для эксклюзивной блокировки (если она действительно эксклюзивная, как утверждает samius), если эксклюзивную блокировку можно написать как Monitor.Enter(_syncObject)?

Она действительно эксклюзивная, даже если вызывается внутри метода AcquireLocks. Читайте документацию Monitor.Enter.
Re[7]: ConcurrentDictionary не дает выгоды в производительности
От: pugv Россия  
Дата: 22.05.13 13:50
Оценка: 1 (1) +1
Здравствуйте, igor-booch, Вы писали:

IB> Зачем метод AcquireLocks для эксклюзивной блокировки (если она действительно эксклюзивная, как утверждает samius), если эксклюзивную блокировку можно написать как Monitor.Enter(_syncObject)?


Так захватить-то нужно те же локи, что используются при частичной блокировке. Просто все.
Re[10]: ConcurrentDictionary не дает выгоды в производительности
От: igor-booch Россия  
Дата: 22.05.13 14:01
Оценка:
S>Расширение BCL для своего алгоритма? Интересно. А что такого может понадобиться от BCL, чего нельзя написать самому?

То что потребуется в алгоритме, но для чего не будет явной реализации в BCL. Это к тому что
S>Сомневаюсь что есть какое-то доказательство для текущего кода из BCL.
Если нет для текущего значит, нужно расширить. А чтобы понять какие расширения нужны, нужен алгоритм.
Хотя действительно вряд ли расширения понадобятся. При реализации словаря ничего такого сложно плохо формализуемого из BCL понадобиться не должно, только базовые структура данных и операции. Вот что может понадобиться, так это разработка математической теории под это дело, или расширение существующих. Но я не уверен, не специалист. Наверняка параллельные алгоритмы должны быть хорошо изучены. Поэтому я и говорю, это сложная научная задача, судя по тому что других сторонних реализаций нет ни одной. Я по крайней мере не встречал.
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания
http://rsdn.ru/Info/rules.xml
Re[8]: ConcurrentDictionary не дает выгоды в производительности
От: igor-booch Россия  
Дата: 22.05.13 14:15
Оценка:
IB>>Это что меняет суть вопроса? Зачем метод AcquireLocks для эксклюзивной блокировки (если она действительно эксклюзивная, как утверждает samius), если эксклюзивную блокировку можно написать как Monitor.Enter(_syncObject)?
S>Она действительно эксклюзивная, даже если вызывается внутри метода AcquireLocks. Читайте документацию Monitor.Enter.

Конечно можно внутри AcquireLocks вызвать Monitor.Enter(_syncObject). Но метод называется AcquireLocks, а не AcquireExclusiveLock. Могу предположить, что в итоге действительно получается некая эксклюзивная блокировка, только не на уровне всего экземпляра класса, а на каком-то другом, более узком уровне для увеличения выгоды от увеличения числа потоков.
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания
http://rsdn.ru/Info/rules.xml
Re[11]: ConcurrentDictionary не дает выгоды в производительности
От: samius Япония http://sams-tricks.blogspot.com
Дата: 22.05.13 14:20
Оценка:
Здравствуйте, igor-booch, Вы писали:

S>>Расширение BCL для своего алгоритма? Интересно. А что такого может понадобиться от BCL, чего нельзя написать самому?


IB>То что потребуется в алгоритме, но для чего не будет явной реализации в BCL. Это к тому что

S>>Сомневаюсь что есть какое-то доказательство для текущего кода из BCL.
IB>Если нет для текущего значит, нужно расширить. А чтобы понять какие расширения нужны, нужен алгоритм.
google-> lockfree hashtable

IB>Поэтому я и говорю, это сложная научная задача, судя по тому что других сторонних реализаций нет ни одной. Я по крайней мере не встречал.

Я думаю что скорее это никому не надо.
Re[9]: ConcurrentDictionary не дает выгоды в производительности
От: samius Япония http://sams-tricks.blogspot.com
Дата: 22.05.13 14:21
Оценка:
Здравствуйте, igor-booch, Вы писали:

S>>Она действительно эксклюзивная, даже если вызывается внутри метода AcquireLocks. Читайте документацию Monitor.Enter.


IB>Конечно можно внутри AcquireLocks вызвать Monitor.Enter(_syncObject). Но метод называется AcquireLocks, а не AcquireExclusiveLock. Могу предположить, что в итоге действительно получается некая эксклюзивная блокировка, только не на уровне всего экземпляра класса, а на каком-то другом, более узком уровне для увеличения выгоды от увеличения числа потоков.


Я вам об этом и написал ранее. Только GrowTable берет действительно эксклюзивную, т.к. передает всегда один и тот же индекс — 0.
Re[8]: ConcurrentDictionary не дает выгоды в производительности
От: igor-booch Россия  
Дата: 22.05.13 14:23
Оценка:
P>Так захватить-то нужно те же локи, что используются при частичной блокировке. Просто все.
Точно! только можно было ReadWriteLock использовать.


private ReadWriteLock _exclusiveReadWriteLock;



Частичные блокировки запрашивают _exclusiveReadWriteLock.AcquireReaderLock, а для в реализации AcquireLocks тогда просто _exclusiveReadWriteLock.AcquireWriterLock
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания
http://rsdn.ru/Info/rules.xml
Re[12]: ConcurrentDictionary не дает выгоды в производительности
От: igor-booch Россия  
Дата: 22.05.13 14:29
Оценка:
S>google-> lockfree hashtable
Ну и где хоть одна реализация для NET?
То что что такие структуры данных не нужны никому сомневаюсь, количество ядер на процах давно перевалило за 1.
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания
http://rsdn.ru/Info/rules.xml
Re[9]: ConcurrentDictionary не дает выгоды в производительности
От: igor-booch Россия  
Дата: 22.05.13 14:31
Оценка:
Хотя с таким подходом будет медленнее чем у них
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания
http://rsdn.ru/Info/rules.xml
Re[13]: ConcurrentDictionary не дает выгоды в производительности
От: samius Япония http://sams-tricks.blogspot.com
Дата: 22.05.13 14:57
Оценка:
Здравствуйте, igor-booch, Вы писали:

S>>google-> lockfree hashtable

IB>Ну и где хоть одна реализация для NET?
Вы спросили про алгоритм, я ответил именно на это.

IB>То что что такие структуры данных не нужны никому сомневаюсь, количество ядер на процах давно перевалило за 1.

Никому из дотнетчиков не нужны настолько что бы писать свою реализацию для дотнета.
Может и написал кто, да не выложил.
Да я и не очень представляю, за счет чего должен быть выигрышь в куче потоков. Там же RMW операции, они долгие по своей природе. В десятки (или более) раз тормознее обычных на кэше.
Re: ConcurrentDictionary не дает выгоды в производительности
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 22.05.13 15:09
Оценка: 6 (1)
Здравствуйте, igor-booch, Вы писали:

Вообще для улучшения производительности, можно Хэш таблицу Разделить например на 1) хэш таблиц. Учитывая что данных будет много.
Тогда Доступ к каждой можно сделать как поз=Хэш % 10. Если хэши хорошо перемешаны вероятность доступа из двух потоков к одной хэш таблицы будет как 1/10, и соответсвенно уменьшится время ожидания на вставку изменения.
и солнце б утром не вставало, когда бы не было меня
Re[10]: ConcurrentDictionary не дает выгоды в производительности
От: igor-booch Россия  
Дата: 23.05.13 09:17
Оценка:
IB>Хотя с таким подходом будет медленнее чем у них

А может и нет, наверное это долго много раз вызывать Monitor.Enter()
Может быстрее будет _exclusiveReadWriteLock.AcquireWriterLock
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания
http://rsdn.ru/Info/rules.xml
Re[3]: ConcurrentDictionary не дает выгоды в производительности
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 23.05.13 09:46
Оценка:
Здравствуйте, igor-booch, Вы писали:

IB>
IB>lock (dictionary)
IB>{
IB>    dictionary.Add(key, value);
IB>}
IB>



IB>и



IB>
IB>concurrentDictionary.TryAdd(key, value);
IB>



IB>Здесь однозначно побеждает СoncurrentDictionary.


Правильно, и это именно то ради чего нужен СoncurrentDictionary.
Re: ConcurrentDictionary не дает выгоды в производительности
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 23.05.13 09:48
Оценка:
Здравствуйте, igor-booch, Вы писали:

IB>Даже на 8 ядерном процессоре Dictionary на одном потоке быстрее, чем ConcurrentDictionary на 8 потоках.


Надо и remove добавить для полноты картины.

Как видно, время Add слабо меняется, а вот время Get меняется заметно. То есть, Get в ConcurrentDictionary работает быстрее !

Теперь сделай ровно тот же тест, но на большом количестве потоков для Dicionary с одновременными операциями add, remove, get — слив гарантирован.
Re[2]: ConcurrentDictionary не дает выгоды в производительности
От: igor-booch Россия  
Дата: 23.05.13 10:36
Оценка:
I>Теперь сделай ровно тот же тест, но на большом количестве потоков для Dicionary

Не для этого тест, я хочу выбрать делать ли мне многопоточный вариант или однопоточный.
Тест показывает, что быстрее будет однопоточный.
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания
http://rsdn.ru/Info/rules.xml
Re[3]: ConcurrentDictionary не дает выгоды в производительности
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 23.05.13 10:39
Оценка:
Здравствуйте, igor-booch, Вы писали:

I>>Теперь сделай ровно тот же тест, но на большом количестве потоков для Dicionary


IB>Не для этого тест, я хочу выбрать делать ли мне многопоточный вариант или однопоточный.

IB>Тест показывает, что быстрее будет однопоточный.

А сценарии у тебя какие ? Итерации не нужны, удаление не нужно ?
Re[4]: ConcurrentDictionary не дает выгоды в производительности
От: igor-booch Россия  
Дата: 23.05.13 10:42
Оценка:
IB>Здесь однозначно побеждает СoncurrentDictionary.
I>Правильно, и это именно то ради чего нужен СoncurrentDictionary.

Я не отрицаю, по Вашему мнению Ваша реплика что-то новое привносит?
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания
http://rsdn.ru/Info/rules.xml
Re[4]: ConcurrentDictionary не дает выгоды в производительности
От: igor-booch Россия  
Дата: 23.05.13 10:45
Оценка:
I>А сценарии у тебя какие ? Итерации не нужны, удаление не нужно ?

Сценарий у меня добавить элементы в словарь за максимально короткое время
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания
http://rsdn.ru/Info/rules.xml
Re[5]: ConcurrentDictionary не дает выгоды в производительности
От: samius Япония http://sams-tricks.blogspot.com
Дата: 23.05.13 11:00
Оценка:
Здравствуйте, igor-booch, Вы писали:

IB>Сценарий у меня добавить элементы в словарь за максимально короткое время

http://www.rsdn.ru/forum/dotnet/5177238.1
Автор: Serginio1
Дата: 22.05.13
Re[2]: ConcurrentDictionary не дает выгоды в производительности
От: igor-booch Россия  
Дата: 23.05.13 11:07
Оценка:
S>Вообще для улучшения производительности, можно Хэш таблицу Разделить например на 1) хэш таблиц. Учитывая что данных будет много.
S>Тогда Доступ к каждой можно сделать как поз=Хэш % 10. Если хэши хорошо перемешаны вероятность доступа из двух потоков к одной хэш таблицы будет как 1/10, и соответсвенно уменьшится время ожидания на вставку изменения.

Если ключ был к примеру int, так можно было бы сделать.
К сожалению этот вариант для меня не подходит так тип ключа мне неизвестен, для меня он object.
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания
http://rsdn.ru/Info/rules.xml
Re[3]: ConcurrentDictionary не дает выгоды в производительности
От: 0x7be СССР  
Дата: 23.05.13 11:17
Оценка: 6 (1)
Здравствуйте, igor-booch, Вы писали:


IB>Если ключ был к примеру int, так можно было бы сделать.

IB>К сожалению этот вариант для меня не подходит так тип ключа мне неизвестен, для меня он object.
Можно применить object.GetHashCode
Re[3]: ConcurrentDictionary не дает выгоды в производительности
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 23.05.13 11:28
Оценка:
Здравствуйте, igor-booch, Вы писали:

S>>Вообще для улучшения производительности, можно Хэш таблицу Разделить например на 1) хэш таблиц. Учитывая что данных будет много.

S>>Тогда Доступ к каждой можно сделать как поз=Хэш % 10. Если хэши хорошо перемешаны вероятность доступа из двух потоков к одной хэш таблицы будет как 1/10, и соответсвенно уменьшится время ожидания на вставку изменения.

IB>Если ключ был к примеру int, так можно было бы сделать.

IB>К сожалению этот вариант для меня не подходит так тип ключа мне неизвестен, для меня он object.
У любого object есть метод GetHashCode любая Хэш таблица использует этот метод для получения Хэш Кода.
Либо всегда можно применить свою функцию Хэширования к ключу.
и солнце б утром не вставало, когда бы не было меня
Re[4]: ConcurrentDictionary не дает выгоды в производительности
От: igor-booch Россия  
Дата: 23.05.13 11:30
Оценка:
0>Можно применить object.GetHashCode
А по каким критериям определить оптимальное количество словарей в этом случае?
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания
http://rsdn.ru/Info/rules.xml
Re[4]: ConcurrentDictionary не дает выгоды в производительности
От: samius Япония http://sams-tricks.blogspot.com
Дата: 23.05.13 11:39
Оценка:
Здравствуйте, 0x7be, Вы писали:

0>Здравствуйте, igor-booch, Вы писали:



IB>>Если ключ был к примеру int, так можно было бы сделать.

IB>>К сожалению этот вариант для меня не подходит так тип ключа мне неизвестен, для меня он object.
0>Можно применить object.GetHashCode
Вообще-то на вход словарю подается IEqualityComparer, его-то и следует использовать.
Re[5]: ConcurrentDictionary не дает выгоды в производительности
От: igor-booch Россия  
Дата: 23.05.13 11:47
Оценка:
S>Вообще-то на вход словарю подается IEqualityComparer, его-то и следует использовать.

Не понимаю как в этом случае реализовать преложенное Serginio1
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания
http://rsdn.ru/Info/rules.xml
Re[5]: ConcurrentDictionary не дает выгоды в производительности
От: igor-booch Россия  
Дата: 23.05.13 11:50
Оценка:
IB>А по каким критериям определить оптимальное количество словарей в этом случае?
Количество словарей наверное = количеству потоков = количеству ядер CPU
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания
http://rsdn.ru/Info/rules.xml
Re[5]: ConcurrentDictionary не дает выгоды в производительности
От: samius Япония http://sams-tricks.blogspot.com
Дата: 23.05.13 12:05
Оценка:
Здравствуйте, igor-booch, Вы писали:

0>>Можно применить object.GetHashCode

IB>А по каким критериям определить оптимальное количество словарей в этом случае?
по критериям, построенным по результатам анализа полученных на практике данных.
Re[6]: ConcurrentDictionary не дает выгоды в производительности
От: samius Япония http://sams-tricks.blogspot.com
Дата: 23.05.13 12:06
Оценка:
Здравствуйте, igor-booch, Вы писали:

S>>Вообще-то на вход словарю подается IEqualityComparer, его-то и следует использовать.


IB>Не понимаю как в этом случае реализовать преложенное Serginio1

А в чем конкретно заключается непонимание?
Re[6]: ConcurrentDictionary не дает выгоды в производительности
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 23.05.13 12:07
Оценка:
Здравствуйте, igor-booch, Вы писали:

IB>>А по каким критериям определить оптимальное количество словарей в этом случае?

IB>Количество словарей наверное = количеству потоков = количеству ядер CPU
Здесь играет роль вероятности. Чем больше массив тем меньше вероятность доступа к одному словарю. Тут много факторов влияет, в том числе и распределение хэш функции. Но лучше всего экспериментальным путем.
Например б+ дерево по сути и является массивом массивов. Там оптимальность длины зависит от вставки и перестроения дерева. Сделай 100 словарей, если к нему будет постоянный доступ. Не ошибешься.
Вернее приведи этот размер к простому числу
и солнце б утром не вставало, когда бы не было меня
Re[4]: ConcurrentDictionary не дает выгоды в производительности
От: igor-booch Россия  
Дата: 23.05.13 12:14
Оценка:
IB>>Если ключ был к примеру int, так можно было бы сделать.
IB>>К сожалению этот вариант для меня не подходит так тип ключа мне неизвестен, для меня он object.
0>Можно применить object.GetHashCode

К сожалению данный вариант тоже не подходит. Но за идею спасибо.
У меня добавление происходит подряд в несколько словарей.
И для каждого разные ключи.
Если применить этот подход,
и каждый словарь разделить на несколько, и в каждый из этих нескольких добавлять в отдельных потоках,
то последовательность может быть нарушена.
Конечно теоретически можно абстрагировать мою логику от последовательности добавления (чтобы добавлять можно было в любом порядке), то тогда логика получится слишком сложной.
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания
http://rsdn.ru/Info/rules.xml
Re[5]: ConcurrentDictionary не дает выгоды в производительности
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 23.05.13 12:24
Оценка: +1
Здравствуйте, igor-booch, Вы писали:

I>>А сценарии у тебя какие ? Итерации не нужны, удаление не нужно ?


IB>Сценарий у меня добавить элементы в словарь за максимально короткое время


Cкажи пожалуйста, почему тебе пришла в голову идея что ConcurrentDictionary решает именно эту проблему или хотя бы может помочь с этой проблемой ? Вроде как слово Concurent говорит совсем о другом.
Re[7]: ConcurrentDictionary не дает выгоды в производительности
От: igor-booch Россия  
Дата: 23.05.13 12:26
Оценка:
IB>>Не понимаю как в этом случае реализовать преложенное Serginio1
S>А в чем конкретно заключается непонимание?

Предположим я решил по совету Serginio1 я решил разделить свой словарь на 10 словарей
Каждый словарь отвечает за определенный диапозон ключей.
Как эти диапазоны определить имея только IEqualityComparer и не зная какого типа будет ключ.
От какого объекта до какого каждый диапозон?
Ситуация усложнится если допустить что ключи могут быть разных типов.
Варианту с GetHashCode в этом случае пофиг.
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания
http://rsdn.ru/Info/rules.xml
Re[8]: ConcurrentDictionary не дает выгоды в производительности
От: samius Япония http://sams-tricks.blogspot.com
Дата: 23.05.13 12:35
Оценка:
Здравствуйте, igor-booch, Вы писали:

IB>>>Не понимаю как в этом случае реализовать преложенное Serginio1

S>>А в чем конкретно заключается непонимание?

IB>Предположим я решил по совету Serginio1 я решил разделить свой словарь на 10 словарей

IB>Каждый словарь отвечает за определенный диапозон ключей.
Serginio1 писал не о диапазоне, а об операции нахождения остатка от деления на число словарей хэшкода ключа.

IB>Ситуация усложнится если допустить что ключи могут быть разных типов.

IB>Варианту с GetHashCode в этом случае пофиг.
EqualityComparer<Object>.Default будет делегировать именно object.GetHashCode()-у если ссылка не нулевая.
Re[6]: ConcurrentDictionary не дает выгоды в производительности
От: igor-booch Россия  
Дата: 23.05.13 12:47
Оценка: -1
I>Cкажи пожалуйста, почему тебе пришла в голову идея что ConcurrentDictionary решает именно эту проблему или хотя бы может помочь с этой проблемой ? Вроде как слово Concurent говорит совсем о другом.

Concurent — способный работать в условиях многопоточности, потокобезопасный. Одно из предназначений многопоточности это для того чтобы множество операций можно было разделить на несколько подмножеств и выполнять операции из этих подмножеств параллельно, то есть в условиях многопоточности.
Понятно что потокобезопасность не означает что код будет работать быстрее на нескольких потоках.
Это скорее значит что код не отвалится на нескольких потоках.
Так как можно на все операции повесить эксклюзивную блокировку на весь объект (или вообще на тип объекта) и код станет потокобезовасным,
но при обращении к коду из нескольких потоков все опрациии будут работать последовательно, как будто отращаются из одного потока.
Чтобы сделать код быстрее на нескольких потоках необходимо использовать более гранулярные блокировки, чем эксклюзивную блокировку на объект.
Если посмотреть сорцы ConcurrentDictionary такая попытка делается (см. обсуждения выше: http://rsdn.ru/forum/dotnet/5176846.1
Автор: samius
Дата: 22.05.13
).
Но судя по результатам теста не совсем удачная попытка, ну или удачная но хотелось бы чтобы она была поудачнее.
Если они хотели добиться только потокобезопасности, без увеличения производительности на нескольких потоках, то назвали бы тогда честно
ThreadSafeDictionary.
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания
http://rsdn.ru/Info/rules.xml
Re[9]: ConcurrentDictionary не дает выгоды в производительности
От: igor-booch Россия  
Дата: 23.05.13 13:30
Оценка:
S>EqualityComparer<Object>.Default будет делегировать именно object.GetHashCode()-у если ссылка не нулевая.
Я наверное Вас не понимаю, но этим постом
http://rsdn.ru/forum/dotnet/5178359.1
Автор: samius
Дата: 23.05.13

Вы предложили альтернативу GetHashCode.

S>Serginio1 писал не о диапазоне, а об операции нахождения остатка от деления на число словарей хэшкода ключа.

По моему мнению алгоритм может быть в 2-х вариантах:

Создаем 10 словарей
Каждый словарь отвечает за определенный диапазон целочиленных значений ключей (или хэш кодов ключей, если мы не знаем тип ключей)
Предположим нужно добавить элемент по ключу K
Тогда
1) мы ищем в какой диапазон попадает K, если К целочисленное
или в какой диапозон попадает K.GetHashCode(), если мы не знаем тип K
2) И делаем вставку в соответсвующей словарь с блокировкой на него

Но этого варианта есть недостаток: нет разброса ключей (хэш кодов ключей) по словарям.

Serginio1 изначально предложил более эффективный вариант (я это сразу не заметил)
Создаем изначально просто 10 словарей без всяких диапозонов
Предположим нужно добавить элемент по ключу K
1) делаем K % 10 и получаем номер словаря, если К целочисленное
или K.GetHashCode() % 10, если тип K неизвестен
2) И делаем вставку в этот словарь с блокировкой на него

Этот вариант избавляет от необходимости определения диапозонов и одновременно обеспечивает разброс ключей (хэш кодов ключей) по словарям.

Вы писали следующее:
0>>Можно применить object.GetHashCode
S>Вообще-то на вход словарю подается IEqualityComparer, его-то и следует использовать.
Как использовать в этих алгоритмах IEqualityComparer переданный на вход словарю непонятно.
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания
http://rsdn.ru/Info/rules.xml
Re[7]: ConcurrentDictionary не дает выгоды в производительности
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 23.05.13 13:41
Оценка:
Здравствуйте, igor-booch, Вы писали:


IB>Если они хотели добиться только потокобезопасности, без увеличения производительности на нескольких потоках, то назвали бы тогда честно

IB>ThreadSafeDictionary.

ConcurrentDictionary<TKey, TValue> — класс




Кстати внутри Это Хэш таблица использующая GetHashCode. Внутри при добавлении используется Monitor.Enter но на конкретную запись, используется Volaitile.Read, TryUdate
Идет сравнение на текущую таблицу. То есть скрость записи изменения из разных потоков должна увеличиться по сравнению с потокобезопасной/
Применение массива ConcurrentDictionary может дать пользу при реструктуризации.
и солнце б утром не вставало, когда бы не было меня
Re[10]: ConcurrentDictionary не дает выгоды в производительности
От: samius Япония http://sams-tricks.blogspot.com
Дата: 23.05.13 13:56
Оценка: 67 (2)
Здравствуйте, igor-booch, Вы писали:

IB>http://rsdn.ru/forum/dotnet/5178359.1
Автор: samius
Дата: 23.05.13

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

S>>Serginio1 писал не о диапазоне, а об операции нахождения остатка от деления на число словарей хэшкода ключа.

IB>По моему мнению алгоритм может быть в 2-х вариантах:

IB>Создаем 10 словарей

IB>Каждый словарь отвечает за определенный диапазон целочиленных значений ключей (или хэш кодов ключей, если мы не знаем тип ключей)
Можно, но надо еще эффективно решать задачу поиска диапазона.
IB>Но этого варианта есть недостаток: нет разброса ключей (хэш кодов ключей) по словарям.
Да, и этот

IB>Serginio1 изначально предложил более эффективный вариант (я это сразу не заметил)

IB>1) делаем K % 10 и получаем номер словаря, если К целочисленное
IB>или K.GetHashCode() % 10, если тип K неизвестен
Мне кажется что именно это предложил Serginio1.

IB>Этот вариант избавляет от необходимости определения диапозонов и одновременно обеспечивает разброс ключей (хэш кодов ключей) по словарям.

Разброс обеспечивает функция GetHashCode и только она.

IB>Вы писали следующее:

0>>>Можно применить object.GetHashCode
S>>Вообще-то на вход словарю подается IEqualityComparer, его-то и следует использовать.
IB>Как использовать в этих алгоритмах IEqualityComparer переданный на вход словарю непонятно.
Вызывать IEqualityComparer.GetHashCode, а как еще?

Уточню. Object.GetHashCode() — глупая функция, прикрученная к объекту. Предполагается что именно объект должен указывать функцию получения своего хэшкода на все случаи жизни. Глупость такого подхода заключается в том, что в общем случае такой одной эффективной функции на все случаи жизни может не существовать. В различных условиях нам следует указывать рализчные функции для вычисления кэшкода. Словари в конструкторе принимают IEqualityComparer, который как раз достаточно гибок что бы для разных ситуаций использовать разные реализации. И частный случай IEqualityComparer- ObjectEqualityComparer — это такой IEqualityComparer, который делегирует вызов на Object.GetHashCode.
Реализуя собственный словарь вы не должны избегать принятых соглашений. Можете, конечно, но если вдруг вы будете хэшкод вычислять одним способом, а словари другим — возможно получите не самую эффективную реализацию в лучшем случае и самую неэфективную в худшем, когда Object.GetHashCode возвращает константу. Случаи когда GetHashCode реализован неверно я не рассматриваю.
Re[8]: ConcurrentDictionary не дает выгоды в производительности
От: igor-booch Россия  
Дата: 23.05.13 14:08
Оценка:
S> Кстати внутри Это Хэш таблица использующая GetHashCode. Внутри при добавлении используется Monitor.Enter но на конкретную запись, используется Volaitile.Read, TryUdate
S>Идет сравнение на текущую таблицу. То есть скрость записи изменения из разных потоков должна увеличиться по сравнению с потокобезопасной/
Она увеличивается но к сожалению не настолько чтобы обогнать даже на 8 потоках на 8-ми ядерном проце
обычный Dictionary на одном потоке. Я ожидал большего от ConcurrentDictonary. Об этом пост.
Чтобы ConcurentDictonary обгонял на множестве потоков нужно в нем увеличивать гранулярность блокировок (умельчать блокировки). Интересно это хотя бы теоретически возможно? Или MS достигла предел гранулярности блокировок в ConcurrentDictonary?

S>Применение массива ConcurrentDictionary может дать пользу при реструктуризации.

Под реструктуризацией Вы понимаете что сначала если код вызывающий ConcurrentDictionary был однопоточным, а потом стал многопоточным? Типа ConcurrentDictionary абстрагирован от поточности?

IB>>Если они хотели добиться только потокобезопасности, без увеличения производительности на нескольких потоках, то назвали бы тогда честно

IB>>ThreadSafeDictionary.
S> ConcurrentDictionary<TKey, TValue> — класс
Не понял, Вы хотите сказать что класс не моет быть ThreadSafe?
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания
http://rsdn.ru/Info/rules.xml
Re[9]: ConcurrentDictionary не дает выгоды в производительности
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 23.05.13 14:20
Оценка:
Здравствуйте, igor-booch, Вы писали:


S>>Применение массива ConcurrentDictionary может дать пользу при реструктуризации.

IB>Под реструктуризацией Вы понимаете что сначала если код вызывающий ConcurrentDictionary был однопоточным, а потом стал многопоточным? Типа ConcurrentDictionary абстрагирован от поточности?
Внутри ConcurrentDictionary массив структур Кей Валуе который при заполнение создается новый массив в 2 раза бошльше и в него копируются текущие значения
IB>>>Если они хотели добиться только потокобезопасности, без увеличения производительности на нескольких потоках, то назвали бы тогда честно
IB>>>ThreadSafeDictionary.
S>> ConcurrentDictionary<TKey, TValue> — класс
IB>Не понял, Вы хотите сказать что класс не моет быть ThreadSafe?
Я хочу сказать, что он ThreadSafe и с конкуренцией на конкретную запись. Но вот тут есть может быть проблема в том, что дополнительный обслуживающий код сам может тормозить.
Можно выяснить это так создать массив с размером простым числом например 101 для того что бы не было затрат на GetHashCode сделать код интовым и посмотреть на скорость выполнения для обыкновенных Хэш Таблиц с блокровками на запись, можно использовать SpinLock. И предусмотреть TryUpdate
и солнце б утром не вставало, когда бы не было меня
Re[6]: ConcurrentDictionary не дает выгоды в производительности
От: igor-booch Россия  
Дата: 24.05.13 07:13
Оценка:
I>Cкажи пожалуйста, почему тебе пришла в голову идея что ConcurrentDictionary решает именно эту проблему или хотя бы может помочь с этой проблемой ? Вроде как слово Concurent говорит совсем о другом.

Дополнение к
http://rsdn.ru/forum/dotnet/5178474.1
Автор: igor-booch
Дата: 23.05.13


О чем по Вашему говорит Concurent?
Интересна также причина Вашей оценки к посту. По-моему остроумие не основная его часть.
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания
http://rsdn.ru/Info/rules.xml
Re[7]: ConcurrentDictionary не дает выгоды в производительности
От: drol  
Дата: 24.05.13 11:54
Оценка: 6 (1)
Здравствуйте, igor-booch, Вы писали:

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


У Вас каша в голове. Concurrency, parallelism, многопоточность — это "четыре разных человека".

IB> то назвали бы тогда честно ThreadSafeDictionary.


Употребление термина concurrent в названии обсуждаемого типа вполне адекватно. Подробности же контракта определяются не названием, а документацией, с которой всё в порядке.
Re[8]: Товарищам смеющимся и минусующим: псевдопараллеризм
От: igor-booch Россия  
Дата: 24.05.13 13:22
Оценка:
D>У Вас каша в голове. Concurrency, parallelism, многопоточность — это "четыре разных человека".

Concurent Resourse — это значит обеспечен конкурентный доступ к Resourse
Parralel Tasks - это когда каждая из множества задач Tasks выполняется одновременно (параллельно)

Ключевое отличие Concurent от Parralel это
1) Parralel — это сотрудничество, Concurent — это конкуренция
2) Concurent — относится к ресурсу, Parralel — к задаче

А теперь рассмотрим как реализуется Parallelism, есть 2 варианта.
Предположим каждая из Task, выполняющаяся параллельно, это функция и на выходе дает некоторые данные — результаты.
Нас конечно интересует объединение результатов со всех Tasks , то есть некий общий результат
1) После того все Tasks закончатся их результаты сливаются в один результат
Это предпочтительный вариант, но не всегда возможен, так как

1.1)в процессе выполнения каждая из Tasks может захотеть увидеть промежуточные результаты выполнения другой Task
1.2)мы получаем общий результат только когда все Tasks выполнятся, а может возникнуть необходимость видеть промежуточный общий результат, то есть сколько успели таски сделать столько и видим в каждый момент времени (системы реального времени)

Поэтому на сцену выходит второй вариант реализации Parallelism
2)Объединение промежуточных результатов каждой Task происходит непрерывно во время их выполнения. То есть получила Task промежуточный результат, сразу этот результат объединяется с общим результатом
Это можно назвать частичным или псевдопараллеризмом.
Так вот, во втором варианте этот общим результатом — это и есть некий ресурс, к которому обеспечивается конкурентный доступ.



То есть псевдопараллеризм реализуется через конкурентный доступ.



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

Вы меня склоняете думать только в категориях крайних случаев параллелизма и конкурентного доступа. Крайние случаи важны для теории. А на практике могут быть промежуточные случаи (псевдопараллеризм). И надеюсь что это не каша у меня в голове, как показалось Вам и возможно остальным смеющимся. (Я не уверен по поводу смеющих, возможно у них свои причины, они мне тоже интересны)
Аналогичная ситуация например с CAP теоремой http://rsdn.ru/forum/design/5155590.1
Автор: igor-booch
Дата: 30.04.13


Как бы Вы назвали словарь предназначенный для конкурентного доступа для псевдопараллельно выполняющихся задач? CuncurrentDictionaryForPseudoparralelTasks?
Допустим, что так, только тогда знакомый Вам ConcurrentDictionary и CuncurrentDictionaryForPseudoParralelTasks будут отличаться только гранулирностью блокировок во внутренней реализации. Публичный интерфейс будет одинаковый. И зачем будет иметь два словаря отличающихся только тем что один хуже другой лучше (я полагаю что чем выше гранулярность (мелкота) блокировок тем лучше)? Так что не стоит воспринимать слово Cuncurrent так однозначно и теоретизированно.
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания
http://rsdn.ru/Info/rules.xml
Re[9]: Товарищам смеющимся и минусующим: псевдопараллеризм
От: igor-booch Россия  
Дата: 24.05.13 14:48
Оценка:
Небольшое дополнение,
задачи для выполнения которых не требуются промежуточные результаты выполнения других задач грубо говоря в терминах функционального программирования называются чистыми функциями. Я ФЯП программирования допускающие только чистые функции называются чистыми (pure). То есть каждая функция полностью изолированна от остальных. Грязные функции обмениваются своими результатами через изменения глобального состояния (контекста выполнения, общие ресурсы). То есть грязная функция знает что выполняется в некотором контексте. В чистом ФЯП понятия контекста выполнения (и потока выполнения) вообще не существует. За счет этого в чистых ФЯП возможно автоматическое распараллерирование. А если вы используете грязные функции императивного языка программирования, извольте при распараллерировании обеспечить эффективный конкурентный доступ к общим ресурсам. Но это уже получится псевдопараллериризм.
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания
http://rsdn.ru/Info/rules.xml
Re[9]: Товарищам смеющимся и минусующим: псевдопараллеризм
От: drol  
Дата: 24.05.13 15:41
Оценка: +2
Здравствуйте, igor-booch, Вы писали:

IB>Concurent Resourse — это значит обеспечен конкурентный доступ к Resourse

IB>Parralel Tasks - это когда каждая из множества задач Tasks выполняется одновременно (параллельно)

Вот именно это я и называю "каша в голове". Вы придумали какую-то собственную личную терминологию и пытаетесь её выдать за общепринятую. Зачем ?

IB>(системы реального времени)


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

IB>Публичный интерфейс будет одинаковый.


Ещё смешней. "Публичный интерфейс", как Вы выражаетесь, это всего лишь одна маленькая часть контракта. Сложность, ограничения на входные\выходные параметры и прочие характеристики такого толка находятся не в сигнатурах методов, а прежде всего в документации. Зачем Вы пытаетесь делать какие-то псевдоглубокомысленные выводы из одного только названия типа — совершенно непонятно.
Re[10]: Товарищам смеющимся и минусующим: псевдопараллеризм
От: samius Япония http://sams-tricks.blogspot.com
Дата: 24.05.13 16:21
Оценка:
Здравствуйте, igor-booch, Вы писали:

IB>Небольшое дополнение,

IB>задачи для выполнения которых не требуются промежуточные результаты выполнения других задач грубо говоря в терминах функционального программирования называются чистыми функциями.
Чистой функцией называют функцию с детерминированным результатом и без побочных эффектов. Что такое промеждуточный результат выполнения другой задачи — не очень понятно в данном аспекте.
IB>Я ФЯП программирования допускающие только чистые функции называются чистыми (pure). То есть каждая функция полностью изолированна от остальных.
Это как это изолирована?
IB>Грязные функции обмениваются своими результатами через изменения глобального состояния (контекста выполнения, общие ресурсы).
Нет, грязная функция — это функция, которая не попадает под определение чистой. А обменивается она или просто меняет окружение — дело десятое.
IB>То есть грязная функция знает что выполняется в некотором контексте.
Все выполняется в некотором контексте
IB>В чистом ФЯП понятия контекста выполнения (и потока выполнения) вообще не существует.
Это определенно новость.
IB>За счет этого в чистых ФЯП возможно автоматическое распараллерирование.
Нет, не поэтому. А потому что (и ровно до тех пор пока) менять ничего нельзя. Но как только появляется изменяемый ресурс, так сразу кончается возможность автоматического распараллеливания. Да, и в чистых языках возможна работа с изменяемыми штуками. Например, в хаскелле считается что такой ресурс находится во внешнем мире по отношению к программе.
IB>А если вы используете грязные функции императивного языка программирования, извольте при распараллерировании обеспечить эффективный конкурентный доступ к общим ресурсам. Но это уже получится псевдопараллериризм.
Устойчивое значение термина "псевдопараллелизм" — выполнение параллельных задач на одном ядре.
Re[11]: Товарищам смеющимся и минусующим: псевдопараллеризм
От: igor-booch Россия  
Дата: 25.05.13 09:24
Оценка:
S>Чистой функцией называют функцию с детерминированным результатом и без побочных эффектов. Что такое промеждуточный результат выполнения другой задачи — не очень понятно в данном аспекте.
А что технически означает "без побочных эффектов". Это значит функция не может менять не одну переменную, которую может менять какая-либо другая функция. Эту переменную я называю по-разному в предыдущих постах: контекстом выполнения, глобальным состоянием, общим ресурсом, общедоступной переменной, внешней переменной, переменной с конкурентным доступом. А для чего может служить эта переменная? Если функции это псевдопараллельно выполняющаяся задача, то в неё складывается промежуточный результат этой задачи, а сама переменная это общий результат всех псевдопараллельно выполняющихся задач.

It has no side effects. The function does not change any variables or the data of any type outside of the function.

http://msdn.microsoft.com/en-us/library/bb669139.aspx

S>Это как это изолирована?

Я употребил это как синоним чистоты функции.

IB>>Грязные функции обмениваются своими результатами через изменения глобального состояния (контекста выполнения, общие ресурсы).

S>Нет, грязная функция — это функция, которая не попадает под определение чистой. А обменивается она или просто меняет окружение — дело десятое.
Так что технически означает грязная функция?

IB>>То есть грязная функция знает что выполняется в некотором контексте.

S>Все выполняется в некотором контексте
Смотря что считать контекстом.
Если общедоступную переренную, то чистые функции не выполняются в контексте.
Если стек вызова, то есть какая функция вызвала данную функцию, то, да и чистые и грязные функции выполняются в контексте. Но не чистые не грязные не имеют доступа к такому контексту на прямую. Грязные функции имеют доступ к таком контексту косвенно через глобальное состояние.

IB>>В чистом ФЯП понятия контекста выполнения (и потока выполнения) вообще не существует.

S>Это определенно новость.
Уточню не существует потока выполнения, таким как он понимается в императивном программировании. В ФЯП нет условных и безусловных переходов, нет циклов. Есть только полседовательность вызова одних функций другими, но для отдельно взятой функции эта последовательность не важна, так как нет глобального состояния.
http://msdn.microsoft.com/en-us/library/bb669144.aspx

IB>>За счет этого в чистых ФЯП возможно автоматическое распараллерирование.

S>Нет, не поэтому. А потому что (и ровно до тех пор пока) менять ничего нельзя.
Я об этом и написал. Для чистой функции доступны только аргументы переданные ей. Эти аргументы она не меняет. Она может только передать их другой функции. А переменных вне чистой функции (внешних переменных) не существует. Больше менять нечего.

S>Устойчивое значение термина "псевдопараллелизм" — выполнение параллельных задач на одном ядре.

Это Вы путаете с гиперпоточностью (HyperThreading). Гиперпоточность это аппаратная технология, а псевдопараллеризм это программное понятие.
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания
http://rsdn.ru/Info/rules.xml
Re[10]: Товарищам смеющимся и минусующим: псевдопараллеризм
От: igor-booch Россия  
Дата: 25.05.13 09:39
Оценка:
IB>>Публичный интерфейс будет одинаковый.
D>Ещё смешней. "Публичный интерфейс", как Вы выражаетесь, это всего лишь одна маленькая часть контракта. Сложность, ограничения на входные\выходные параметры и прочие характеристики такого толка находятся не в сигнатурах методов, а прежде всего в документации. Зачем Вы пытаетесь делать какие-то псевдоглубокомысленные выводы из одного только названия типа — совершенно непонятно.

По поводу контракта согласен, ну и что из этого? Вы хотите сказать что будет две реализации словаря с конкурентным доступом, с одинаковым публичным интерфейсом, но разной документацией? А что в документации написано:

Represents a thread-safe collection of key/value pairs that can be accessed by multiple threads concurrently.


Очень хорошо согласуется с названием типа. Код должен быть самодокументируемым. Если MS увеличит гранулярность (умельчит) блокировок в ConcurrentDictionary в следующих версиях NET framework, для того чтобы сделать конкурентный доступ к нему более эффективным в условиях многопоточности, название вполне справедливо может остаться тем же.
thread-safe в цитате выше употребляется как синоним concurrent. Я уже писал
Автор: igor-booch
Дата: 23.05.13
что thread-safe не означает эффективный concurrent. Поэтому скорей всего MS сделала задел на будущее: повышение эффективности конкурентного доступа, а не просто thread-safe. Просто по результатам моего теста этому светлому будущему еще суждено наступить.
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания
http://rsdn.ru/Info/rules.xml
Re[9]: Товарищам смеющимся и минусующим: псевдопараллеризм
От: igor-booch Россия  
Дата: 25.05.13 09:56
Оценка: :))
Еще одно оффтопное дополнение:
Конкуренция и сотрудничество идут рука об руку не только в программировании, но в экономике (и вообще везде). При капитализме каждый субъект экономической деятельности (Task) стремится захватить под свою экслюзивную блокировку как можно больше ресурсов (частная собственность). То есть гранулярность блокировок низкая (они стремятся к укрупнению). Это приводит к снижению степени параллелизма, но зато надежно. Меньше вероятность нарушения целостности ресурсов и deadlock. Иными словами легче построить такую систему государственного управления (читай написать программу) при которой нурушение целостности ресурсов и deadlock маловероятен.
Другой крайностью является коммунизм. Тут все ресурсы общие. Гранулярноть блокоровок есть, но она низкая. Это по идее должно увеличить степень параллеризма. Но на практике очень сложно построить систему государственного управления (читай написать программу), при которой можно исключить нарушение целостности ресурсов и dead locks при высокой гранулярности блокирок. Но с развитием технологий и техническим прогрессом построение такой систему облегчиться. Поэтому коммунизм победит! К такому выводу приходил К. Маркс. А Ленин решил можно резко увеличить гранулярность блокировок, что равносильно глубокому необдуманному рефакторингу перед релизом.
Я надеялся что ConcurrentDictionary получится использовать при коммунизме, но MS, конечно выпустила более капиталистическую версию, чем я предполагал.
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания
http://rsdn.ru/Info/rules.xml
Re[12]: Товарищам смеющимся и минусующим: псевдопараллеризм
От: igor-booch Россия  
Дата: 25.05.13 10:04
Оценка:
В дополнение к гиперпоточности.
Одно логическое ядро CPU может конкурентно использоваться нескольким потоками за счет Context Switch.
За счет гиперпоточности одно физическое ядро CPU может быть разбито на несколько логических ядер CPU.
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания
http://rsdn.ru/Info/rules.xml
Re[12]: Товарищам смеющимся и минусующим: псевдопараллеризм
От: igor-booch Россия  
Дата: 25.05.13 13:11
Оценка:
S>Чистой функцией называют функцию с детерминированным результатом и без побочных эффектов. Что такое промеждуточный результат выполнения другой задачи — не очень понятно в данном аспекте.
А что такое детерминированный результат? Это когда функция в любой момент времени при одних и тех же аргументах возвращает одинаковые результаты. А как же она может возвращать разные результаты если аргументы одинаковы. Единственный вариант функция зависит от чего то еще кроме своих аргументом. Это что-то еще является внешним контекстом (внешней переменной), которая может принимать различные значения в различные периоды времени. Можно сказать что отсутствие побочных эффектов это отсутствие записи во внешний контекст. А детерминированность это отсутствие чтения из внешнего контекста. Одним словом можно сказать — независимость от внешнего контекста.
Грязная функция зависит от внешнего контекста, но если этот контекст не меняется при условиях С, то можно сказать что грязная функция детерминирована при условиях С.
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания
http://rsdn.ru/Info/rules.xml
Re[10]: Товарищам смеющимся и минусующим: псевдопараллеризм
От: igor-booch Россия  
Дата: 25.05.13 13:29
Оценка:
Дополнение.
Из предыдущего сообщения может создастся впечатление что конкуренция и сотрудничество враги (техническое противоречие). Примерить конкуренцию и сотрудничество попытался американский математик Джон Нэш

Нэш сумел разглядеть новое лицо конкуренции, смоделировав ситуацию, впоследствии получившую название «равновесие по Нэшу» или «некооперативное равновесие», при которой обе стороны используют идеальную стратегию, что и приводит к созданию устойчивого равновесия


Всем советую посмотреть фильм по Джона Нэша: Игры разума (A Beautiful Mind)

Опечатка во втором абзаце про коммунизм в предыдущем сообщении
Автор: igor-booch
Дата: 25.05.13
:
написано:
Гранулярноть блокоровок есть, но она низкая.
Надо:
Гранулярноть блокировок есть, но она высокая.
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания
http://rsdn.ru/Info/rules.xml
Re[12]: Товарищам смеющимся и минусующим: псевдопараллеризм
От: samius Япония http://sams-tricks.blogspot.com
Дата: 25.05.13 17:24
Оценка:
Здравствуйте, igor-booch, Вы писали:

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

IB>А что технически означает "без побочных эффектов". Это значит функция не может менять не одну переменную, которую может менять какая-либо другая функция. Эту переменную я называю по-разному в предыдущих постах: контекстом выполнения, глобальным состоянием, общим ресурсом, общедоступной переменной, внешней переменной, переменной с конкурентным доступом.
Вот то что вы называете что-то разными терминами и путает вас. Стек — это тоже контекст. Куча — и контекст и общедоступный ресурс, да еще и с конкурентным доступом. И все выполняется в этом контексте и чистые функции не исключение совершенно. Определяйте используемые термины жестче, иначе непонятно, что вы подразумеваете. А переменная, которую не может менять какая-либо другая функция — это не определение.
IB>А для чего может служить эта переменная? Если функции это псевдопараллельно выполняющаяся задача, то в неё складывается промежуточный результат этой задачи, а сама переменная это общий результат всех псевдопараллельно выполняющихся задач.
Еще раз. Вы неверно используете термин псевдопараллельность.
в случае f = sin(x*x), значение, полученное в качестве результата x*x — есть как раз промежуточный результат, который складывается на стек для вызова sin. Понятно на что я намекаю? В ваших терминах f — грязная функция, да еще и псевдопараллельно выполняющаяся задача.

IB>

IB>It has no side effects. The function does not change any variables or the data of any type outside of the function.

IB>http://msdn.microsoft.com/en-us/library/bb669139.aspx
Если это тянет на определение, то оно не полное и неточное.

S>>Это как это изолирована?

IB>Я употребил это как синоним чистоты функции.
Зачем? Очень неочевидный синоним.

IB>>>Грязные функции обмениваются своими результатами через изменения глобального состояния (контекста выполнения, общие ресурсы).

S>>Нет, грязная функция — это функция, которая не попадает под определение чистой. А обменивается она или просто меняет окружение — дело десятое.
IB>Так что технически означает грязная функция?
выделил

IB>>>То есть грязная функция знает что выполняется в некотором контексте.

S>>Все выполняется в некотором контексте
IB>Смотря что считать контекстом.
Вот!

IB>Если общедоступную переренную, то чистые функции не выполняются в контексте.

Почему? Раз переменная общедоступна, то она доступна любой функции, и чистой тоже. И чистые функции даже могут переменную читать и использовать полученное значение для вычисления результата с единственным ограничеием — результат не должен зависеть от того значения. А что может зависеть? Например, метод получения результата.
IB>Если стек вызова, то есть какая функция вызвала данную функцию, то, да и чистые и грязные функции выполняются в контексте. Но не чистые не грязные не имеют доступа к такому контексту на прямую.
Это откуда следует?
IB>Грязные функции имеют доступ к таком контексту косвенно через глобальное состояние.

IB>>>В чистом ФЯП понятия контекста выполнения (и потока выполнения) вообще не существует.

S>>Это определенно новость.
IB>Уточню не существует потока выполнения, таким как он понимается в императивном программировании. В ФЯП нет условных и безусловных переходов, нет циклов. Есть только полседовательность вызова одних функций другими, но для отдельно взятой функции эта последовательность не важна, так как нет глобального состояния.
IB>http://msdn.microsoft.com/en-us/library/bb669144.aspx
Вот откройте свою ссылку и разглядите там в табличке что в ФП внезапно есть control flow, которые и есть порядок выполнения. И он одинакого нужен и ИП и ФП. Да, GOTO в ФП обычно не держат, но прямой заменитель как правило имеется — if-then-else. Вместо циклов — рекурсия. И композиция определяет порядок вызовов функций.

IB>>>За счет этого в чистых ФЯП возможно автоматическое распараллерирование.

S>>Нет, не поэтому. А потому что (и ровно до тех пор пока) менять ничего нельзя.
IB>Я об этом и написал. Для чистой функции доступны только аргументы переданные ей. Эти аргументы она не меняет. Она может только передать их другой функции. А переменных вне чистой функции (внешних переменных) не существует. Больше менять нечего.
Когда вы об этом писали, вы ссылались на некий контекст, который не определили. А теперь я вам показал как чистая функция может взаимодействовать с контекстом (например с глобальной переменной), оставаясь формально чистой.

S>>Устойчивое значение термина "псевдопараллелизм" — выполнение параллельных задач на одном ядре.

IB>Это Вы путаете с гиперпоточностью (HyperThreading). Гиперпоточность это аппаратная технология, а псевдопараллеризм это программное понятие.
Это вы меня хотите запутать, но не выйдет.
http://books.google.ru/books?id=LMg_ZL7CLAAC&amp;lpg=PA39&amp;ots=KDX17gnP81&amp;dq=pseudo%20parallelism&amp;pg=PA38#v=onepage&amp;q=pseudo%20parallelism&amp;f=false
Сравните год издания книги и год выпуска первых HT от Intel.
Я без труда нагуглил еще несколько упоминаний термина pseudo-paralleLism в такой же трактовке. В вашей трактовке (про складывание куда-то промежуточных результатов) — не встретил ни разу.
Re[13]: Товарищам смеющимся и минусующим: псевдопараллеризм
От: samius Япония http://sams-tricks.blogspot.com
Дата: 25.05.13 17:30
Оценка:
Здравствуйте, igor-booch, Вы писали:

IB>В дополнение к гиперпоточности.

IB>Одно логическое ядро CPU может конкурентно использоваться нескольким потоками за счет Context Switch.
IB>За счет гиперпоточности одно физическое ядро CPU может быть разбито на несколько логических ядер CPU.
Вот псевдопараллелизм — как раз выполнение нескольких задач на одном логическом ядре параллельно за счет переключений. То есть при том что логически задачи выглядят выполняющимися параллельно, физически в каждый момент времени выполняется лишь одна задача.
А HT — дает логические ядра и существуют моменты времени, в которые выполняется более одной задачи на одном физическом ядре (но логически на разных).
Re[14]: Товарищам смеющимся и минусующим: псевдопараллеризм
От: igor-booch Россия  
Дата: 26.05.13 09:59
Оценка:
IB>>Одно логическое ядро CPU может конкурентно использоваться нескольким потоками за счет Context Switch.
IB>>За счет гиперпоточности одно физическое ядро CPU может быть разбито на несколько логических ядер CPU.
S>Вот псевдопараллелизм — как раз выполнение нескольких задач на одном логическом ядре параллельно за счет переключений. То есть при том что логически задачи выглядят выполняющимися параллельно, физически в каждый момент времени выполняется лишь одна задача.

Совершенно верно. Общедоступным ресурсом может быть не только общедоступная переменная, но и логическое ядро CPU. Подумайте о CPU как об общедоступном ресурсе для псевдопараллельно выполняющихся задач и Вы получите определение псевдопарралеризма, как его понимает Вы, но не противоречащее моему определению: псевдопараллельно выполняющиеся задачи конкурируют за доступ к общедоступному ресурсу: это если абстрагироваться от того, чем является общедоступный ресурс. Если общедоступным ресурсом считать логическое ядро CPU это 1-ый частный случай. Если общедоступным ресурсом считать общедоступную переменную это 2-ой частный случай. И то что Вы нагуглили в этом
Автор: samius
Дата: 25.05.13
сообщении является 1-ым частным случаем псевдопараллеризма.
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания
http://rsdn.ru/Info/rules.xml
Re[15]: Товарищам смеющимся и минусующим: псевдопараллеризм
От: samius Япония http://sams-tricks.blogspot.com
Дата: 26.05.13 11:39
Оценка:
Здравствуйте, igor-booch, Вы писали:

IB>>>Одно логическое ядро CPU может конкурентно использоваться нескольким потоками за счет Context Switch.

IB>>>За счет гиперпоточности одно физическое ядро CPU может быть разбито на несколько логических ядер CPU.
S>>Вот псевдопараллелизм — как раз выполнение нескольких задач на одном логическом ядре параллельно за счет переключений. То есть при том что логически задачи выглядят выполняющимися параллельно, физически в каждый момент времени выполняется лишь одна задача.

IB>Совершенно верно. Общедоступным ресурсом может быть не только общедоступная переменная, но и логическое ядро CPU. Подумайте о CPU как об общедоступном ресурсе для псевдопараллельно выполняющихся задач и Вы получите определение псевдопарралеризма, как его понимает Вы, но не противоречащее моему определению: псевдопараллельно выполняющиеся задачи конкурируют за доступ к общедоступному ресурсу: это если абстрагироваться от того, чем является общедоступный ресурс. Если общедоступным ресурсом считать логическое ядро CPU это 1-ый частный случай. Если общедоступным ресурсом считать общедоступную переменную это 2-ой частный случай. И то что Вы нагуглили в этом
Автор: samius
Дата: 25.05.13
сообщении является 1-ым частным случаем псевдопараллеризма.

Я не собираюсь рассматривать всерьез вашу трактовку так как 1) вы не можете или не хотите указать источник, 2) — вы выдумываете ее по ходу обсуждения. На это указывает попытка приписать мне путаницу с гипертредингом.

С формулировкой про ядра — там все однозначно. С формулировкой про ресурсы в виде переменных — полный хаос.
Видите ли, если за доступ к переменной или Dictionary нужно конкурировать, то в случае ConcurrentDictionary — все зависит от случая. Выполнится ваше определение псевдопараллелизма или нет, зависит от того, потребуется ли ожидание или нет. А когда один поток кладет в словарь, а другой только читает — то это вообще не псевдопараллельные задачи, а в полном смысле параллельные, т.к. конкуренции за доступ нет. Так по вашему?
Re: ConcurrentDictionary не дает выгоды в производительности
От: Аноним  
Дата: 26.05.13 17:24
Оценка:
Здравствуйте, igor-booch, Вы писали:

IB>Задался вопросом: кто будет быстрее

IB>обычный Dictionary на одном потоке
IB>или ConcurrentDictionary на нескольких
IB>Написал тест, результаты шокировали.
IB>Даже на 8 ядерном процессоре Dictionary на одном потоке быстрее, чем ConcurrentDictionary на 8 потоках.

А что тут странного ?

Все просто, представим следующую ( упрощенную реализацию метода Add ConcurencyDictionary )


lock( _dictinonarySyncObject )
{
   dict[name] = value;
}



Очевидно что если мы запустим в нескольких потоках данный метод, то он будет выполняться не параллельно а последовательно из-за lock
т.е. допустим запустили 8 потоков 8 методов add, какой-то из них первый схватит lock и будет держать остальных, потом следующий и т.д.

Так что скорость добавления элемента в такой реализации никак не будет выше скорости добавления на одном потоке.
+накладные расходы на lock, создание потоков и т.п.
Re[13]: Товарищам смеющимся и минусующим: псевдопараллеризм
От: igor-booch Россия  
Дата: 26.05.13 18:46
Оценка:
Здравствуйте, samius, Вы писали:

S>Здравствуйте, igor-booch, Вы писали:


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

IB>>А что технически означает "без побочных эффектов". Это значит функция не может менять не одну переменную, которую может менять какая-либо другая функция. Эту переменную я называю по-разному в предыдущих постах: контекстом выполнения, глобальным состоянием, общим ресурсом, общедоступной переменной, внешней переменной, переменной с конкурентным доступом.
S>Вот то что вы называете что-то разными терминами и путает вас. Стек — это тоже контекст. Куча — и контекст и общедоступный ресурс, да еще и с конкурентным доступом. И все выполняется в этом контексте и чистые функции не исключение совершенно. Определяйте используемые термины жестче, иначе непонятно, что вы подразумеваете.
То что я называю разными терминами это варианты использования общедоступной переменной или то чем она является, частные случаи. Читателя я хочу привести от частного к общему (индукция). Стек вызовов это не переменная. Да, стек вызовов функций — это тоже контекст, согласен. Но это не такой же контекст как переменная. Надеюсь Вы никогда не пишите методы в таком ключе:

int Foo()
{
    if (меня вызвала функция A)
    {
        Вычисляю результат способом 1;
    }
    else
    {
        Вычисляю результат способом 2;
    }         
}


Надеюсь вместо этого Вы пишите:
int Foo()
{
    if (общедоступная_переменная == "А")
    {
        Вычисляю результат способом 1;
    }
    else
    {
        Вычисляю результат способом 2;
    }         
}


Кстати это пример не детерминированной функции. В зависимости от того какое значение будет принимать общедоступная_переменная, результат этой функции будет разным. Вот пример функции с побочным эффектом:

void Foo()
{
    общедоступная_переменная = "B";        
}

Мы меняем общедоступную переменную.

S>А переменная, которую не может менять какая-либо другая функция — это не определение.

IB>>http://msdn.microsoft.com/en-us/library/bb669139.aspx
S>Если это тянет на определение, то оно не полное и неточное.
Дайте свое определение, только расшифруйте, что значит побочный эффект и каким образом функция может стать не детерминированной.
Дополнить своё определение общедоступной переменной хочу тем, что общедоступная переменная эта переменная, которая не входит в аргументы функции.


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

S>Еще раз. Вы неверно используете термин псевдопараллельность.
S>в случае f = sin(x*x), значение, полученное в качестве результата x*x — есть как раз промежуточный результат, который складывается на стек для вызова sin. Понятно на что я намекаю? В ваших терминах f — грязная функция, да еще и псевдопараллельно выполняющаяся задача.
Это будет справедливо если я попытаюсь 2 операции: умножение и sin выполнить параллельно. Только я так делать не буду. Я же писал что все нужно распараллерировать "до яиц"
Еще это справедливо если стек вызовов считать контекстом, я в своих рассуждения так не считаю, см. предыдущий ответ.
Еще результат возвращенный функцией F не является общедоступной переменной, он доступен только той функции которая вызвала F.
f = sin(x*x) это функция которая не поддается распараллеливанию. В f = sin(x*x) sin зависит от результатов умножения, поэтому f = sin(x*x) распараллерить нельзя, даже в функциональном программировании. И sin является чистой функцией, так как зависит только от своего аргумента. Если взять отдельно умножение, то его можно распаралерировать, и sin тоже можно, если разложить в ряд слогаемых.
Другое дело если будет
f = f1(f2(x), f3(x))
Здесь два вычисления f2(x) и f3(x) можно запустить как две параллельные задачи, если f2 и f3 чистые функции.
Если f2 и f3 грязные функции их вычисления можно запустить как псевдопараллельные.

S>>>Это как это изолирована?

IB>>Я употребил это как синоним чистоты функции.
S>Зачем? Очень неочевидный синоним.
Изолированна от контекста. Если контекстом считать общедоступную переменную вполне очевидный синоним. Еще один синоним "не зависит" (от контекста).

IB>>Если общедоступную переренную, то чистые функции не выполняются в контексте.

S>Почему? Раз переменная общедоступна, то она доступна любой функции, и чистой тоже. И чистые функции даже могут переменную читать и использовать полученное значение для вычисления результата с единственным ограничеием — результат не должен зависеть от того значения. А что может зависеть? Например, метод получения результата.
Очень интересно. Приведете пример такой чистой функции на псевдокоде.

IB>>Если стек вызова, то есть какая функция вызвала данную функцию, то, да и чистые и грязные функции выполняются в контексте. Но не чистые не грязные не имеют доступа к такому контексту на прямую.

S>Это откуда следует?
См. первый пример кода в этом после. В C# есть возможность получить доступ к стеку вызовов: класс StackTrace. Но я надеюсь Вы согласитесь, завязывать на него логику функций нельзя.


IB>>>>В чистом ФЯП понятия контекста выполнения (и потока выполнения) вообще не существует.

S>>>Это определенно новость.
IB>>Уточню не существует потока выполнения, таким как он понимается в императивном программировании. В ФЯП нет условных и безусловных переходов, нет циклов. Есть только полседовательность вызова одних функций другими, но для отдельно взятой функции эта последовательность не важна, так как нет глобального состояния.
IB>>http://msdn.microsoft.com/en-us/library/bb669144.aspx
S>Вот откройте свою ссылку и разглядите там в табличке что в ФП внезапно есть control flow, которые и есть порядок выполнения. И он одинакого нужен и ИП и ФП. Да, GOTO в ФП обычно не держат, но прямой заменитель как правило имеется — if-then-else. Вместо циклов — рекурсия. И композиция определяет порядок вызовов функций.
Вы думаете я вам прислал эту ссылку не посмотрев на неё? Я кажется ясно написал, что в ФЯП есть полседовательность вызова одних функций другими.
Во первых управление потоком выполнения (flow control) и порядок выполнения (Order of execution) это разные вещи. В ФЯП аналоги if-then-else есть, называются сопоставления с образцом (pattern matching), но они не являются средствами управления потом выполнения.
А вот порядок выполнения (Order of execution) может быть важен только для грязных функций (императивное программирование). Например F1 инициализирует общедоступную переменную, а F2 читает проинициализированную общедоступную переменную. Правильная последовательность вызовов это сначала вызвать F1, а потом F2. Если Вы сначала вызовете F2, она будет читать непроинициализированную общедоступную переменную. Если функции чистые и не зависят от общедоступных переменных, порядок их выполнения (Order of execution) не важен. Тоже самое написано в ссылке, которую Вы мне посоветовали открыть. Да сначала я выразился по поводу потока выполнения недостаточно точно, сейчас уточнил.
GOTO в ФП не обычно не держат, а вообще не держат.
Циклы кстати реализуются через if и goto вверх (и вниз) по потоку выполнения.


IB>>>>За счет этого в чистых ФЯП возможно автоматическое распараллерирование.

S>>>Нет, не поэтому. А потому что (и ровно до тех пор пока) менять ничего нельзя.
IB>>Я об этом и написал. Для чистой функции доступны только аргументы переданные ей. Эти аргументы она не меняет. Она может только передать их другой функции. А переменных вне чистой функции (внешних переменных) не существует. Больше менять нечего.
S>Когда вы об этом писали, вы ссылались на некий контекст, который не определили. А теперь я вам показал как чистая функция может взаимодействовать с контекстом (например с глобальной переменной), оставаясь формально чистой.
Спросили бы что я подразумеваю под контекстом, если считали, что я его не определил.
Где Вы мне показали как чистая функция может взаимодействовать с контекстом (например с глобальной переменной), оставаясь формально чистой?
Чистая функция должна быть дитерминированной. Детерминированной функция в любой момент времени при одних и тех же аргументах возвращает одинаковые результаты. Вот грязная функция (ссылается на общедоступнуб переменную):


int Foo(int arg)
{
    return общедоступная_переменная * arg;
}


Теперь рассмотрим такой код:

общедоступная_переменная = 1;
результат1 = Foo(3);
общедоступная_переменная = 3;
результат2 = Foo(3);


Значение переменной результат1 будет не равно значению переменной результат2. Хотя функция Foo вызывалась с одним и тем же аргументом 3.
Чистая функция не может ссылаться на общедоступные переменные, поэтому недетерминированность для неё невозможна в принципе. http://rsdn.ru/forum/dotnet/5180373.1
Автор: igor-booch
Дата: 25.05.13


S>>>Устойчивое значение термина "псевдопараллелизм" — выполнение параллельных задач на одном ядре.

IB>>Это Вы путаете с гиперпоточностью (HyperThreading). Гиперпоточность это аппаратная технология, а псевдопараллеризм это программное понятие.
S>Это вы меня хотите запутать, но не выйдет.
Зачем так негативно воспринимать. В споре рождается истина. Может Вы что-то от меня узнаете, может я от Вас. Простите если слишком грубо выразил свое несогласие с Вами по поводу того, что Hyper-threading это не псевдопараллелизм.
Ответил в другом посте http://rsdn.ru/forum/dotnet/5180799.1
Автор: igor-booch
Дата: 26.05.13
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания
http://rsdn.ru/Info/rules.xml
Re[16]: Товарищам смеющимся и минусующим: псевдопараллеризм
От: igor-booch Россия  
Дата: 26.05.13 19:02
Оценка:
S>Я не собираюсь рассматривать всерьез вашу трактовку так как 1) вы не можете или не хотите указать источник,
Не могу:
то что я пишу это то как я понимаю параллелизм на основе всего, что я ранее читал и своего опыта. Источников в этом смысле очень много я всех я не вспомню.

S>Видите ли, если за доступ к переменной или Dictionary нужно конкурировать, то в случае ConcurrentDictionary — все зависит от случая. Выполнится ваше определение псевдопараллелизма или нет, зависит от того, потребуется ли ожидание или нет.

Ожидание может может потребовать а может и нет, общедоступный ресурс может потребоваться в одни момент времени несколькими псевдопараллельно выполняющимися задачами, а может и нет. Это действительно дело случая.

S>А когда один поток кладет в словарь, а другой только читает — то это вообще не псевдопараллельные задачи, а в полном смысле параллельные, т.к. конкуренции за доступ нет. Так по вашему?

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

S>На это указывает попытка приписать мне путаницу с гипертредингом.

Еще раз прошу прошение если слишком грубо выразил свое несогласие с Вами по поводу того, что Hyper-threading это не псевдопараллелизм. Но я на данный момент остаюсь при своем мнении.
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания
http://rsdn.ru/Info/rules.xml
Re[2]: ConcurrentDictionary не дает выгоды в производительности
От: igor-booch Россия  
Дата: 26.05.13 19:09
Оценка:
IB>Даже на 8 ядерном процессоре Dictionary на одном потоке быстрее, чем ConcurrentDictionary на 8 потоках.
А>А что тут странного ?
А>Все просто, представим следующую ( упрощенную реализацию метода Add ConcurencyDictionary )

А>

А>lock( _dictinonarySyncObject )
А>{
А>   dict[name] = value;
А>}

А>



В ConcurencyDictionary используются более гранулярные блокировки. С такой блокировкой отдельный класс ConcurencyDictionary не нужен. Можно на обычный Dictionary всегда писать

lock(dict)
{
   dict[name] = value;
}


и тогда действительно ничего странного не будет.
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания
http://rsdn.ru/Info/rules.xml
Re[14]: Товарищам смеющимся и минусующим: псевдопараллеризм
От: samius Япония http://sams-tricks.blogspot.com
Дата: 26.05.13 20:18
Оценка:
Здравствуйте, igor-booch, Вы писали:

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


IB>То что я называю разными терминами это варианты использования общедоступной переменной или то чем она является, частные случаи. Читателя я хочу привести от частного к общему (индукция). Стек вызовов это не переменная. Да, стек вызовов функций — это тоже контекст, согласен. Но это не такой же контекст как переменная.

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

IB>Надеюсь Вы никогда не пишите методы в таком ключе:

IB>
IB>    if (меня вызвала функция A)
IB>


IB>Надеюсь вместо этого Вы пишите:

IB>
IB>    if (общедоступная_переменная == "А")
IB>

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

IB>Кстати это пример не детерминированной функции. В зависимости от того какое значение будет принимать общедоступная_переменная, результат этой функции будет разным.

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

IB>Вот пример функции с побочным эффектом:

Я знаю что такое функция с побочным эффектом.

S>>А переменная, которую не может менять какая-либо другая функция — это не определение.

IB>>>http://msdn.microsoft.com/en-us/library/bb669139.aspx
S>>Если это тянет на определение, то оно не полное и неточное.
IB>Дайте свое определение, только расшифруйте, что значит побочный эффект и каким образом функция может стать не детерминированной.
http://en.wikipedia.org/wiki/Pure_function
Я даю определения в очень редких случаях. Предпочитаю пользоваться общеупотребимыми и общедоступными, что бы люди меня понимали.
Определение побочного эффекта можно найти дальше по ссылочке, а как функция становится недетерминированной можно понять прямо из определения.
IB>Дополнить своё определение общедоступной переменной хочу тем, что общедоступная переменная эта переменная, которая не входит в аргументы функции.
По вашему доплненному определению локальная переменная функции общедоступна.

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

S>>Еще раз. Вы неверно используете термин псевдопараллельность.
S>>в случае f = sin(x*x), значение, полученное в качестве результата x*x — есть как раз промежуточный результат, который складывается на стек для вызова sin. Понятно на что я намекаю? В ваших терминах f — грязная функция, да еще и псевдопараллельно выполняющаяся задача.
IB>Это будет справедливо если я попытаюсь 2 операции: умножение и sin выполнить параллельно. Только я так делать не буду. Я же писал что все нужно распараллерировать "до яиц"
Вы не поняли иронию. Я пытаюсь применять ваши формулировки.
IB>Еще это справедливо если стек вызовов считать контекстом, я в своих рассуждения так не считаю, см. предыдущий ответ.
IB>Еще результат возвращенный функцией F не является общедоступной переменной, он доступен только той функции которая вызвала F.
По вашему последнему дополнению к понятию общедоступной переменной — это общедоступный результат
IB>f = sin(x*x) это функция которая не поддается распараллеливанию. В f = sin(x*x) sin зависит от результатов умножения, поэтому f = sin(x*x) распараллерить нельзя, даже в функциональном программировании. И sin является чистой функцией, так как зависит только от своего аргумента. Если взять отдельно умножение, то его можно распаралерировать, и sin тоже можно, если разложить в ряд слогаемых.
IB>Другое дело если будет
IB>f = f1(f2(x), f3(x))
IB>Здесь два вычисления f2(x) и f3(x) можно запустить как две параллельные задачи, если f2 и f3 чистые функции.
IB>Если f2 и f3 грязные функции их вычисления можно запустить как псевдопараллельные.
Нет, нельзя, т.к. могут помешать друг другу получить ожидаемый результат.

S>>Зачем? Очень неочевидный синоним.

IB>Изолированна от контекста. Если контекстом считать общедоступную переменную вполне очевидный синоним. Еще один синоним "не зависит" (от контекста).
Ну так мы же еще не договорились, что считать контекстом!

IB>>>Если общедоступную переренную, то чистые функции не выполняются в контексте.

S>>Почему? Раз переменная общедоступна, то она доступна любой функции, и чистой тоже. И чистые функции даже могут переменную читать и использовать полученное значение для вычисления результата с единственным ограничеием — результат не должен зависеть от того значения. А что может зависеть? Например, метод получения результата.
IB>Очень интересно. Приведете пример такой чистой функции на псевдокоде.
string Quote(string v)
{
   return (GlobalFlag == 0)
      ? "\"" + v + "\""
      : String.Format("\"{0}\"", v);
}


IB>>>Если стек вызова, то есть какая функция вызвала данную функцию, то, да и чистые и грязные функции выполняются в контексте. Но не чистые не грязные не имеют доступа к такому контексту на прямую.

S>>Это откуда следует?
IB>См. первый пример кода в этом после. В C# есть возможность получить доступ к стеку вызовов: класс StackTrace. Но я надеюсь Вы согласитесь, завязывать на него логику функций нельзя.
Нет, не соглашусь. Что значит нельзя? Можно. Так откуда следует что функции не имеют доступа к стеку? Особенно с учетом того что локальные переменные расположены на стеке. И что адрес локальной переменной можно передать выше по стеку...

IB>>>http://msdn.microsoft.com/en-us/library/bb669144.aspx

S>>Вот откройте свою ссылку и разглядите там в табличке что в ФП внезапно есть control flow, которые и есть порядок выполнения. И он одинакого нужен и ИП и ФП. Да, GOTO в ФП обычно не держат, но прямой заменитель как правило имеется — if-then-else. Вместо циклов — рекурсия. И композиция определяет порядок вызовов функций.
IB>Вы думаете я вам прислал эту ссылку не посмотрев на неё? Я кажется ясно написал, что в ФЯП есть полседовательность вызова одних функций другими.
Да, и вы написали что он не важен. Отсылаю вас к примеру sin(x*x)
IB>Во первых управление потоком выполнения (flow control) и порядок выполнения (Order of execution) это разные вещи. В ФЯП аналоги if-then-else есть, называются сопоставления с образцом (pattern matching), но они не являются средствами управления потом выполнения.
Да ладно? Не может быть! (это к разным предложениям)
IB>А вот порядок выполнения (Order of execution) может быть важен только для грязных функций (императивное программирование). Например F1 инициализирует общедоступную переменную, а F2 читает проинициализированную общедоступную переменную. Правильная последовательность вызовов это сначала вызвать F1, а потом F2. Если Вы сначала вызовете F2, она будет читать непроинициализированную общедоступную переменную. Если функции чистые и не зависят от общедоступных переменных, порядок их выполнения (Order of execution) не важен. Тоже самое написано в ссылке, которую Вы мне посоветовали открыть. Да сначала я выразился по поводу потока выполнения недостаточно точно, сейчас уточнил.
Порядок выполнения важен — см. sin(x*x)
IB>GOTO в ФП не обычно не держат, а вообще не держат.
IB>Циклы кстати реализуются через if и goto вверх (и вниз) по потоку выполнения.
Раз так, то и вызов функции — тоже goto.

IB>>>>>За счет этого в чистых ФЯП возможно автоматическое распараллерирование.

S>>>>Нет, не поэтому. А потому что (и ровно до тех пор пока) менять ничего нельзя.
IB>>>Я об этом и написал. Для чистой функции доступны только аргументы переданные ей. Эти аргументы она не меняет. Она может только передать их другой функции. А переменных вне чистой функции (внешних переменных) не существует. Больше менять нечего.
S>>Когда вы об этом писали, вы ссылались на некий контекст, который не определили. А теперь я вам показал как чистая функция может взаимодействовать с контекстом (например с глобальной переменной), оставаясь формально чистой.
IB>Спросили бы что я подразумеваю под контекстом, если считали, что я его не определил.
Я думал что вы знаете что вы его не определили.
IB>Где Вы мне показали как чистая функция может взаимодействовать с контекстом (например с глобальной переменной), оставаясь формально чистой?
Полагал что достаточно было словесного описания, но вы попросили пример. См. выше пример с функцией Quote.
IB>Чистая функция должна быть дитерминированной. Детерминированной функция в любой момент времени при одних и тех же аргументах возвращает одинаковые результаты. Вот грязная функция (ссылается на общедоступнуб переменную):
Я не утверждал обратного, не пойму, зачем вы меня разоблачаете? Пример поскипал.

IB>Чистая функция не может ссылаться на общедоступные переменные, поэтому недетерминированность для неё невозможна в принципе. http://rsdn.ru/forum/dotnet/5180373.1
Автор: igor-booch
Дата: 25.05.13

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

IB>>>Это Вы путаете с гиперпоточностью (HyperThreading). Гиперпоточность это аппаратная технология, а псевдопараллеризм это программное понятие.

S>>Это вы меня хотите запутать, но не выйдет.
IB>Зачем так негативно воспринимать. В споре рождается истина. Может Вы что-то от меня узнаете, может я от Вас. Простите если слишком грубо выразил свое несогласие с Вами по поводу того, что Hyper-threading это не псевдопараллелизм.
Уверяю, негатива не было. Считайте что забыл поставить смайл. Извинения не требуются, но приняты на тот случай, если вы обидитесь если я их не приму
IB>Ответил в другом посте http://rsdn.ru/forum/dotnet/5180799.1
Автор: igor-booch
Дата: 26.05.13
Re[17]: Товарищам смеющимся и минусующим: псевдопараллеризм
От: samius Япония http://sams-tricks.blogspot.com
Дата: 26.05.13 20:34
Оценка:
Здравствуйте, igor-booch, Вы писали:

S>>Я не собираюсь рассматривать всерьез вашу трактовку так как 1) вы не можете или не хотите указать источник,

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

S>>Видите ли, если за доступ к переменной или Dictionary нужно конкурировать, то в случае ConcurrentDictionary — все зависит от случая. Выполнится ваше определение псевдопараллелизма или нет, зависит от того, потребуется ли ожидание или нет.

IB>Ожидание может может потребовать а может и нет, общедоступный ресурс может потребоваться в одни момент времени несколькими псевдопараллельно выполняющимися задачами, а может и нет. Это действительно дело случая.
Я не привык оперировать с недетерминированными определениями, которые работают от случая к случаю

S>>А когда один поток кладет в словарь, а другой только читает — то это вообще не псевдопараллельные задачи, а в полном смысле параллельные, т.к. конкуренции за доступ нет. Так по вашему?

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

S>>На это указывает попытка приписать мне путаницу с гипертредингом.

IB>Еще раз прошу прошение если слишком грубо выразил свое несогласие с Вами по поводу того, что Hyper-threading это не псевдопараллелизм.
По поводу извинений уже ответил, а вот несогласие я выражал в другом отношении. Я не согласился в том что я перепутал псевдопараллелизм и гипертрединг. И предоставил ссылку на литературу, употреблявшую этот термин задолго до появления этой фишки в продаже. А теперь вы будто-бы приписываете мне тезис о том что HT это не псевдопараллерлизм. Я такого не утверждал.

IB>Но я на данный момент остаюсь при своем мнении.

Рад
Re[18]: Товарищам смеющимся и минусующим: псевдопараллеризм
От: igor-booch Россия  
Дата: 27.05.13 07:19
Оценка:
S>Я не собираюсь рассматривать всерьез вашу трактовку так как 1) вы не можете или не хотите указать источник,
IB>>Не могу:
IB>>то что я пишу это то как я понимаю параллелизм на основе всего, что я ранее читал и своего опыта. Источников в этом смысле очень много я всех я не вспомню.
S>Не нужно все. Укажите хотя бы один. Не может быть такого что их настолько много что они не гуглятся...
http://en.wikipedia.org/wiki/Concurrency_(computer_science)
http://en.wikipedia.org/wiki/Parallel_computing
http://www.osp.ru/os/2010/01/13000689/
http://umk.portal.kemsu.ru/mps/html/node_book.htm#p1
Только в явном виде то, о чем я написал Вы не найдете, нужно использовать
http://www.fondgp.ru/gp/biblio/rus/51
Граница между синтезом знаний и генерированием знаний нечеткая. Мы же люди, а не роботы.
Если все уже написано и осмыслено до нас, зачем тогда нам писать, осмыслять и обсуждать обмениваясь своим видением и пониманием сути вещей?

S>>>Видите ли, если за доступ к переменной или Dictionary нужно конкурировать, то в случае ConcurrentDictionary — все зависит от случая. Выполнится ваше определение псевдопараллелизма или нет, зависит от того, потребуется ли ожидание или нет.

IB>>Ожидание может может потребовать а может и нет, общедоступный ресурс может потребоваться в одни момент времени несколькими псевдопараллельно выполняющимися задачами, а может и нет. Это действительно дело случая.
S>Я не привык оперировать с недетерминированными определениями, которые работают от случая к случаю
Так в ошибки связанные неправильной организацией конкурентного доступа в многопоточном программировании носят случайный характер

S>>>А когда один поток кладет в словарь, а другой только читает — то это вообще не псевдопараллельные задачи, а в полном смысле параллельные, т.к. конкуренции за доступ нет. Так по вашему?

IB>>Нет, это тоже псевдопараллелизм, неважно чтение или запись в общедоступную переменную, это все-равно доступ к ней, за который (за доступ) идет конкуренция.
S>Так а нету конкуренции ведь! Один поток пишет и ни с кем не конкурирует, другой читает и тоже не конкурирует. Никто никого не ждет ни пол такта. Могут выполняться на разных физических ядрах параллельно в полном смысле этого слова.
Наверное Вы имеете ввиду multiple readers, single writer (ReadWriteLock). В этом смысле чтецы между собой не конкурируют, конкурируют только писатели между собой и чтецы с писателями. Но псевдопараллеризм не сделать только на чтецах.
Принцип multiple readers, single writer позволяет повысить эффективность конкурентного доступа к ресурсу.
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания
http://rsdn.ru/Info/rules.xml
Re[19]: Товарищам смеющимся и минусующим: псевдопараллеризм
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 27.05.13 07:32
Оценка:
Здравствуйте, igor-booch, Вы писали:

Что то вы в теорию углубились. Мне вот лично интересно какой эффект будет от применения массива из 101 хэш таблицы с применением ReadWriteLock при доступе к Хэш таблице.
Насколько дополнительный код ConcurrentDictionary тяжел и насколько проще решать через вероятность. На самом деле внутри ConcurrentDictionary тоже применяется Lock но это на запись.
Чтение вообще блокировок не испльзует. Но вот при 8 потоках вероятность доступа к каждой хэш таблице будет 8/101. Можно поиграть с количеством этого массива и выяснить при каком количестве эффекта не наблюдается и сравнить со скоростью ConcurrentDictionary
и солнце б утром не вставало, когда бы не было меня
Re[19]: Товарищам смеющимся и минусующим: псевдопараллеризм
От: samius Япония http://sams-tricks.blogspot.com
Дата: 27.05.13 07:55
Оценка:
Здравствуйте, igor-booch, Вы писали:

IB>>>то что я пишу это то как я понимаю параллелизм на основе всего, что я ранее читал и своего опыта. Источников в этом смысле очень много я всех я не вспомню.

S>>Не нужно все. Укажите хотя бы один. Не может быть такого что их настолько много что они не гуглятся...

IB>Только в явном виде то, о чем я написал Вы не найдете, нужно использовать

Ясно. То есть вы не можете указать на то что в вашей формулировке этим термином кто-то пользуется. Именно это я и хотел выяснить. Кстати, я спрашивал у вас понимание псевдопараллелизма, а не параллелизма.
IB>http://www.fondgp.ru/gp/biblio/rus/51
IB>Граница между синтезом знаний и генерированием знаний нечеткая. Мы же люди, а не роботы.
Ну а причем тут синтез знаний, если идет обсуждение понимания устоявшегося термина?
IB>Если все уже написано и осмыслено до нас, зачем тогда нам писать, осмыслять и обсуждать обмениваясь своим видением и пониманием сути вещей?
Например, для того что бы понять, что было написано до нас.

IB>>>Ожидание может может потребовать а может и нет, общедоступный ресурс может потребоваться в одни момент времени несколькими псевдопараллельно выполняющимися задачами, а может и нет. Это действительно дело случая.

S>>Я не привык оперировать с недетерминированными определениями, которые работают от случая к случаю
IB>Так в ошибки связанные неправильной организацией конкурентного доступа в многопоточном программировании носят случайный характер
Не соглашусь. Ошибка она или есть или ее нет. Сама она не может ни появиться ни исчезнуть. А вот ее проявление зависит от случая, то есть может проявляться, а может не проявляться.

S>>Так а нету конкуренции ведь! Один поток пишет и ни с кем не конкурирует, другой читает и тоже не конкурирует. Никто никого не ждет ни пол такта. Могут выполняться на разных физических ядрах параллельно в полном смысле этого слова.

IB>Наверное Вы имеете ввиду multiple readers, single writer (ReadWriteLock). В этом смысле чтецы между собой не конкурируют, конкурируют только писатели между собой и чтецы с писателями. Но псевдопараллеризм не сделать только на чтецах.
Я же написал что я имел в виду. ConcurrentDictionary, один поток читатель и один поток писатель.
IB>Принцип multiple readers, single writer позволяет повысить эффективность конкурентного доступа к ресурсу.
Что бы этот тезис был справедлив, нужно указать относительно какого сценария он позволяет повысить эффективность.
Re[15]: Товарищам смеющимся и минусующим: псевдопараллеризм
От: igor-booch Россия  
Дата: 27.05.13 08:14
Оценка:
S>Я вам просто демонстрирую недостаток недоговоренности о значениях терминов.
Я абсолютно согласен, что недостатки есть, предела совершенству нет.
Еще чтобы более лояльно относиться к таким недостаткам можете посмотреть теорему Геделя о неполноте.



IB>>Кстати это пример не детерминированной функции. В зависимости от того какое значение будет принимать общедоступная_переменная, результат этой функции будет разным.

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

IB>>Вот пример функции с побочным эффектом:

S>Я знаю что такое функция с побочным эффектом.
Верю...

S>>>А переменная, которую не может менять какая-либо другая функция — это не определение.

IB>>>>http://msdn.microsoft.com/en-us/library/bb669139.aspx
S>>>Если это тянет на определение, то оно не полное и неточное.
IB>>Дайте свое определение, только расшифруйте, что значит побочный эффект и каким образом функция может стать не детерминированной.
S>http://en.wikipedia.org/wiki/Pure_function
S>Я даю определения в очень редких случаях. Предпочитаю пользоваться общеупотребимыми и общедоступными, что бы люди меня понимали.
В вашей ссылке написано, то что хорошо согласуется с тем, что пишу, замените только слово "state" (состояние) на слово "общедоступная переменная".


S>По вашему последнему дополнению к понятию общедоступной переменной — это общедоступный результат

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

IB>>f = f1(f2(x), f3(x))

IB>>Здесь два вычисления f2(x) и f3(x) можно запустить как две параллельные задачи, если f2 и f3 чистые функции.
IB>>Если f2 и f3 грязные функции их вычисления можно запустить как псевдопараллельные.
S>Нет, нельзя, т.к. могут помешать друг другу получить ожидаемый результат.
А чтоб не мешали необходима синхронизация конкуррентного доступа к общим ресурсам (общедоступным переменным)

S>>>Зачем? Очень неочевидный синоним.

IB>>Изолированна от контекста. Если контекстом считать общедоступную переменную вполне очевидный синоним. Еще один синоним "не зависит" (от контекста).
S>Ну так мы же еще не договорились, что считать контекстом!
Я в предыдущем сообщении пояснил что я подразумеваю по контекстом. Если подразумевать что то другое, то конечно логическая целостность моих рассуждений нарушится. Но так можно любую теорию опровергнуть. Любая теория начинается с терминологической системы.

IB>>>>Если общедоступную переренную, то чистые функции не выполняются в контексте.

S>>>Почему? Раз переменная общедоступна, то она доступна любой функции, и чистой тоже. И чистые функции даже могут переменную читать и использовать полученное значение для вычисления результата с единственным ограничеием — результат не должен зависеть от того значения. А что может зависеть? Например, метод получения результата.
IB>>Очень интересно. Приведете пример такой чистой функции на псевдокоде.
S>
S>string Quote(string v)
S>{
S>   return (GlobalFlag == 0)
S>      ? "\"" + v + "\""
S>      : String.Format("\"{0}\"", v);
S>}
S>

Да еще можно написать

string Quote(string v)
{
   return (GlobalFlag == GlobalFlag)
      ? "\"" + v + "\""
      : String.Format("\"{0}\"", v);
}

Тоже будет ссылаться на общедоступную переменную (GlobalFlag), но от ней результат функции зависеть не будет. Спасибо за наводку. Более точное определение чистой функции такое:
логически редуцированная форма функции не ссылается на общедоступные переменные



IB>>Во первых управление потоком выполнения (flow control) и порядок выполнения (Order of execution) это разные вещи. В ФЯП аналоги if-then-else есть, называются сопоставления с образцом (pattern matching), но они не являются средствами управления потом выполнения.

S>Да ладно? Не может быть! (это к разным предложениям)
В http://msdn.microsoft.com/en-us/library/bb669144.aspx см. таблицу и строки в ней: Order of execution и Primary flow control


IB>>А вот порядок выполнения (Order of execution) может быть важен только для грязных функций (императивное программирование). Например F1 инициализирует общедоступную переменную, а F2 читает проинициализированную общедоступную переменную. Правильная последовательность вызовов это сначала вызвать F1, а потом F2. Если Вы сначала вызовете F2, она будет читать непроинициализированную общедоступную переменную. Если функции чистые и не зависят от общедоступных переменных, порядок их выполнения (Order of execution) не важен. Тоже самое написано в ссылке, которую Вы мне посоветовали открыть. Да сначала я выразился по поводу потока выполнения недостаточно точно, сейчас уточнил.

S>Порядок выполнения важен — см. sin(x*x)
В этом смысле важен. Функция не может быть выполнена пока не вычисленны все её аргументы

IB>>GOTO в ФП не обычно не держат, а вообще не держат.

IB>>Циклы кстати реализуются через if и goto вверх (и вниз) по потоку выполнения.
S>Раз так, то и вызов функции — тоже goto.
Только этот goto может только компилятор ФЯП генерировать, а программисту при написании программы он недоступен в принципе.
В структурном программировании и ассемблерном goto доступен программисту.
См. Primary flow control это контроль не компилятором, а программистом.


IB>>Чистая функция должна быть дитерминированной. Детерминированной функция в любой момент времени при одних и тех же аргументах возвращает одинаковые результаты. Вот грязная функция (ссылается на общедоступнуб переменную):

S>Я не утверждал обратного, не пойму, зачем вы меня разоблачаете? Пример поскипал.
Очень хорошо, значит мы друг друга поняли. Я так на всякий случай написал.
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания
http://rsdn.ru/Info/rules.xml
Re[20]: Товарищам смеющимся и минусующим: псевдопараллеризм
От: igor-booch Россия  
Дата: 27.05.13 08:28
Оценка:
S> Что то вы в теорию углубились.
Мне понравилось. Я для себя много чего прояснил и узнал нового. Спасибо RSDN и всем участникам в том, числе смеющимся и минусующим.

S> Мне вот лично интересно какой эффект будет от применения массива из 101 хэш таблицы с применением ReadWriteLock при доступе к Хэш таблице.

S>Насколько дополнительный код ConcurrentDictionary тяжел и насколько проще решать через вероятность. На самом деле внутри ConcurrentDictionary тоже применяется Lock но это на запись.
S>Чтение вообще блокировок не испльзует. Но вот при 8 потоках вероятность доступа к каждой хэш таблице будет 8/101. Можно поиграть с количеством этого массива и выяснить при каком количестве эффекта не наблюдается и сравнить со скоростью ConcurrentDictionary

Да интересно было это посмотреть,
Но область применения такого подхода ограничена
http://rsdn.ru/forum/dotnet/5178409.1
Автор: igor-booch
Дата: 23.05.13


Еще интересно было бы посмотреть
http://rsdn.ru/forum/dotnet/5177162.1
Автор: igor-booch
Дата: 22.05.13
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания
http://rsdn.ru/Info/rules.xml
Re[15]: Товарищам смеющимся и минусующим: псевдопараллеризм
От: igor-booch Россия  
Дата: 27.05.13 08:32
Оценка:
IB>>Чистая функция не может ссылаться на общедоступные переменные, поэтому недетерминированность для неё невозможна в принципе. http://rsdn.ru/forum/dotnet/5180373.1
Автор: igor-booch
Дата: 25.05.13

S>Нарушение причины и следствия. детерминированность — необходимое условие чистоты, а не наоборот. И если есть детерминированная функция без сайд-эффектов, ссылающаяся на общедоступные переменные, то она и будет чистой по определению. А то что чистая функция может быть недетерминированной — этого я не утвреждал.
По моему нет нарушения. Возможно это
Автор: igor-booch
Дата: 25.05.13
прояснит ситуацию.
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания
http://rsdn.ru/Info/rules.xml
Re[21]: Товарищам смеющимся и минусующим: псевдопараллеризм
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 27.05.13 09:04
Оценка:
Здравствуйте, igor-booch, Вы писали:

S>> Что то вы в теорию углубились.

IB>Мне понравилось. Я для себя много чего прояснил и узнал нового. Спасибо RSDN и всем участникам в том, числе смеющимся и минусующим.

S>> Мне вот лично интересно какой эффект будет от применения массива из 101 хэш таблицы с применением ReadWriteLock при доступе к Хэш таблице.

S>>Насколько дополнительный код ConcurrentDictionary тяжел и насколько проще решать через вероятность. На самом деле внутри ConcurrentDictionary тоже применяется Lock но это на запись.
S>>Чтение вообще блокировок не испльзует. Но вот при 8 потоках вероятность доступа к каждой хэш таблице будет 8/101. Можно поиграть с количеством этого массива и выяснить при каком количестве эффекта не наблюдается и сравнить со скоростью ConcurrentDictionary

IB>Да интересно было это посмотреть,

IB>Но область применения такого подхода ограничена
IB>http://rsdn.ru/forum/dotnet/5178409.1
Автор: igor-booch
Дата: 23.05.13




Ты делаешь надстройку реализую все методы Dictionary. Но внутри Делаешь доступ через массив. Внутри ConcurrentDictionary используется тот же GetHashCode

Тое есть
Class СтруктураХраненияХэшТаблиц <TKey, TValue>
{
public ReaderWriterLock rwl;
public Dictionary<TKey, TValue> ХэшТаблица

}

СтруктураХраненияХэшТаблиц<TKey, TValue>[] ХэшТаблицы
IB>Еще интересно было бы посмотреть
IB>http://rsdn.ru/forum/dotnet/5177162.1
Автор: igor-booch
Дата: 22.05.13





Про ReadWriteLock я уже писал.

public bool GetValue(TKey key, out TValue value)
 {
 int hashcode=this.m_comparer.GetHashCode(key);
 int bucketNo = (hashcode & 0x7fffffff) % 101;

СтруктураХраненияХэшТаблиц Структура=ХэшТаблицы[bucketNo];

Структура.rwl.AcquireReaderLock(0);
 try
 {
 return Структура.ХэшТаблица.GetValue(TKey key, out TValue value)

 } 
 finally
 {
 // Ensure that the lock is released.
Структура.rwl.ReleaseReaderLock();
 }


 }



И так со всеми методами. Ты получаешь Словарь в невысокой вероятностью доступа из разных потоков к одной хэш таблицы.
Компарер по умолчанию EqualityComparer<TKey>.Default;
и солнце б утром не вставало, когда бы не было меня
Re[22]: Товарищам смеющимся и минусующим: псевдопараллеризм
От: igor-booch Россия  
Дата: 27.05.13 09:22
Оценка:
S>Ты делаешь надстройку реализую все методы Dictionary. Но внутри Делаешь доступ через массив. Внутри ConcurrentDictionary используется тот же GetHashCode

S>Тое есть

S>Class СтруктураХраненияХэшТаблиц <TKey, TValue>
S> {
S> public ReaderWriterLock rwl;
S> public Dictionary<TKey, TValue> ХэшТаблица

S>}


S>СтруктураХраненияХэшТаблиц<TKey, TValue>[] ХэшТаблицы


Понял, посмотрю как будет время. Только непонятно зачем здесь ReaderWriterLock , по-моему можно без него обойтись.



IB>>Еще интересно было бы посмотреть

IB>>http://rsdn.ru/forum/dotnet/5177162.1
Автор: igor-booch
Дата: 22.05.13

S>Про ReadWriteLock я уже писал.

S>
S>public bool GetValue(TKey key, out TValue value)
S> {
S> int hashcode=this.m_comparer.GetHashCode(key);
S> int bucketNo = (hashcode & 0x7fffffff) % 101;

S>СтруктураХраненияХэшТаблиц Структура=ХэшТаблицы[bucketNo];

S>Структура.rwl.AcquireReaderLock(0);
S> try
S> {
S> return Структура.ХэшТаблица.GetValue(TKey key, out TValue value)

S> } 
S> finally
S> {
S> // Ensure that the lock is released.
S>Структура.rwl.ReleaseReaderLock();
S> }


S> }

S>



S>И так со всеми методами. Ты получаешь Словарь в невысокой вероятностью доступа из разных потоков к одной хэш таблицы.

S>Компарер по умолчанию EqualityComparer<TKey>.Default;

А здесь не понял зачем, СтруктураХраненияХэшТаблиц, можно и без них обойтись. Я имел ввиду что нужно взять исходники ConcurrentDictionary и переписать там механизм блокировок с применением ReaderWriterLock.

Здесь бесполезно обсуждать, нужно чтобы кто-то написал код, и тогда его обсуждать и тестировать.
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания
http://rsdn.ru/Info/rules.xml
Re[16]: Товарищам смеющимся и минусующим: псевдопараллеризм
От: igor-booch Россия  
Дата: 27.05.13 09:37
Оценка: :)
IB>>>GOTO в ФП не обычно не держат, а вообще не держат.
IB>>>Циклы кстати реализуются через if и goto вверх (и вниз) по потоку выполнения.
S>>Раз так, то и вызов функции — тоже goto.
IB>Только этот goto может только компилятор ФЯП генерировать, а программисту при написании программы он недоступен в принципе.
IB>В структурном программировании и ассемблерном goto доступен программисту.
IB>См. Primary flow control это контроль не компилятором, а программистом.

Маленькое уточнение,
В структурных языках программирования goto доступен, но goto отсутствует в парадигме структурного программирования (противоречит ей)
В структурных языках программирования goto является как-бы возможностью перейти на более низкий уровень неструктурного программирования.
В парадигме структурного программирования утверждается что все алгоритмы могут быть реализованы через условные конструкции и циклы, без goto
Сами условные конструкции и циклы на низком уровне реализуются с помощью goto
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания
http://rsdn.ru/Info/rules.xml
Re[23]: Товарищам смеющимся и минусующим: псевдопараллеризм
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 27.05.13 09:40
Оценка:
Здравствуйте, igor-booch, Вы писали:



IB>А здесь не понял зачем, СтруктураХраненияХэшТаблиц, можно и без них обойтись. Я имел ввиду что нужно взять исходники ConcurrentDictionary и переписать там механизм блокировок с применением ReaderWriterLock.


IB>Здесь бесполезно обсуждать, нужно чтобы кто-то написал код, и тогда его обсуждать и тестировать.

А там блокировка только на запись. Блокировок на чтение нет.
Вот как выглядит

private bool TryAddInternal(TKey key, TValue value, bool updateIfExists, bool acquireLock, out TValue resultingValue)
{
    int num2;
    int num3;
    Tables<TKey, TValue> tables;
    int hashCode = this.m_comparer.GetHashCode(key);
Label_000D:
    tables = this.m_tables;
    this.GetBucketAndLockNo(hashCode, out num2, out num3, tables.m_buckets.Length, tables.m_locks.Length);
    bool flag = false;
    bool lockTaken = false;
    try
    {
        if (acquireLock)
        {
            Monitor.Enter(tables.m_locks[num3], ref lockTaken);
        }
        if (tables != this.m_tables)
        {
            goto Label_000D;
        }
        Node<TKey, TValue> node = null;
        for (Node<TKey, TValue> node2 = tables.m_buckets[num2]; node2 != null; node2 = node2.m_next)
        {
            if (this.m_comparer.Equals(node2.m_key, key))
            {
                if (updateIfExists)
                {
                    if (ConcurrentDictionary<TKey, TValue>.s_isValueWriteAtomic)
                    {
                        node2.m_value = value;
                    }
                    else
                    {
                        Node<TKey, TValue> node3 = new Node<TKey, TValue>(node2.m_key, value, hashCode, node2.m_next);
                        if (node == null)
                        {
                            tables.m_buckets[num2] = node3;
                        }
                        else
                        {
                            node.m_next = node3;
                        }
                    }
                    resultingValue = value;
                }
                else
                {
                    resultingValue = node2.m_value;
                }
                return false;
            }
            node = node2;
        }
        Volatile.Write<Node<TKey, TValue>>(ref tables.m_buckets[num2], new Node<TKey, TValue>(key, value, hashCode, tables.m_buckets[num2]));
        tables.m_countPerLock[num3] += 1;
        if (tables.m_countPerLock[num3] > this.m_budget)
        {
            flag = true;
        }
    }
    finally
    {
        if (lockTaken)
        {
            Monitor.Exit(tables.m_locks[num3]);
        }
    }
    if (flag)
    {
        this.GrowTable(tables);
    }
    resultingValue = value;
    return true;
}



Monitor.Enter(tables.m_locks[num3] блокируется запись.

в tryGetValue используется MemoryBarrier

public static T Read<T>(ref T location) where T: class
{
T local = location;
Thread.MemoryBarrier();
return local;
}
и солнце б утром не вставало, когда бы не было меня
Re[17]: Товарищам смеющимся и минусующим: псевдопараллеризм
От: igor-booch Россия  
Дата: 27.05.13 09:41
Оценка:
Здравствуйте, igor-booch, Вы писали:

IB>>>>GOTO в ФП не обычно не держат, а вообще не держат.

IB>>>>Циклы кстати реализуются через if и goto вверх (и вниз) по потоку выполнения.
S>>>Раз так, то и вызов функции — тоже goto.
IB>>Только этот goto может только компилятор ФЯП генерировать, а программисту при написании программы он недоступен в принципе.
IB>>В структурном программировании и ассемблерном goto доступен программисту.
IB>>См. Primary flow control это контроль не компилятором, а программистом.

IB>Маленькое уточнение,

IB>В структурных языках программирования goto доступен, но goto отсутствует в парадигме структурного программирования (противоречит ей)
IB>В структурных языках программирования goto является как-бы возможностью перейти на более низкий уровень неструктурного программирования.
IB>В парадигме структурного программирования утверждается что все алгоритмы могут быть реализованы через условные конструкции и циклы, без goto
IB>Сами условные конструкции и циклы на низком уровне реализуются с помощью goto

А функциональном программировании пошли дальше и сказали, что все (почти все) алгоритмы можно записать только через вызовы (в т. ч. рекурсивные) функций (без условных конструкций и циклов).
Но сейчас известны алгоритмы крепкие орешки, для которых есть структурная запись, но отсутствует функциональная.
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания
http://rsdn.ru/Info/rules.xml
Re[23]: Товарищам смеющимся и минусующим: псевдопараллеризм
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 27.05.13 09:43
Оценка:
Здравствуйте, igor-booch, Вы писали:

IB>Здесь бесполезно обсуждать, нужно чтобы кто-то написал код, и тогда его обсуждать и тестировать.

Ну так этот кто то должен иметь задачу и интерес оптимального решения этой задачи. Если ты задаешь такие вопросы то тебе и флаг в руки.
и солнце б утром не вставало, когда бы не было меня
Re[16]: Товарищам смеющимся и минусующим: псевдопараллеризм
От: samius Япония http://sams-tricks.blogspot.com
Дата: 27.05.13 09:48
Оценка:
Здравствуйте, igor-booch, Вы писали:

S>>Я вам просто демонстрирую недостаток недоговоренности о значениях терминов.

IB>Я абсолютно согласен, что недостатки есть, предела совершенству нет.
IB>Еще чтобы более лояльно относиться к таким недостаткам можете посмотреть теорему Геделя о неполноте.
Теорема Геделя не оправдывает неформальное отношение к формальным терминам и формулировкам.

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

S>>http://en.wikipedia.org/wiki/Pure_function
S>>Я даю определения в очень редких случаях. Предпочитаю пользоваться общеупотребимыми и общедоступными, что бы люди меня понимали.
IB>В вашей ссылке написано, то что хорошо согласуется с тем, что пишу, замените только слово "state" (состояние) на слово "общедоступная переменная".
Нет, не очень хорошо. Очевидны разночтения с формулировкой из MS (здесь я противопоставил определение с википедии не вашему, а MS-шному).

S>>По вашему последнему дополнению к понятию общедоступной переменной — это общедоступный результат

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

IB>>>Если f2 и f3 грязные функции их вычисления можно запустить как псевдопараллельные.

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

S>>Ну так мы же еще не договорились, что считать контекстом!

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

IB>Да еще можно написать


IB>Тоже будет ссылаться на общедоступную переменную (GlobalFlag), но от ней результат функции зависеть не будет. Спасибо за наводку. Более точное определение чистой функции такое:

IB>логически редуцированная форма функции не ссылается на общедоступные переменные
Вот объясните, для чего вы это делаете? Чем вас не устраивает известное определение чистой функции, зачем надо изобретать обязательно свой велосипед? Это определение тоже неудачно. Можно написать функцию, которая не будет ссылаться на общедоступные переменные и будет недетерминирована и/или иметь побочные эффекты. и редукцию зачем-то прикрутили.

IB>>>Во первых управление потоком выполнения (flow control) и порядок выполнения (Order of execution) это разные вещи. В ФЯП аналоги if-then-else есть, называются сопоставления с образцом (pattern matching), но они не являются средствами управления потом выполнения.

S>>Да ладно? Не может быть! (это к разным предложениям)
IB>В http://msdn.microsoft.com/en-us/library/bb669144.aspx см. таблицу и строки в ней: Order of execution и Primary flow control
В первом случае я удивился очевидности, во втором — неочевидности. Извиняюсь за сумбурное изложение эмоций.
А разве вы не знаете что PM называют if-ом на стеройдах?

S>>Порядок выполнения важен — см. sin(x*x)

IB>В этом смысле важен. Функция не может быть выполнена пока не вычисленны все её аргументы
Ох, сколько у вас смыслов и контекстов этих смыслов...

IB>>>GOTO в ФП не обычно не держат, а вообще не держат.

IB>>>Циклы кстати реализуются через if и goto вверх (и вниз) по потоку выполнения.
S>>Раз так, то и вызов функции — тоже goto.
IB>Только этот goto может только компилятор ФЯП генерировать, а программисту при написании программы он недоступен в принципе.
Вот вот это "в принципе" — хотелось бы выяснить, откуда оно взято? То что вы не наблюдаете GOTO в функциональных языках — это ведь еще не повод рассуждать о принципах...
IB>В структурном программировании и ассемблерном goto доступен программисту.
Можно узнать, где это записано?
IB>См. Primary flow control это контроль не компилятором, а программистом.
дада. Программист контроллирует, где компилятор должен поставить goto.
Re[24]: Товарищам смеющимся и минусующим: псевдопараллеризм
От: igor-booch Россия  
Дата: 27.05.13 09:50
Оценка:
S> Ну так этот кто то должен иметь задачу и интерес оптимального решения этой задачи. Если ты задаешь такие вопросы то тебе и флаг в руки.
Мы все братья и сестры и должны помогать друг другу
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания
http://rsdn.ru/Info/rules.xml
Re[16]: Товарищам смеющимся и минусующим: псевдопараллеризм
От: samius Япония http://sams-tricks.blogspot.com
Дата: 27.05.13 09:51
Оценка:
Здравствуйте, igor-booch, Вы писали:

IB>>>Чистая функция не может ссылаться на общедоступные переменные, поэтому недетерминированность для неё невозможна в принципе. http://rsdn.ru/forum/dotnet/5180373.1
Автор: igor-booch
Дата: 25.05.13

S>>Нарушение причины и следствия. детерминированность — необходимое условие чистоты, а не наоборот. И если есть детерминированная функция без сайд-эффектов, ссылающаяся на общедоступные переменные, то она и будет чистой по определению. А то что чистая функция может быть недетерминированной — этого я не утвреждал.
IB>По моему нет нарушения. Возможно это
Автор: igor-booch
Дата: 25.05.13
прояснит ситуацию.

Нет не прояснит. Потому как там опять любимый ваш трюк — давать вещам альтернативные определения.

А детерминированность это отсутствие чтения из внешнего контекста.

Определение по википедии не запрещает чтения из внешнего контекста, а ваше — запрещает. Следовательно мы говорим о разных вещах и я вас не понимаю. Следовательно все что вы говорите о чистоте, ФП и более высоких материях — это нечто совсем другое, чем то, что подразумевают люди, использующие общеупотребимые определения.
Re[17]: Товарищам смеющимся и минусующим: псевдопараллеризм
От: samius Япония http://sams-tricks.blogspot.com
Дата: 27.05.13 09:53
Оценка:
Здравствуйте, igor-booch, Вы писали:

IB>Маленькое уточнение,

IB>В структурных языках программирования goto доступен, но goto отсутствует в парадигме структурного программирования (противоречит ей)
IB>В структурных языках программирования goto является как-бы возможностью перейти на более низкий уровень неструктурного программирования.
IB>В парадигме структурного программирования утверждается что все алгоритмы могут быть реализованы через условные конструкции и циклы, без goto
IB>Сами условные конструкции и циклы на низком уровне реализуются с помощью goto

Этот ликбез для меня?
Re[18]: Товарищам смеющимся и минусующим: псевдопараллеризм
От: samius Япония http://sams-tricks.blogspot.com
Дата: 27.05.13 09:55
Оценка:
Здравствуйте, igor-booch, Вы писали:

IB>А функциональном программировании пошли дальше и сказали, что все (почти все) алгоритмы можно записать только через вызовы (в т. ч. рекурсивные) функций (без условных конструкций и циклов).

IB>Но сейчас известны алгоритмы крепкие орешки, для которых есть структурная запись, но отсутствует функциональная.

Вы утверждаете что тезис Чёрча — Тьюринга опровергнут? Можно ссылочку на источник?
Re[18]: Товарищам смеющимся и минусующим: псевдопараллеризм
От: samius Япония http://sams-tricks.blogspot.com
Дата: 27.05.13 09:56
Оценка:
Здравствуйте, igor-booch, Вы писали:

IB>А функциональном программировании пошли дальше и сказали, что все (почти все) алгоритмы можно записать только через вызовы (в т. ч. рекурсивные) функций (без условных конструкций и циклов).

Да, вот еще что. Откуда следует что условных конструкций в ФП нет? Как вы будете останавливать рекурсию без условных конструкций?
Re[23]: Товарищам смеющимся и минусующим: псевдопараллеризм
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 27.05.13 09:59
Оценка:
Здравствуйте, igor-booch, Вы писали:
Да и внутри там

private class Node
{
    // Fields
    internal int m_hashcode;
    internal TKey m_key;
    internal volatile ConcurrentDictionary<TKey, TValue>.Node m_next;
    internal TValue m_value;

    // Methods
    internal Node(TKey key, TValue value, int hashcode, ConcurrentDictionary<TKey, TValue>.Node next);
}



А не 2 массива как в Dictionary
private int[] buckets;
private Entry<TKey, TValue>[] entries;

где

private struct Entry
{
    public int hashCode;
    public int next;
    public TKey key;
    public TValue value;
}


А вот со списками в Net особенно младших версий было, связанное со сборкой мусора при изменение ссылок в старших поколениях. Так как старшие поколения не учавствуют в сборке мусора, то изменения в их ссылках нужно регистрировать. http://www.rsdn.ru/forum/dotnet/415352.1
Автор: Serginio1
Дата: 20.10.03
и солнце б утром не вставало, когда бы не было меня
Re[17]: Товарищам смеющимся и минусующим: псевдопараллеризм
От: igor-booch Россия  
Дата: 27.05.13 10:07
Оценка:
Здравствуйте, samius, Вы писали:

S>Здравствуйте, igor-booch, Вы писали:


S>>>Я вам просто демонстрирую недостаток недоговоренности о значениях терминов.

IB>>Я абсолютно согласен, что недостатки есть, предела совершенству нет.
IB>>Еще чтобы более лояльно относиться к таким недостаткам можете посмотреть теорему Геделя о неполноте.
S>Теорема Геделя не оправдывает неформальное отношение к формальным терминам и формулировкам.
А судьи кто?


IB>>>>Если f2 и f3 грязные функции их вычисления можно запустить как псевдопараллельные.

S>>>Нет, нельзя, т.к. могут помешать друг другу получить ожидаемый результат.
IB>>А чтоб не мешали необходима синхронизация конкуррентного доступа к общим ресурсам (общедоступным переменным)
S>Синхронизация конкурентного доступа не гарантирует должный порядок для вызова грязных функций.
Поэтому я и написал "необходима", а не "достаточна". Компилятор конечно должен еще свое дело сделать.


S>Чем вас не устраивает известное определение чистой функции, зачем надо изобретать обязательно свой велосипед?

Всем устраивает, у меня просто другая форма этого определения. Кому то понятна одна форма кому другая. Главное чтобы содержание было одинаковым.


IB>>См. Primary flow control это контроль не компилятором, а программистом.

S>дада. Программист контроллирует, где компилятор должен поставить goto.
Структурное программирование дает программисту абстракцию над goto в виду условных структур и циклов: http://www.rsdn.ru/forum/dotnet/5181675.1
Автор: igor-booch
Дата: 27.05.13

Функциональное программирование даетпрограммисту абстракцию над условными структурами и циклами в виде лямбда исчисления: http://www.rsdn.ru/forum/dotnet/5181680.1
Автор: igor-booch
Дата: 27.05.13
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания
http://rsdn.ru/Info/rules.xml
Re[18]: Товарищам смеющимся и минусующим: псевдопараллеризм
От: igor-booch Россия  
Дата: 27.05.13 10:10
Оценка:
S>Этот ликбез для меня?

Не знаю, я в Вашей голове не копался.
Может новичок почитает эту дискуссию и для него это будет полезно.
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания
http://rsdn.ru/Info/rules.xml
Re[25]: Товарищам смеющимся и минусующим: псевдопараллеризм
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 27.05.13 10:13
Оценка:
Здравствуйте, igor-booch, Вы писали:

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

IB>Мы все братья и сестры и должны помогать друг другу

Кстати протестировать можно как подсчет слов из разных файлов из разных потоков на примере http://www.rsdn.ru/article/alg/tlsd.xml
Автор(ы): Сергей Смирнов (Serginio1)
Дата: 14.08.2004
Пример реализации двухуровневого массива с помощью нового средства С# — generics. Сравнение производительности различных реализаций сортированных списков.
и солнце б утром не вставало, когда бы не было меня
Re[19]: Товарищам смеющимся и минусующим: псевдопараллеризм
От: igor-booch Россия  
Дата: 27.05.13 10:39
Оценка: :)
S>Вы утверждаете что тезис Чёрча — Тьюринга опровергнут? Можно ссылочку на источник?

Уровень формализации нашей беседы не позволяет делать какие-либо выводы по данному вопросу. Но вопрос интересный попробую на него ответить.
Посмотрите отличие частично рекурсивных функций от общерекурсивных функций.
Функции вычислимые по Тюрингу являются частично рекурсивными.
Но не всякая частично рекурсивная функция является общерекурсивной.

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


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

Источник
https://ru.wikipedia.org/wiki/%D0%A0%D0%B5%D0%BA%D1%83%D1%80%D1%81%D0%B8%D0%B2%D0%BD%D0%B0%D1%8F_%D1%84%D1%83%D0%BD%D0%BA%D1%86%D0%B8%D1%8F_(%D1%82%D0%B5%D0%BE%D1%80%D0%B8%D1%8F_%D0%B2%D1%8B%D1%87%D0%B8%D1%81%D0%BB%D0%B8%D0%BC%D0%BE%D1%81%D1%82%D0%B8)#.D0.A7.D0.B0.D1.81.D1.82.D0.B8.D1.87.D0.BD.D0.BE_.D1.80.D0.B5.D0.BA.D1.83.D1.80.D1.81.D0.B8.D0.B2.D0.BD.D0.B0.D1.8F_.D1.84.D1.83.D0.BD.D0.BA.D1.86.D0.B8.D1.8F
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания
http://rsdn.ru/Info/rules.xml
Re[18]: Товарищам смеющимся и минусующим: псевдопараллеризм
От: samius Япония http://sams-tricks.blogspot.com
Дата: 27.05.13 10:42
Оценка:
Здравствуйте, igor-booch, Вы писали:

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


IB>>>Еще чтобы более лояльно относиться к таким недостаткам можете посмотреть теорему Геделя о неполноте.

S>>Теорема Геделя не оправдывает неформальное отношение к формальным терминам и формулировкам.
IB>А судьи кто?
В данном случае я. Я считаю что вы слишком вольно относитесь к формулировкам.

IB>>>А чтоб не мешали необходима синхронизация конкуррентного доступа к общим ресурсам (общедоступным переменным)

S>>Синхронизация конкурентного доступа не гарантирует должный порядок для вызова грязных функций.
IB>Поэтому я и написал "необходима", а не "достаточна". Компилятор конечно должен еще свое дело сделать.
И тоже ошиблись, т.к. необходимой она не является, что легко показать на примере.

S>>Чем вас не устраивает известное определение чистой функции, зачем надо изобретать обязательно свой велосипед?

IB>Всем устраивает, у меня просто другая форма этого определения. Кому то понятна одна форма кому другая. Главное чтобы содержание было одинаковым.
Разве вам не очевидно что и содержание различно, и классы чистых функций по википедии и по вам различны?

IB>>>См. Primary flow control это контроль не компилятором, а программистом.

S>>дада. Программист контроллирует, где компилятор должен поставить goto.
IB>Структурное программирование дает программисту абстракцию над goto в виду условных структур и циклов: http://www.rsdn.ru/forum/dotnet/5181675.1
Автор: igor-booch
Дата: 27.05.13

IB>Функциональное программирование даетпрограммисту абстракцию над условными структурами и циклами в виде лямбда исчисления: http://www.rsdn.ru/forum/dotnet/5181680.1
Автор: igor-booch
Дата: 27.05.13

Извините, параллель не уместна. Если структурный программист оперирует напрямую условными операторами и циклами, то ФП программист все-таки оперирует не лямбда исчислением, а условными структурами. Т.е. никто еще пока не сказал чтов if в ФП зло и что его надо везде выкинуть и пользоваться лямбдами вместо него.
Re[19]: Товарищам смеющимся и минусующим: псевдопараллеризм
От: samius Япония http://sams-tricks.blogspot.com
Дата: 27.05.13 10:43
Оценка:
Здравствуйте, igor-booch, Вы писали:

S>>Этот ликбез для меня?


IB>Не знаю, я в Вашей голове не копался.

IB>Может новичок почитает эту дискуссию и для него это будет полезно.
Вряд ли. Вы все время пытаетесь ввести свои определения, которые не эквивалентны. Новичкам будет вредно. Кстати, полагаю что вы как раз новичок
Да и я тоже. Только у меня непроходимость к вольным трактовкам.
Re[20]: Товарищам смеющимся и минусующим: псевдопараллеризм
От: igor-booch Россия  
Дата: 27.05.13 10:52
Оценка:
S>Вряд ли. Вы все время пытаетесь ввести свои определения, которые не эквивалентны. Новичкам будет вредно. Кстати, полагаю что вы как раз новичок
S>Да и я тоже. Только у меня непроходимость к вольным трактовкам.
Да, у меня вольные трактовки.
Невольные трактовки это математические формулы, теоремы и доказательства.
Да, если новичок осилит то, о чем я пишу на таком уровне, это будет для него более полезно.
Согласен с Вами.
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания
http://rsdn.ru/Info/rules.xml
Re[20]: Товарищам смеющимся и минусующим: псевдопараллеризм
От: samius Япония http://sams-tricks.blogspot.com
Дата: 27.05.13 10:53
Оценка:
Здравствуйте, igor-booch, Вы писали:

S>>Вы утверждаете что тезис Чёрча — Тьюринга опровергнут? Можно ссылочку на источник?


IB>Уровень формализации нашей беседы не позволяет делать какие-либо выводы по данному вопросу. Но вопрос интересный попробую на него ответить.

IB>Посмотрите отличие частично рекурсивных функций от общерекурсивных функций.
IB>Функции вычислимые по Тюрингу являются частично рекурсивными.
IB>Но не всякая частично рекурсивная функция является общерекурсивной.

IB>

IB>Задача определения того, является ли частично рекурсивная функция с данным описанием общерекурсивной или нет, алгоритмически неразрешима.


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


IB>Источник

IB>https://ru.wikipedia.org/wiki/%D0%A0%D0%B5%D0%BA%D1%83%D1%80%D1%81%D0%B8%D0%B2%D0%BD%D0%B0%D1%8F_%D1%84%D1%83%D0%BD%D0%BA%D1%86%D0%B8%D1%8F_(%D1%82%D0%B5%D0%BE%D1%80%D0%B8%D1%8F_%D0%B2%D1%8B%D1%87%D0%B8%D1%81%D0%BB%D0%B8%D0%BC%D0%BE%D1%81%D1%82%D0%B8)#.D0.A7.D0.B0.D1.81.D1.82.D0.B8.D1.87.D0.BD.D0.BE_.D1.80.D0.B5.D0.BA.D1.83.D1.80.D1.81.D0.B8.D0.B2.D0.BD.D0.B0.D1.8F_.D1.84.D1.83.D0.BD.D0.BA.D1.86.D0.B8.D1.8F
Вы все куда-то хотите в сторону вильнуть. А что, функциональное программирование это программирование на общерекурсивных функциях?
Тезис Черча-Тьюринга — он именно о лямбда исчислении. А ФП построено именно на нем.
Re[21]: Товарищам смеющимся и минусующим: псевдопараллеризм
От: samius Япония http://sams-tricks.blogspot.com
Дата: 27.05.13 10:53
Оценка:
Здравствуйте, igor-booch, Вы писали:

IB>Да, у меня вольные трактовки.

IB>Невольные трактовки это математические формулы, теоремы и доказательства.
IB>Да, если новичок осилит то, о чем я пишу на таком уровне, это будет для него более полезно.
IB>Согласен с Вами.
Если осилит, в чем вы не правы со своими трактовками — то да, будет полезно.
Re[21]: Товарищам смеющимся и минусующим: псевдопараллеризм
От: igor-booch Россия  
Дата: 27.05.13 11:01
Оценка:
S> А что, функциональное программирование это программирование на общерекурсивных функциях?
Интересно было бы исследовать эту гипотезу более обстоятельно.
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания
http://rsdn.ru/Info/rules.xml
Re[22]: Товарищам смеющимся и минусующим: псевдопараллеризм
От: igor-booch Россия  
Дата: 27.05.13 11:09
Оценка:
IB>>Да, у меня вольные трактовки.
IB>>Невольные трактовки это математические формулы, теоремы и доказательства.
IB>>Да, если новичок осилит то, о чем я пишу на таком уровне, это будет для него более полезно.
IB>>Согласен с Вами.
S>Если осилит, в чем вы не правы со своими трактовками — то да, будет полезно.

Буду только рад за такого человека, если он формализует, то о чем я говорю и формально докажет противоречивость моих утверждений.
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания
http://rsdn.ru/Info/rules.xml
Re[22]: Товарищам смеющимся и минусующим: псевдопараллеризм
От: samius Япония http://sams-tricks.blogspot.com
Дата: 27.05.13 11:09
Оценка: -1
Здравствуйте, igor-booch, Вы писали:

S>> А что, функциональное программирование это программирование на общерекурсивных функциях?

IB>Интересно было бы исследовать эту гипотезу более обстоятельно.
Это не гипотеза а ирония
Re[23]: Товарищам смеющимся и минусующим: псевдопараллеризм
От: samius Япония http://sams-tricks.blogspot.com
Дата: 27.05.13 11:10
Оценка:
Здравствуйте, igor-booch, Вы писали:

IB>Буду только рад за такого человека, если он формализует, то о чем я говорю и формально докажет противоречивость моих утверждений.

Я уже доказал и привел вам доказательства
Re[24]: Товарищам смеющимся и минусующим: псевдопараллеризм
От: igor-booch Россия  
Дата: 27.05.13 11:20
Оценка:
IB>>Буду только рад за такого человека, если он формализует, то о чем я говорю и формально докажет противоречивость моих утверждений.
S>Я уже доказал и привел вам доказательства

Вы наверное имели ввиду доказательства как строгий математический термин.
Если так, то Вы не могли это сделать, так как я давал свои утверждения в неформализованном виде.
Если не так, то я принимаю Ваше мнение.
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания
http://rsdn.ru/Info/rules.xml
Re[19]: Товарищам смеющимся и минусующим: псевдопараллеризм
От: igor-booch Россия  
Дата: 27.05.13 11:24
Оценка:
S>Т.е. никто еще пока не сказал чтов if в ФП зло и что его надо везде выкинуть и пользоваться лямбдами вместо него.
if как инструмент управления потоком исполнения (flow conrol) присутствует только в нечистых функциональных ЯП. Например F#.
Нечистые ФЯП допускают нечистые функции.
В чистых ФЯП if как инструмент управления потоком исполнения отсутствует.
Кстати по поводу потока исполнения в ФП:


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


http://ru.wikipedia.org/wiki/%D0%A4%D1%83%D0%BD%D0%BA%D1%86%D0%B8%D0%BE%D0%BD%D0%B0%D0%BB%D1%8C%D0%BD%D0%BE%D0%B5_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5

Под нестрогой моделью вычислений здесь понимаются ленивые вычисления.

f = f1(f2(x), f3(x))
Здесь два вычисления f2(x) и f3(x) можно запустить как две параллельные задачи, если f2 и f3 чистые функции.

Какая из функций вычистится первой f2(x) или f3(x) неизвестно.
Любая из функция f2(x) и f3(x) может быть вообще никогда не вычислена, если её значение не потребуется для f1
Ленивые вычисления лежат в основе ФП.
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания
http://rsdn.ru/Info/rules.xml
Re[25]: Товарищам смеющимся и минусующим: псевдопараллеризм
От: samius Япония http://sams-tricks.blogspot.com
Дата: 27.05.13 11:27
Оценка: -1
Здравствуйте, igor-booch, Вы писали:

IB>>>Буду только рад за такого человека, если он формализует, то о чем я говорю и формально докажет противоречивость моих утверждений.

S>>Я уже доказал и привел вам доказательства

IB>Вы наверное имели ввиду доказательства как строгий математический термин.

Причем тут математическая строгость? Если я беру две формулировки и показываю разницу между ними на конкретных примерах. Тут хоть строго, хоть не строго, разница есть и от строгости или мягкости она никуда не пропадает.
IB>Если так, то Вы не могли это сделать, так как я давал свои утверждения в неформализованном виде.
Не важно, в каком виде вы их даете. Они не выполняются.
IB>Если не так, то я принимаю Ваше мнение.
Re[17]: Товарищам смеющимся и минусующим: псевдопараллеризм
От: igor-booch Россия  
Дата: 27.05.13 11:30
Оценка:
S>Определение по википедии не запрещает чтения из внешнего контекста, а ваше — запрещает.

Интересно, приведите, пожалуйста, цитату из википедии
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания
http://rsdn.ru/Info/rules.xml
Re[20]: Товарищам смеющимся и минусующим: псевдопараллеризм
От: samius Япония http://sams-tricks.blogspot.com
Дата: 27.05.13 11:33
Оценка:
Здравствуйте, igor-booch, Вы писали:

S>>Т.е. никто еще пока не сказал чтов if в ФП зло и что его надо везде выкинуть и пользоваться лямбдами вместо него.

IB>if как инструмент управления потоком исполнения (flow conrol) присутствует только в нечистых функциональных ЯП. Например F#.
А разве в хаскелле if отменили?
IB>Нечистые ФЯП допускают нечистые функции.
Очевидно
IB>В чистых ФЯП if как инструмент управления потоком исполнения отсутствует.
Хаскелль
IB>Кстати по поводу потока исполнения в ФП:

IB>

IB>Нестрогая модель вычислений приводит к непредсказуемому порядку вызова функций, что создает проблемы при вводе-выводе, где порядок выполнения операций важен.


IB>http://ru.wikipedia.org/wiki/%D0%A4%D1%83%D0%BD%D0%BA%D1%86%D0%B8%D0%BE%D0%BD%D0%B0%D0%BB%D1%8C%D0%BD%D0%BE%D0%B5_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5


IB>Под нестрогой моделью вычислений здесь понимаются ленивые вычисления.

Ох, любите вы менять темы. Причем тут проблемы при вводе-выводе?

IB>f = f1(f2(x), f3(x))

IB>Здесь два вычисления f2(x) и f3(x) можно запустить как две параллельные задачи, если f2 и f3 чистые функции.
можно

IB>Какая из функций вычистится первой f2(x) или f3(x) неизвестно.

IB>Любая из функция f2(x) и f3(x) может быть вообще никогда не вычислена, если её значение не потребуется для f1
IB>Ленивые вычисления лежат в основе ФП.
это, конечно интересно, только это очевидно даже для структурного программирования.
Re[18]: Товарищам смеющимся и минусующим: псевдопараллеризм
От: samius Япония http://sams-tricks.blogspot.com
Дата: 27.05.13 11:35
Оценка:
Здравствуйте, igor-booch, Вы писали:

S>>Определение по википедии не запрещает чтения из внешнего контекста, а ваше — запрещает.


IB>Интересно, приведите, пожалуйста, цитату из википедии

пожалуйста

In computer programming, a function may be described as pure if both these statements about the function hold:
1. The function always evaluates the same result value given the same argument value(s). The function result value cannot depend on any hidden information or state that may change as program execution proceeds or between different executions of the program, nor can it depend on any external input from I/O devices.
2. Evaluation of the result does not cause any semantically observable side effect or output, such as mutation of mutable objects or output to I/O devices.

Я здесь не вижу запрета на чтение из внешнего контекста. Если вы видите, то выделите его для меня.
Re[17]: Товарищам смеющимся и минусующим: псевдопараллеризм
От: igor-booch Россия  
Дата: 27.05.13 11:38
Оценка: -1
S>это нечто совсем другое, чем то, что подразумевают люди, использующие общеупотребимые определения.
Общеупотребимость определения понятие растяжимое, отностиельное и субъективное.
Единственное что может претендовать на неоспоримую общеупотребимость это формализованные утверждения в виде математических формул и теорем.
Я на такую общеупотребимость не претендую.
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания
http://rsdn.ru/Info/rules.xml
Re[18]: Товарищам смеющимся и минусующим: псевдопараллеризм
От: samius Япония http://sams-tricks.blogspot.com
Дата: 27.05.13 11:40
Оценка:
Здравствуйте, igor-booch, Вы писали:

S>>это нечто совсем другое, чем то, что подразумевают люди, использующие общеупотребимые определения.

IB>Общеупотребимость определения понятие растяжимое, отностиельное и субъективное.
IB>Единственное что может претендовать на неоспоримую общеупотребимость это формализованные утверждения в виде математических формул и теорем.
IB>Я на такую общеупотребимость не претендую.
А на то что вас будут понимать люди вы претендуете? Еще раз. Вы подразумеваете одно, а люди — другое. Как вы собираетесь договариваться?
Re[21]: Товарищам смеющимся и минусующим: псевдопараллеризм
От: igor-booch Россия  
Дата: 27.05.13 11:47
Оценка:
S>>>Т.е. никто еще пока не сказал чтов if в ФП зло и что его надо везде выкинуть и пользоваться лямбдами вместо него.
IB>>if как инструмент управления потоком исполнения (flow conrol) присутствует только в нечистых функциональных ЯП. Например F#.
S>А разве в хаскелле if отменили?
if в хаскеле это функция, такая же как и все остальные функции, например, map, а не инструмент управления потоком исполнения (flow control) как императивных языках

IB>>Под нестрогой моделью вычислений здесь понимаются ленивые вычисления.

S>Ох, любите вы менять темы. Причем тут проблемы при вводе-выводе?
это как пример дан,
функция Console.ReadLine ни при каких условиях не является дитерминированной (пользователь может ввести все-что угодно), поэтому не является чистой, а все остальные функции, которые её вызывают тоже становятся нечистыми.


IB>>Какая из функций вычистится первой f2(x) или f3(x) неизвестно.

IB>>Любая из функция f2(x) и f3(x) может быть вообще никогда не вычислена, если её значение не потребуется для f1
IB>>Ленивые вычисления лежат в основе ФП.
S>это, конечно интересно, только это очевидно даже для структурного программирования.
согласен очевидно
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания
http://rsdn.ru/Info/rules.xml
Re[19]: Товарищам смеющимся и минусующим: псевдопараллеризм
От: igor-booch Россия  
Дата: 27.05.13 11:51
Оценка: :)
IB>>Интересно, приведите, пожалуйста, цитату из википедии
S>пожалуйста
S>

S>In computer programming, a function may be described as pure if both these statements about the function hold:
S> 1. The function always evaluates the same result value given the same argument value(s). The function result value cannot depend on any hidden information or state that may change as program execution proceeds or between different executions of the program, nor can it depend on any external input from I/O devices.
S> 2. Evaluation of the result does not cause any semantically observable side effect or output, such as mutation of mutable objects or output to I/O devices.

S>Я здесь не вижу запрета на чтение из внешнего контекста. Если вы видите, то выделите его для меня.

Выделил,
уберите слово "контекст" из моих рассуждений и замените его на "состояние" (state), смысл останется тем же.
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания
http://rsdn.ru/Info/rules.xml
Re[19]: Товарищам смеющимся и минусующим: псевдопараллеризм
От: igor-booch Россия  
Дата: 27.05.13 11:54
Оценка: :)
S>А на то что вас будут понимать люди вы претендуете? Еще раз. Вы подразумеваете одно, а люди — другое. Как вы собираетесь договариваться?
То что Вам не понятны мои утверждения я уяснил,
То что по Вашему мнению другим людям не будут понятны мои утверждения я тоже уяснил.
Но я искренне и по человечески надеюсь что кто-то найдет для себя полезное в моих словах.
Я так же искренне понимаю, что возможно я ошибаюсь.
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания
http://rsdn.ru/Info/rules.xml
Re[22]: Товарищам смеющимся и минусующим: псевдопараллеризм
От: samius Япония http://sams-tricks.blogspot.com
Дата: 27.05.13 11:59
Оценка:
Здравствуйте, igor-booch, Вы писали:

IB>>>if как инструмент управления потоком исполнения (flow conrol) присутствует только в нечистых функциональных ЯП. Например F#.

S>>А разве в хаскелле if отменили?
IB>if в хаскеле это функция, такая же как и все остальные функции, например, map, а не инструмент управления потоком исполнения (flow control) как императивных языках
Ошибаетесь. if в хаскеле мог бы быть объявлен как функция но лишь за счет природы PM и ленивости. А PM в хаскеле является именно инструментом управления flow control как if в императивных языках. Только круче. Не важно, как объявлен if в хаскеле, важно что flow control рулится паттерн-матчингом на ура.

IB>>>Под нестрогой моделью вычислений здесь понимаются ленивые вычисления.

S>>Ох, любите вы менять темы. Причем тут проблемы при вводе-выводе?
IB>это как пример дан,
IB>функция Console.ReadLine ни при каких условиях не является дитерминированной (пользователь может ввести все-что угодно), поэтому не является чистой, а все остальные функции, которые её вызывают тоже становятся нечистыми.
Это понятно, так к чему вы сменили тему?
Re[20]: Товарищам смеющимся и минусующим: псевдопараллеризм
От: samius Япония http://sams-tricks.blogspot.com
Дата: 27.05.13 12:01
Оценка:
Здравствуйте, igor-booch, Вы писали:

IB>>>Интересно, приведите, пожалуйста, цитату из википедии

S>>пожалуйста
S>>

S>>In computer programming, a function may be described as pure if both these statements about the function hold:
S>> 1. The function always evaluates the same result value given the same argument value(s). The function result value cannot depend on any hidden information or state that may change as program execution proceeds or between different executions of the program, nor can it depend on any external input from I/O devices.
S>> 2. Evaluation of the result does not cause any semantically observable side effect or output, such as mutation of mutable objects or output to I/O devices.

S>>Я здесь не вижу запрета на чтение из внешнего контекста. Если вы видите, то выделите его для меня.

IB>Выделил,

Спасибо. Но вы выделили не запрет на чтение, а запрет на зависимость результата от состояния.
IB>уберите слово "контекст" из моих рассуждений и замените его на "состояние" (state), смысл останется тем же.
Нет. Ведь вы запрещаете взаимодействие с контекстом, а определение на википедии запрещает зависимость результата от него.
Re[20]: Товарищам смеющимся и минусующим: псевдопараллеризм
От: samius Япония http://sams-tricks.blogspot.com
Дата: 27.05.13 12:05
Оценка:
Здравствуйте, igor-booch, Вы писали:

S>>А на то что вас будут понимать люди вы претендуете? Еще раз. Вы подразумеваете одно, а люди — другое. Как вы собираетесь договариваться?

IB>То что Вам не понятны мои утверждения я уяснил,
Это не совсем так. Какие-то непонятны, а те что понятны — я вижу их расхождение с общедоступными формулировками.
IB>То что по Вашему мнению другим людям не будут понятны мои утверждения я тоже уяснил.
IB>Но я искренне и по человечески надеюсь что кто-то найдет для себя полезное в моих словах.
А я искренне не понимаю, ваше нежелание относиться к формулировкам более формально. Зачем их все время перевыдумывать и надеяться на понимание, если можно оперировать существующими до вас?
IB>Я так же искренне понимаю, что возможно я ошибаюсь.
Рад.
Re[23]: Товарищам смеющимся и минусующим: псевдопараллеризм
От: igor-booch Россия  
Дата: 27.05.13 12:05
Оценка:
S>Ошибаетесь. if в хаскеле мог бы быть объявлен как функция но лишь за счет природы PM и ленивости. А PM в хаскеле является именно инструментом управления flow control как if в императивных языках. Только круче. Не важно, как объявлен if в хаскеле, важно что flow control рулится паттерн-матчингом на ура.
if в хаскеле не мог бы объявлен как функция, а он объявлен как функция.


The advantages of the function if'


http://www.haskell.org/haskellwiki/If-then-else

Причем эта функция даже не входит в базовый пакет Haskell Prelude:

Unfortunately there is no such function in the Prelude.

Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания
http://rsdn.ru/Info/rules.xml
Re[24]: Товарищам смеющимся и минусующим: псевдопараллеризм
От: samius Япония http://sams-tricks.blogspot.com
Дата: 27.05.13 12:13
Оценка:
Здравствуйте, igor-booch, Вы писали:

S>>Ошибаетесь. if в хаскеле мог бы быть объявлен как функция но лишь за счет природы PM и ленивости. А PM в хаскеле является именно инструментом управления flow control как if в императивных языках. Только круче. Не важно, как объявлен if в хаскеле, важно что flow control рулится паттерн-матчингом на ура.

IB>if в хаскеле не мог бы объявлен как функция, а он объявлен как функция.
Откуда это следует?

IB>

IB>The advantages of the function if'


IB>http://www.haskell.org/haskellwiki/If-then-else


IB>Причем эта функция даже не входит в базовый пакет Haskell Prelude:


IB>

IB>Unfortunately there is no such function in the Prelude.

Действительно не входит. Но раз функции нет, но if-then-else в Prelude используется, то наверное это все-таки не функция?
Re[21]: Товарищам смеющимся и минусующим: псевдопараллеризм
От: igor-booch Россия  
Дата: 27.05.13 12:21
Оценка: :)
S>Нет. Ведь вы запрещаете взаимодействие с контекстом, а определение на википедии запрещает зависимость результата от него.

А взаимодействие зачем может быть кроме как для формирования результата? Я вам уже отвечал
Я бы не усложнял и не разделял слова взаимодействие и зависимость.
Хотя взаимодействие подразумевает двустороннюю зависимость.
Поэтому могу сейчас уточнить.
Грязная функция зависит от (ссылается на) состояния (контекста, общедоступное переменной),
но состояние не зависит (не ссылается) не на одну из грязных функций.
То есть мы можем ссылаться на ресурс, но ресурс на нас ссылаться не может.
То есть зависимость односторонняя: от функции к состоянию, но не наоборот.
Спасибо за наводку. Может поможет мне где нибудь.

Посмотрите так же http://rsdn.ru/forum/dotnet/5181563.1
Автор: igor-booch
Дата: 27.05.13

про Вашу функцию Quote(string v)
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания
http://rsdn.ru/Info/rules.xml
Re[21]: Товарищам смеющимся и минусующим: псевдопараллеризм
От: igor-booch Россия  
Дата: 27.05.13 12:24
Оценка:
S>А я искренне не понимаю, ваше нежелание относиться к формулировкам более формально.
Такое желание есть, только на этом форуме никто не общается на языке математических формул и теорем.
Хотя возможно было бы полезно.
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания
http://rsdn.ru/Info/rules.xml
Re[25]: Товарищам смеющимся и минусующим: псевдопараллеризм
От: igor-booch Россия  
Дата: 27.05.13 12:26
Оценка:
IB>>

IB>>Unfortunately there is no such function in the Prelude.

S>Действительно не входит. Но раз функции нет, но if-then-else в Prelude используется, то наверное это все-таки не функция?

В Prelude она как раз не входит. Выделил.


S>Откуда это следует?


IB>>

IB>>The advantages of the function if'

Выделено.
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания
http://rsdn.ru/Info/rules.xml
Re[22]: Товарищам смеющимся и минусующим: псевдопараллеризм
От: samius Япония http://sams-tricks.blogspot.com
Дата: 27.05.13 12:27
Оценка:
Здравствуйте, igor-booch, Вы писали:

S>>Нет. Ведь вы запрещаете взаимодействие с контекстом, а определение на википедии запрещает зависимость результата от него.


IB>А взаимодействие зачем может быть кроме как для формирования результата? Я вам уже отвечал

IB>Я бы не усложнял и не разделял слова взаимодействие и зависимость.
Если бы вы не хотели все усложнить, пользовались бы определением из википедии. Но вы именно что усложняете.

IB>Хотя взаимодействие подразумевает двустороннюю зависимость.

IB>Поэтому могу сейчас уточнить.
IB>Грязная функция зависит от (ссылается на) состояния (контекста, общедоступное переменной),
Это уже можно опроевргнуть, предоставив грязную функцию, не ссылающуюся на контекст. Такую можно легко предоставить, если подумать.
IB>но состояние не зависит (не ссылается) не на одну из грязных функций.
IB>То есть мы можем ссылаться на ресурс, но ресурс на нас ссылаться не может.
IB>То есть зависимость односторонняя: от функции к состоянию, но не наоборот.
Вот тут я уже не понимаю. Состояние не зависит от грязных функций? Еще как зависит. Грязные функции его как раз и портят.
IB>Спасибо за наводку. Может поможет мне где нибудь.


IB>Посмотрите так же http://rsdn.ru/forum/dotnet/5181563.1
Автор: igor-booch
Дата: 27.05.13

IB>про Вашу функцию Quote(string v)
Видел, она все еще грязная по вашему определению. Редуцировать вы сможете if globalvar == globalvar, но не if globalvar == 1.
Re[26]: Товарищам смеющимся и минусующим: псевдопараллеризм
От: samius Япония http://sams-tricks.blogspot.com
Дата: 27.05.13 12:30
Оценка:
Здравствуйте, igor-booch, Вы писали:

IB>>>

IB>>>Unfortunately there is no such function in the Prelude.

S>>Действительно не входит. Но раз функции нет, но if-then-else в Prelude используется, то наверное это все-таки не функция?

IB>В Prelude она как раз не входит. Выделил.

А я вам выделяю то что в Prelude она не входит, но if-then-else в прелюде активно используется. И это указывает на то что if- не функция.


S>>Откуда это следует?


IB>>>

IB>>>The advantages of the function if'

IB>Выделено.
ну вы выделили function, но почему-то упускаете что это function if', а не function if.

И еще. Если бы if была действительно функцией, то нафига бы тогда компилятор заставлял бы писать then и else слова? Попробуйте напишите без них.
Re[3]: ConcurrentDictionary не дает выгоды в производительности
От: vvlad.net  
Дата: 27.05.13 12:50
Оценка: -1
Здравствуйте, igor-booch, Вы писали:

0>>Тест не корректен: при тестировании параллельного кода в замеры времени попадает создание потоков.

IB>Если тест служит для выбора между одно поточной реализацией и многопоточной, то все корректно: создание потоков это издержки многопоточной реализации

Неверно — при многопоточной реализации время создание потоков не учитывается — используется пул потоков. А создание потока — дорогая операция.
Re[23]: Товарищам смеющимся и минусующим: псевдопараллеризм
От: igor-booch Россия  
Дата: 27.05.13 12:52
Оценка:
IB>>но состояние не зависит (не ссылается) не на одну из грязных функций.
IB>>То есть мы можем ссылаться на ресурс, но ресурс на нас ссылаться не может.
IB>>То есть зависимость односторонняя: от функции к состоянию, но не наоборот.
S>Вот тут я уже не понимаю. Состояние не зависит от грязных функций? Еще как зависит. Грязные функции его как раз и портят.
IB>>Спасибо за наводку. Может поможет мне где нибудь.
S>

Я же написал, что здесь "зависит" употреблено в смысле "ссылается на".
Вы понимаете что такое зависимость между проектами в Visual Studio?
Вот здесь такая же зависимость.

IB>>Посмотрите так же http://rsdn.ru/forum/dotnet/5181563.1
Автор: igor-booch
Дата: 27.05.13

IB>>про Вашу функцию Quote(string v)
S>Видел, она все еще грязная по вашему определению. Редуцировать вы сможете if globalvar == globalvar, но не if globalvar == 1.

Там где у Вас if globalvar == 1


string Quote(string v)
{
return (GlobalFlag == 1)
? "\"" + v + "\""
: String.Format("\"{0}\"", v);
}


В независимости от значения globalvar, происходят действия с одинаковым результатом.
Это тоже поддается редукции, возможно даже компилятором.
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания
http://rsdn.ru/Info/rules.xml
Re[27]: Товарищам смеющимся и минусующим: псевдопараллеризм
От: igor-booch Россия  
Дата: 27.05.13 12:58
Оценка:
S>А я вам выделяю то что в Prelude она не входит, но if-then-else в прелюде активно используется. И это указывает на то что if- не функция.
S>И еще. Если бы if была действительно функцией, то нафига бы тогда компилятор заставлял бы писать then и else слова? Попробуйте напишите без них.

Интересно, дайте ссылку на документацию на if как не функцию в Haskell.
Может Вы имеете ввиду сопоставление с образцом (pattern matching)?
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания
http://rsdn.ru/Info/rules.xml
Re[24]: Товарищам смеющимся и минусующим: псевдопараллеризм
От: samius Япония http://sams-tricks.blogspot.com
Дата: 27.05.13 13:13
Оценка: -1
Здравствуйте, igor-booch, Вы писали:

IB>>>То есть зависимость односторонняя: от функции к состоянию, но не наоборот.

S>>Вот тут я уже не понимаю. Состояние не зависит от грязных функций? Еще как зависит. Грязные функции его как раз и портят.
IB>>>Спасибо за наводку. Может поможет мне где нибудь.
S>>

IB>Я же написал, что здесь "зависит" употреблено в смысле "ссылается на".

IB>Вы понимаете что такое зависимость между проектами в Visual Studio?
Понимаю
IB>Вот здесь такая же зависимость.
Не понимаю


IB>>>Посмотрите так же http://rsdn.ru/forum/dotnet/5181563.1
Автор: igor-booch
Дата: 27.05.13

IB>>>про Вашу функцию Quote(string v)
S>>Видел, она все еще грязная по вашему определению. Редуцировать вы сможете if globalvar == globalvar, но не if globalvar == 1.

IB>Там где у Вас if globalvar == 1


IB>

IB>string Quote(string v)
IB>{
IB> return (GlobalFlag == 1)
IB> ? "\"" + v + "\""
IB> : String.Format("\"{0}\"", v);
IB>}

да

IB>В независимости от значения globalvar, происходят действия с одинаковым результатом.

именно
IB>Это тоже поддается редукции, возможно даже компилятором.
Вот видите, как вы все усложняете. Ваши формулировки работают в зависимости от того, будет ли компилятор или не будет редуцировать то, чего он доказать не может. А формулировка из википедии работает как часы без отсылки к возможностям компилятора.
Re[28]: Товарищам смеющимся и минусующим: псевдопараллеризм
От: samius Япония http://sams-tricks.blogspot.com
Дата: 27.05.13 13:20
Оценка:
Здравствуйте, igor-booch, Вы писали:

S>>А я вам выделяю то что в Prelude она не входит, но if-then-else в прелюде активно используется. И это указывает на то что if- не функция.

S>>И еще. Если бы if была действительно функцией, то нафига бы тогда компилятор заставлял бы писать then и else слова? Попробуйте напишите без них.

IB>Интересно, дайте ссылку на документацию на if как не функцию в Haskell.

Интересно только тем что вы опять поторопились с выводами. Ссылки у меня такой нет. А то что вы приводили — так это ссылка не на документацию if, а ссылка на то, чем было бы хорошо или плохо иметь функцию if', которой в прелюде все-таки нет. Понимаете, там не написано что if-then-else это функция. Там написано лишь что синтаксическая форма if-then-esle могла бы быть ей. Но она ей не является фактически. И на это указывают некоторые рассуждения: обязательность then-else и отсутствие объявления такой функции в prelude. В Prelude нет не только if', о котором написано в вики. Там и if-then-else не описан, но употребляется.

IB>Может Вы имеете ввиду сопоставление с образцом (pattern matching)?

Нет конечно. Я имею в виду if-then-else. Об этом так же намекает то что я попросил вас записать if без then и else.
Re[29]: Товарищам смеющимся и минусующим: псевдопараллеризм
От: igor-booch Россия  
Дата: 27.05.13 13:28
Оценка:
IB>>Интересно, дайте ссылку на документацию на if как не функцию в Haskell.
S>Интересно только тем что вы опять поторопились с выводами. Ссылки у меня такой нет.

А я нашел http://en.wikibooks.org/wiki/Haskell/Control_structures

Только

Note that in Haskell if is an expression (which is converted to a value) – and not a statement (which is executed) like in many imperative languages

и

If you programmed in C or Java, you will recognize Haskell's if/then/else as an equivalent to the ternary conditional operator ?

Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания
http://rsdn.ru/Info/rules.xml
Re[30]: Товарищам смеющимся и минусующим: псевдопараллеризм
От: samius Япония http://sams-tricks.blogspot.com
Дата: 27.05.13 13:30
Оценка:
Здравствуйте, igor-booch, Вы писали:

IB>>>Интересно, дайте ссылку на документацию на if как не функцию в Haskell.

S>>Интересно только тем что вы опять поторопились с выводами. Ссылки у меня такой нет.

IB>А я нашел http://en.wikibooks.org/wiki/Haskell/Control_structures


IB>Только

IB>

IB>Note that in Haskell if is an expression (which is converted to a value) – and not a statement (which is executed) like in many imperative languages

IB>и

IB>

IB>If you programmed in C or Java, you will recognize Haskell's if/then/else as an equivalent to the ternary conditional operator ?

Так это все не новость во-первых, а во-вторых прямо не указывает на то что if не функция.
Re[31]: Товарищам смеющимся и минусующим: псевдопараллеризм
От: igor-booch Россия  
Дата: 27.05.13 14:19
Оценка:
Здравствуйте, samius, Вы писали:

S>Здравствуйте, igor-booch, Вы писали:


IB>>>>Интересно, дайте ссылку на документацию на if как не функцию в Haskell.

S>>>Интересно только тем что вы опять поторопились с выводами. Ссылки у меня такой нет.

IB>>А я нашел http://en.wikibooks.org/wiki/Haskell/Control_structures


IB>>Только

IB>>

IB>>Note that in Haskell if is an expression (which is converted to a value) – and not a statement (which is executed) like in many imperative languages

IB>>и

IB>>

IB>>If you programmed in C or Java, you will recognize Haskell's if/then/else as an equivalent to the ternary conditional operator ?

S>Так это все не новость во-первых, а во-вторых прямо не указывает на то что if не функция.

То что есть if не функция не знал.
Я знал только про охранные выражения и сопоставления с образцом, которые взаимозаменяемы с Haskell if.

Guards and top-level if expressions are mostly interchangeable



Но чем отличается выражение (expression) от инструкции (statement)?
Не зря в C# и других императивных языках программирования наряду с if есть тернарный оператор "?"
Смотрим документацию по оператору ? в C#

condition ? first_expression : second_expression;


Смотрим теперь документация по if-else в C#:

if (expression)
statement1
[else
statement2]


Видите опять различается expression и statement.

Разница в том, что в expression вы не можете применять if (или for), то есть операторы контролирующие поток выполнения, то есть statement. И тернарная конструкция сама по себе тоже является expression, а не statement. Это ограничение дает возможность компилятору императивного языка делать оптимизации. Я очень удивлюсь если Вы найдете в Haskell if, в котором участвует statement, а не expression. Вот это будет новость, которая опровергнет то, о чем я Вам давно говорю

что в функциональном программировании нет условных конструкций, как средств управления потоком выполнения.



Кстати функция в Haskell тоже является выражением (expression), со всеми вытекающими последствиями.
А в императивном языке функция это подпрограмма (множество statement).
Надеюсь это поможет Вам меня понять.
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания
http://rsdn.ru/Info/rules.xml
Re[32]: Товарищам смеющимся и минусующим: псевдопараллеризм
От: samius Япония http://sams-tricks.blogspot.com
Дата: 27.05.13 14:32
Оценка:
Здравствуйте, igor-booch, Вы писали:

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


S>>Так это все не новость во-первых, а во-вторых прямо не указывает на то что if не функция.


IB>То что есть if не функция не знал.

ну как же? Вот if-then-else и есть не функция.
IB>Я знал только про охранные выражения и сопоставления с образцом, которые взаимозаменяемы с Haskell if.

IB>

IB>Guards and top-level if expressions are mostly interchangeable


IB>Но чем отличается выражение (expression) от инструкции (statement)?

выражение возвращает значение. Statement- гадит в окружение, иначе не нужен вообще.
IB>Не зря в C# и других императивных языках программирования наряду с if есть тернарный оператор "?"
IB>Смотрим документацию по оператору ? в C#
Конечно не зря

IB>

IB>condition ? first_expression : second_expression;


IB>Смотрим теперь документация по if-else в C#:


IB>

IB>if (expression)
IB> statement1
IB>[else
IB> statement2]


IB>Видите опять различается expression и statement.

Вижу.

IB>Разница в том, что в expression вы не можете применять if (или for), то есть операторы контролирующие поток выполнения, то есть statement.

конечно, применять в expression то, что не возвращает значения? Вот если бы if и for (statement-ы) могли возвращать значения, то никаких бы проблем в применении их внутри выражения не было бы.

IB>И тернарная конструкция сама по себе тоже является expression, а не statement. Это ограничение дает возможность компилятору императивного языка делать оптимизации. Я очень удивлюсь если Вы найдете в Haskell if, в котором участвует statement, а не expression. Вот это будет новость, которая опровергнет то, о чем я Вам давно говорю

Вы мне давно говорили что if — функция, но оказалось что это не так, теперь вы метнулись в сторону обсуждения expression vs statement.

IB>

IB>что в функциональном программировании нет условных конструкций, как средств управления потоком выполнения.

Ну как же? А if-then-else это не условная конструкция, или она не управляет потоком?

IB>Кстати функция в Haskell тоже является выражением (expression), со всеми вытекающими последствиями.

нет, не является
foo = 2 * (<определите пожалуйста функцию прямо здесь>)
IB>А в императивном языке функция это подпрограмма (множество statement).
Мне непонятен ваш переход от подпрограммы к statement-у. Подпрограмме не запрещено быть выражением.
IB>Надеюсь это поможет Вам меня понять.
Не помогло.
Re[33]: Товарищам смеющимся и минусующим: псевдопараллеризм
От: igor-booch Россия  
Дата: 27.05.13 16:12
Оценка:
S>Ну как же? А if-then-else это не условная конструкция, или она не управляет потоком?

В функциональном программировании не управляет потоком выполнения.

http://msdn.microsoft.com/en-us/library/bb669144.aspx
Строчка Primary flow control в таблице отличий функционального программирования от императивного.
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания
http://rsdn.ru/Info/rules.xml
Re[34]: Товарищам смеющимся и минусующим: псевдопараллеризм
От: samius Япония http://sams-tricks.blogspot.com
Дата: 27.05.13 16:38
Оценка:
Здравствуйте, igor-booch, Вы писали:

S>>Ну как же? А if-then-else это не условная конструкция, или она не управляет потоком?


IB>В функциональном программировании не управляет потоком выполнения.

А F# достаточно функционален как пример функционального языка?
http://msdn.microsoft.com/en-us/library/dd233231.aspx
Вот что интересно. В C# значит if потоком управляет, а в F# уже нет?

IB>http://msdn.microsoft.com/en-us/library/bb669144.aspx

IB>Строчка Primary flow control в таблице отличий функционального программирования от императивного.
Хорошо, посмотрим по-пристальнее на сей солидный источник.
[Imperative]
Loops, conditionals, and function (method) calls.
[Functional]
Function calls, including recursion.

1. Function calls в обоих случаях. Вычеркнем function calls, т.к. в отличия подходов он явно не входит.
2. В императивном подходе Loops, а в функциональном — нет. Но видимо циклы заменяются рекурсией. Согласны?
3. В императивном conditionals, а в функциональном — походу никакого аналога. Тут либо источник не врет, либо какой-то аналог должен быть.

А теперь прошу, покажите мне нормальный рабочий пример рекурсии без conditionals и его аналогов. Рабочий — это значит что бы он что-то вычислял, а не представлял собой бесконечный цикл. Может быть вы укажете что-то в общем случае, или в частном (например, вычисление факториала).

Может есть какой-то другой источник, который убедительно показывает отсутствие conditionals в функциональном программировании?
Re[35]: Товарищам смеющимся и минусующим: псевдопараллеризм
От: igor-booch Россия  
Дата: 27.05.13 16:51
Оценка:
S>А теперь прошу, покажите мне нормальный рабочий пример рекурсии без conditionals и его аналогов. Рабочий — это значит что бы он что-то вычислял, а не представлял собой бесконечный цикл. Может быть вы укажете что-то в общем случае, или в частном (например, вычисление факториала).

Вот классический пример реализации быстрой сортировки на Haskell

qsort []     = []
qsort (x:xs) = qsort (filter (< x) xs) ++ [x] ++ qsort (filter (>= x) xs)


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

http://ru.wikibooks.org/wiki/%D0%9F%D1%80%D0%B8%D0%BC%D0%B5%D1%80%D1%8B_%D1%80%D0%B5%D0%B0%D0%BB%D0%B8%D0%B7%D0%B0%D1%86%D0%B8%D0%B8_%D0%B1%D1%8B%D1%81%D1%82%D1%80%D0%BE%D0%B9_%D1%81%D0%BE%D1%80%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%BA%D0%B8
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания
http://rsdn.ru/Info/rules.xml
Re[35]: Товарищам смеющимся и минусующим: псевдопараллеризм
От: igor-booch Россия  
Дата: 27.05.13 17:00
Оценка:
S>А F# достаточно функционален как пример функционального языка?
S>http://msdn.microsoft.com/en-us/library/dd233231.aspx

F# это грязный функциональный язык, так как допускает грязные функции, то есть переход на императивное программирование
Я все время вел дискуссию в рамках чистых функциональных языков.
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания
http://rsdn.ru/Info/rules.xml
Re[36]: Товарищам смеющимся и минусующим: псевдопараллеризм
От: samius Япония http://sams-tricks.blogspot.com
Дата: 27.05.13 17:01
Оценка:
Здравствуйте, igor-booch, Вы писали:

S>>А теперь прошу, покажите мне нормальный рабочий пример рекурсии без conditionals и его аналогов. Рабочий — это значит что бы он что-то вычислял, а не представлял собой бесконечный цикл. Может быть вы укажете что-то в общем случае, или в частном (например, вычисление факториала).


IB>Вот классический пример реализации быстрой сортировки на Haskell


IB>
IB>qsort []     = []
IB>qsort (x:xs) = qsort (filter (< x) xs) ++ [x] ++ qsort (filter (>= x) xs)
IB>


IB>Его обычно показывают функциональные программисты, когда хотят выпедриться перед императивными

И здесь мы видим в роли conditional PM. К if-then-else приводится тривиально, как и обратно.
Или вы будете утверждать что PM рулит потоком а if-then-else нет?
Re[37]: Товарищам смеющимся и минусующим: псевдопараллеризм
От: igor-booch Россия  
Дата: 27.05.13 17:06
Оценка:
S>И здесь мы видим в роли conditional PM. К if-then-else приводится тривиально, как и обратно.
S>Или вы будете утверждать что PM рулит потоком а if-then-else нет?

Что такое conditional PM ?
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания
http://rsdn.ru/Info/rules.xml
Re[36]: Товарищам смеющимся и минусующим: псевдопараллеризм
От: samius Япония http://sams-tricks.blogspot.com
Дата: 27.05.13 17:10
Оценка:
Здравствуйте, igor-booch, Вы писали:

S>>А F# достаточно функционален как пример функционального языка?

S>>http://msdn.microsoft.com/en-us/library/dd233231.aspx

IB>F# это грязный функциональный язык, так как допускает грязные функции, то есть переход на императивное программирование

IB>Я все время вел дискуссию в рамках чистых функциональных языков.

А, ну разок вы забыли упомянуть про чистоту и я тут же воткнул F#.
Re[38]: Товарищам смеющимся и минусующим: псевдопараллеризм
От: samius Япония http://sams-tricks.blogspot.com
Дата: 27.05.13 17:11
Оценка:
Здравствуйте, igor-booch, Вы писали:

S>>И здесь мы видим в роли conditional PM. К if-then-else приводится тривиально, как и обратно.

S>>Или вы будете утверждать что PM рулит потоком а if-then-else нет?

IB>Что такое conditional PM ?

не удачно выразился. Pattern matching в роли conditional.
Re[39]: Товарищам смеющимся и минусующим: псевдопараллеризм
От: igor-booch Россия  
Дата: 27.05.13 17:17
Оценка:
IB>>Что такое conditional PM ?
S>не удачно выразился. Pattern matching в роли conditional.

Pattern matching не управляет потоком выполнения, так же как и тернарный оператор (?) в императивных языках.
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания
http://rsdn.ru/Info/rules.xml
Re[40]: Товарищам смеющимся и минусующим: псевдопараллеризм
От: samius Япония http://sams-tricks.blogspot.com
Дата: 27.05.13 17:38
Оценка:
Здравствуйте, igor-booch, Вы писали:

IB>>>Что такое conditional PM ?

S>>не удачно выразился. Pattern matching в роли conditional.

IB>Pattern matching не управляет потоком выполнения, так же как и тернарный оператор (?) в императивных языках.

поржал
Re[41]: Товарищам смеющимся и минусующим: псевдопараллеризм
От: igor-booch Россия  
Дата: 27.05.13 18:06
Оценка: :)))
S>поржал
Не хотел спускаться в такие дебри, но придется.
Спуститесь на уровень ассемблерных комманд.
if как инструмент управления потоком с большей вероятностью будет компилироваться в cmp + jmp
cmp — это проверить условие
jmp — это goto
тут меняется поток управления (goto)

А вот тернарный оператор с большей вероятностью будет компилироваться в
cmov — Conditional Move Data
тут процессор проверит условие и на его основании выполнит перемещение данных в памяти
то есть изменения потока управления не произойдет

cmov работает быстрее чем cmp + jmp
В IL предусмотрены аналогичные оптимизации.

Источники
http://stackoverflow.com/questions/6754454/speed-difference-between-if-else-and-ternary-operator-in-c
http://stackoverflow.com/questions/2259741/is-the-conditional-operator-slow

Слово вероятность я здесь употребил, потому-что есть условия когда такая оптимизация может не срабатывать.
Здесь Вы конечно придирётесь к вероятности,
но здесь важна задумка, математическая концепция выражений, вычислимых без изменения потока управления, для которой разработчики процессоров сделали cmov.
Я предполагаю что в ассемблерном коде будет для функционального языка будет больше cmov, а в
ассемблерном коде будет для императивного языка будет больше cmp + jmp
Можно уточнить на форуме декларативных программистов.
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания
http://rsdn.ru/Info/rules.xml
Re[42]: Товарищам смеющимся и минусующим: псевдопараллеризм
От: samius Япония http://sams-tricks.blogspot.com
Дата: 27.05.13 18:16
Оценка:
Здравствуйте, igor-booch, Вы писали:

S>>поржал

IB>Не хотел спускаться в такие дебри, но придется.
IB>Спуститесь на уровень ассемблерных комманд.
Прошу прощения, но ища разницу между функциональным и императивным подходом на уровне ассемблера, вы мне напоминаете пару форумчан. Разница в подходе, а не в инструкциях.
Потому эти рассуждения об jmp и cmp я игнорирую.

IB>if как инструмент управления потоком с большей вероятностью будет компилироваться в cmp + jmp

IB>cmp — это проверить условие
IB>jmp — это goto
IB>тут меняется поток управления (goto)

IB>А вот тернарный оператор с большей вероятностью будет компилироваться в

IB>cmov — Conditional Move Data
IB>тут процессор проверит условие и на его основании выполнит перемещение данных в памяти
IB>то есть изменения потока управления не произойдет

IB>cmov работает быстрее чем cmp + jmp

IB>В IL предусмотрены аналогичные оптимизации.

IB>Источники

IB>http://stackoverflow.com/questions/6754454/speed-difference-between-if-else-and-ternary-operator-in-c
IB>http://stackoverflow.com/questions/2259741/is-the-conditional-operator-slow

IB>Слово вероятность я здесь употребил, потому-что есть условия когда такая оптимизация может не срабатывать.

IB>Здесь Вы конечно придирётесь к вероятности,
IB>но здесь важна задумка, математическая концепция выражений, вычислимых без изменения потока управления, для которой разработчики процессоров сделали cmov.
IB>Я предполагаю что в ассемблерном коде будет для функционального языка будет больше cmov, а в
IB>ассемблерном коде будет для императивного языка будет больше cmp + jmp
IB>Можно уточнить на форуме декларативных программистов.

Все довольно просто. Как императивный if позволяет указывать, выполнять ли какой-то код при условии (или без) так и функциональный if позволяет указывать, выполнять какой-то код или нет. Это и называется управлением потока вычисления.
А вот уже чем он там реализуется — это довольно малоинтересные детали. Значительное отличие в statement vs expression.
Re[43]: Товарищам смеющимся и минусующим: псевдопараллеризм
От: igor-booch Россия  
Дата: 27.05.13 18:27
Оценка: :)
S>>>поржал
IB>>Не хотел спускаться в такие дебри, но придется.
IB>>Спуститесь на уровень ассемблерных комманд.
S>Прошу прощения, но ища разницу между функциональным и императивным подходом на уровне ассемблера, вы мне напоминаете пару форумчан. Разница в подходе, а не в инструкциях.
Так ассемблер это Ваша любимая машина Тюринга,
всё от ней растет, в т. ч. и лямбда исчисление
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания
http://rsdn.ru/Info/rules.xml
Re[44]: Товарищам смеющимся и минусующим: псевдопараллеризм
От: samius Япония http://sams-tricks.blogspot.com
Дата: 27.05.13 18:40
Оценка: -1
Здравствуйте, igor-booch, Вы писали:

S>>>>поржал

IB>>>Не хотел спускаться в такие дебри, но придется.
IB>>>Спуститесь на уровень ассемблерных комманд.
S>>Прошу прощения, но ища разницу между функциональным и императивным подходом на уровне ассемблера, вы мне напоминаете пару форумчан. Разница в подходе, а не в инструкциях.
IB>Так ассемблер это Ваша любимая машина Тюринга,
IB>всё от ней растет, в т. ч. и лямбда исчисление
Очень сомневаюсь в происхождении лямбда исчисления от машины Тюринга. Вам стоит взглянуть на даты первых публикаций по тому и другому.
Re[45]: Товарищам смеющимся и минусующим: псевдопараллеризм
От: samius Япония http://sams-tricks.blogspot.com
Дата: 27.05.13 19:06
Оценка:
Здравствуйте, samius, Вы писали:

S>Здравствуйте, igor-booch, Вы писали:


IB>>Так ассемблер это Ваша любимая машина Тюринга,

IB>>всё от ней растет, в т. ч. и лямбда исчисление
S>Очень сомневаюсь в происхождении лямбда исчисления от машины Тюринга. Вам стоит взглянуть на даты первых публикаций по тому и другому.
-1 вместо аргументированного ответа?
Re[42]: Товарищам смеющимся и минусующим: псевдопараллеризм
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 28.05.13 06:15
Оценка:
Здравствуйте, igor-booch, Вы писали:

S>>поржал

IB>Не хотел спускаться в такие дебри, но придется.
IB>Спуститесь на уровень ассемблерных комманд.
IB>if как инструмент управления потоком с большей вероятностью будет компилироваться в cmp + jmp
IB>cmp — это проверить условие
IB>jmp — это goto
IB>тут меняется поток управления (goto)

IB>А вот тернарный оператор с большей вероятностью будет компилироваться в

IB>cmov — Conditional Move Data

Похоже, у vdimas появились последователи. Это просто оптимизация компилятора, её можно делать и в случае с if, никаких препятствий для этого нет.

IB>тут процессор проверит условие и на его основании выполнит перемещение данных в памяти

IB>то есть изменения потока управления не произойдет

Давай на примере:

var f = predicate() ? function1() : funciton2();


В чем разница с аналогичным if ?
Re[46]: Товарищам смеющимся и минусующим: псевдопараллеризм
От: igor-booch Россия  
Дата: 28.05.13 06:20
Оценка:
S>-1 вместо аргументированного ответа?

Кому надо и кому будет интересно, сам уже сможет во всем разобраться.
Не вижу смысла в дальнейшей дискуссии.
Если что то осталось не понятно задавайте вопросы в личку.
Постараюсь ответить.
Если вопросы будут интересные, сделаю отдельные топики, ну, или Вы сами сделайте.
Эту ветку больше не хочу засорять.
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания
http://rsdn.ru/Info/rules.xml
Re[43]: Товарищам смеющимся и минусующим: псевдопараллеризм
От: igor-booch Россия  
Дата: 28.05.13 06:26
Оценка:
IB>>А вот тернарный оператор с большей вероятностью будет компилироваться в
IB>>cmov — Conditional Move Data
I>Это просто оптимизация компилятора, её можно делать и в случае с if, никаких препятствий для этого нет.

Можно, только с тернарным оператором она будет более вероятна, так как он является expression, а не statement как if
С if менее вероятна.
Разработчики систем команд CPU и компиляторов, зная принципиальные отличия expression от statement предусмотрели такие оптимизации.
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания
http://rsdn.ru/Info/rules.xml
Re[37]: Товарищам смеющимся и минусующим: псевдопараллеризм
От: igor-booch Россия  
Дата: 28.05.13 06:47
Оценка:
S>А, ну разок вы забыли упомянуть про чистоту и я тут же воткнул F#.
http://rsdn.ru/forum/dotnet/5181824.1
Автор: igor-booch
Дата: 27.05.13
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания
http://rsdn.ru/Info/rules.xml
Re[44]: Товарищам смеющимся и минусующим: псевдопараллеризм
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 28.05.13 06:49
Оценка: +1 -1
Здравствуйте, igor-booch, Вы писали:

IB>Так ассемблер это Ваша любимая машина Тюринга,

IB>всё от ней растет, в т. ч. и лямбда исчисление

Лямбда счисление это абстракция того же уровня что и машина тьюринга и обе этих абстрации абсолютно независимы.
Re[44]: Товарищам смеющимся и минусующим: псевдопараллеризм
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 28.05.13 06:53
Оценка:
Здравствуйте, igor-booch, Вы писали:

IB>Можно, только с тернарным оператором она будет более вероятна, так как он является expression, а не statement как if

IB>С if менее вероятна.
IB>Разработчики систем команд CPU и компиляторов, зная принципиальные отличия expression от statement предусмотрели такие оптимизации.

Не будет она "более вероятна". Более вероятно, что тернарную операцию будет невозможно применить, а следовательно и соответствующую оптимизацию. А если if можно свести к тернарной операции, то нет препятствий для оптимизации. Возможно только компилятор пока еще не умеет все такие оптимизации.
Re[47]: Товарищам смеющимся и минусующим: псевдопараллеризм
От: samius Япония http://sams-tricks.blogspot.com
Дата: 28.05.13 06:53
Оценка:
Здравствуйте, igor-booch, Вы писали:

S>>-1 вместо аргументированного ответа?


IB>Кому надо и кому будет интересно, сам уже сможет во всем разобраться.

Уже? А что изменилось? Что в этой теме было озвучено такого ключевого, после чего кому надо смогут сами разобраться и до чего не могли бы?
IB>Не вижу смысла в дальнейшей дискуссии.
Не все в жизни делается с умыслом

IB>Если что то осталось не понятно задавайте вопросы в личку.

IB>Постараюсь ответить.
IB>Если вопросы будут интересные, сделаю отдельные топики, ну, или Вы сами сделайте.
IB>Эту ветку больше не хочу засорять.
Вот знаете какие вопросы остались? Порядка как так можно поставить -1 на просьбу сравнить даты публикаций о лямбда исчислении и машины Тюринга? Вот с чем вы не согласны, с тем что их надо сравнивать прежде чем утверждать, что от чего произошло, или с чем еще?
Не то что бы я за минусы переживаю. Просто часто понятно, с чем собеседник не согласен. А тут — совершенно нет.

А вопросы по предмету я лучше задам википедии В ваших трактовках, конечно, забавно разбираться. Но контрпродуктивно.
Re[38]: Товарищам смеющимся и минусующим: псевдопараллеризм
От: samius Япония http://sams-tricks.blogspot.com
Дата: 28.05.13 06:56
Оценка:
Здравствуйте, igor-booch, Вы писали:

S>>А, ну разок вы забыли упомянуть про чистоту и я тут же воткнул F#.

IB>http://rsdn.ru/forum/dotnet/5181824.1
Автор: igor-booch
Дата: 27.05.13

у вас там очередная путаница. Чистый ФП не значит ленивый и наоборот.
Re[45]: Товарищам смеющимся и минусующим: псевдопараллеризм
От: igor-booch Россия  
Дата: 28.05.13 06:56
Оценка:
I>Лямбда счисление это абстракция того же уровня что и машина тьюринга и обе этих абстрации абсолютно независимы.


Вместе с ней λ-исчисление обладает свойством полноты по Тьюрингу и, следовательно, представляет собой простейший язык программирования

http://ru.wikipedia.org/wiki/%D0%9B%D1%8F%D0%BC%D0%B1%D0%B4%D0%B0-%D0%B8%D1%81%D1%87%D0%B8%D1%81%D0%BB%D0%B5%D0%BD%D0%B8%D0%B5
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания
http://rsdn.ru/Info/rules.xml
Re[45]: Товарищам смеющимся и минусующим: псевдопараллеризм
От: igor-booch Россия  
Дата: 28.05.13 07:05
Оценка:
S>Очень сомневаюсь в происхождении лямбда исчисления от машины Тюринга. Вам стоит взглянуть на даты первых публикаций по тому и другому.
http://rsdn.ru/forum/dotnet/5182862.1
Автор: igor-booch
Дата: 28.05.13
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания
http://rsdn.ru/Info/rules.xml
Re[46]: Товарищам смеющимся и минусующим: псевдопараллеризм
От: samius Япония http://sams-tricks.blogspot.com
Дата: 28.05.13 07:05
Оценка: -1
Здравствуйте, igor-booch, Вы писали:

I>>Лямбда счисление это абстракция того же уровня что и машина тьюринга и обе этих абстрации абсолютно независимы.



IB>

IB> Вместе с ней λ-исчисление обладает свойством полноты по Тьюрингу и, следовательно, представляет собой простейший язык программирования


Ну вот мериют массу в килограммах. Отсюда ведь не значит что фунты произошли от килограммов? А полноту мериют по Тьюрингу. Вот и делов-то.
Re[47]: Товарищам смеющимся и минусующим: псевдопараллеризм
От: igor-booch Россия  
Дата: 28.05.13 07:13
Оценка:
Здравствуйте, samius, Вы писали:

S>Здравствуйте, igor-booch, Вы писали:


I>>>Лямбда счисление это абстракция того же уровня что и машина тьюринга и обе этих абстрации абсолютно независимы.



IB>>

IB>> Вместе с ней λ-исчисление обладает свойством полноты по Тьюрингу и, следовательно, представляет собой простейший язык программирования


S>Ну вот мериют массу в килограммах. Отсюда ведь не значит что фунты произошли от килограммов? А полноту мериют по Тьюрингу. Вот и делов-то.



Здесь другой смысл. По Вашему получается, что масса обладает свойством килограмма.
В этой цитате имеется ввиду, что λ-исчисление сводится к машине Тьюринга.
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания
http://rsdn.ru/Info/rules.xml
Re[48]: Товарищам смеющимся и минусующим: псевдопараллеризм
От: samius Япония http://sams-tricks.blogspot.com
Дата: 28.05.13 07:19
Оценка:
Здравствуйте, igor-booch, Вы писали:

IB>Здесь другой смысл. По Вашему получается, что масса обладает свойством килограмма.

IB>В этой цитате имеется ввиду, что λ-исчисление сводится к машине Тьюринга.
Представляете, оно и наоборот сводится (МТ к λ-исчислению). И какие выводы вы теперь сделаете?
Re[49]: Товарищам смеющимся и минусующим: псевдопараллеризм
От: igor-booch Россия  
Дата: 28.05.13 07:23
Оценка:
IB>>В этой цитате имеется ввиду, что λ-исчисление сводится к машине Тьюринга.
S>Представляете, оно и наоборот сводится (МТ к λ-исчислению). И какие выводы вы теперь сделаете?

Представляю, выводы мои от этого не меняются.
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания
http://rsdn.ru/Info/rules.xml
Re[50]: Товарищам смеющимся и минусующим: псевдопараллеризм
От: samius Япония http://sams-tricks.blogspot.com
Дата: 28.05.13 07:47
Оценка:
Здравствуйте, igor-booch, Вы писали:

IB>>>В этой цитате имеется ввиду, что λ-исчисление сводится к машине Тьюринга.

S>>Представляете, оно и наоборот сводится (МТ к λ-исчислению). И какие выводы вы теперь сделаете?

IB>Представляю, выводы мои от этого не меняются.

Представил. В сочетании с игнорированием хронологии открытий МТ и λ-исчисления это признаки отрицания объективной реальности.
Re[46]: Товарищам смеющимся и минусующим: псевдопараллеризм
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 28.05.13 08:37
Оценка:
Здравствуйте, igor-booch, Вы писали:

I>>Лямбда счисление это абстракция того же уровня что и машина тьюринга и обе этих абстрации абсолютно независимы.


IB>

IB> Вместе с ней λ-исчисление обладает свойством полноты по Тьюрингу и, следовательно, представляет собой простейший язык программирования

IB>http://ru.wikipedia.org/wiki/%D0%9B%D1%8F%D0%BC%D0%B1%D0%B4%D0%B0-%D0%B8%D1%81%D1%87%D0%B8%D1%81%D0%BB%D0%B5%D0%BD%D0%B8%D0%B5

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

Скажем, если два человека обладают одинаковыми физическими и интеллектуальными данным и даже являются двойниками друг друга, то из этого никак не следует, что один из них произошел от другого.
Re[48]: Товарищам смеющимся и минусующим: псевдопараллеризм
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 28.05.13 08:42
Оценка:
Здравствуйте, igor-booch, Вы писали:

IB>Здесь другой смысл. По Вашему получается, что масса обладает свойством килограмма.

IB>В этой цитате имеется ввиду, что λ-исчисление сводится к машине Тьюринга.

Не сводится. В той цитате говорится о том, что любую вычислимую задачу можно решить как машиной Тьюринга, так и лямбда счислением.
Re[49]: Товарищам смеющимся и минусующим: псевдопараллеризм
От: igor-booch Россия  
Дата: 28.05.13 10:51
Оценка:
I>Не сводится. В той цитате говорится о том, что любую вычислимую задачу можно решить как машиной Тьюринга, так и лямбда счислением.

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

Первые попытки уточнения понятия алгоритма и его исследования осуществляли в первой половине XX века Алан Тьюринг, Эмиль Пост, Жак Эрбран, Курт Гедель, А. А. Марков, Алонзо Чёрч. Было разработано несколько определений понятия алгоритма, но впоследствии было выяснено, что все они определяют одно и то же понятие

http://ru.wikipedia.org/wiki/%D0%90%D0%BB%D0%B3%D0%BE%D1%80%D0%B8%D1%82%D0%BC#.D0.A4.D0.BE.D1.80.D0.BC.D0.B0.D0.BB.D1.8C.D0.BD.D0.BE.D0.B5_.D0.BE.D0.BF.D1.80.D0.B5.D0.B4.D0.B5.D0.BB.D0.B5.D0.BD.D0.B8.D0.B5
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания
http://rsdn.ru/Info/rules.xml
Re[47]: Товарищам смеющимся и минусующим: псевдопараллеризм
От: igor-booch Россия  
Дата: 28.05.13 10:55
Оценка:
I>Это всего лишь означает, что вычислительные возможности обоих версий одинаковы и из этого никак не следует, что одно произошло от другого.

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


Согласен. Просто современные CPU это машины Тюринга и важна сводимость именно к машине Тюринга. Я это имел ввиду.
Для квантовых компьютеров IMHO родным будет лямбда исчисление.
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания
http://rsdn.ru/Info/rules.xml
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.