Сообщение Re[71]: MS забило на дотнет. Питону - да, сишарпу - нет? от 17.09.2021 18:49
Изменено 17.09.2021 21:20 vdimas
Re[71]: MS забило на дотнет. Питону - да, сишарпу - нет?
Здравствуйте, Sinclair, Вы писали:
V>>Т.е. тот же исходник, с чуть другим форматированием и идентификаторами?
S>Примерно так.
Это слив корпоративного ноу-хау.
V>>Исследования имеющихся lock-free алгоритмов и потенциальных способов их применимости в наших сценариях я делал за зарплату в рабочее время когда-то.
V>>Туда же изобретение собственных как алгоритмов, так и сценариев их применения.
S>Вы же в курсе, что алгоритмы не являются охраноспособными?
Только на алгоритмы и можно получить патент.
Но на конкретную реализацию алгоритма (вотчина авторского права) патент получить нельзя.
Далее.
Патент требует раскрытия алгоритма.
Срок патента ограничен.
Ограничена географическая область патента — охрана действительна только в стране выдачи и в странах, где действуют взаимные патентные соглашения со страной выдачи.
Патенты стоят денег, патентировать алгоритмы по всему миру дорого.
Не зря в программировании прижилось в основном "ноу-хау" — коммерческая тайна.
А крупные конторы патентируют обычно вещи, которые видны невооружённым взглядом, т.е. алгоритмы работы системы в целом, на высоком уровне.
И то, я как-то почитывал такие патенты — удивлялся.
Похоже, патентируют очевидные вещи сугубо в кач-ве защиты от патентных троллей.
Этим информационным мусором отбили всякое любопытство почитывать западные патенты.
S>А исходный код — это исходный код. В него входит и форматирование, и идентификаторы. ГК РФ запросто разрешает параллельно разрабатывать два кода, один из которых является служебным произведением, а второй — нет.
Да плевать на тонкости реализации и форматирования. ))
Не уверен, что требуется кому-либо объяснять это.
V>>Например, у нас при банальной отсылке данных в сокет совместно работает сразу 3 lock-free алгоритма.
V>>Каждый из них простейший, но их определённая комбинация рождает новый алгоритм более высокого уровня, который умудряется быть тем эффективней, чем больше нагрузка.
S>Хорошо вам.
Там кейз специфический — lock-free очередь соединена с примитивом сигнализации, на котором надо ожидать в отсутствии задач или IO.
В дотнете же для тасков используют встроенный пул, который в случае Windows и вовсе системный:
https://docs.microsoft.com/en-us/windows/win32/api/threadpoollegacyapiset/nf-threadpoollegacyapiset-queueuserworkitem
И потоки из пула ожидают на внутренних своих примитивах сигнализации внутри WinaAPI, где нет возможности добавить знание о происходящем в очереди в сам факт манипулирования примитивами сигнализации.
Например, дотнет должен обслуживать как потенциально-легковесную очередь задач самому себе, так и поступающие извне в поток UserWorkItem, даже если они к Task не имеют никакого отношения.
Я же говорю — тут требуется комплексное переосмысление происходящего.
Мне даже очередь таймеров пришлось переосмыслить от классической приоритетной очереди до, скажем так, своей релизации, более подходящей под наши сценарии.
Даже запрос текущего monotonic-системного времени был переосмыслен. ))
Кароч, всё то, что отжирало то тут, то там сотни наносекунд или даже до микросекунды на каждый чих, складываясь в общую задержку.
Стоимость своих альтернативных решений — единицы-десяки наносекунд на каждую такую операцию-кирпичик.
V>>Выглядит как "я хочу на блюдечке с голубой каёмочкой".
V>>Хотел бы по-настоящему, уже бы давал свои соображения по реализации (там есть на что обратить внимание).
S>Не, я не настолько квалифицирован в lock-free алгоритмах.
Ну, сложные lock-free алгоритмы не всегда в реальном использовании обгоняют простые на мьютексах, если блокировки мьютексов короткие и вероятность конфликтов низка.
По настоящему эффективными могут быть только предельно простые lock-free алгоритмы, их можно понять и без специальной подготовки.
Тогда задача перетекает в несколько другую плоскость — попытаться расписать работу всей системы на комбинации отдельных простых lock-free алгоритмов.
Для меня это неотъемлимый контекст по работе, с этих позиций и рассуждал.
Поэтому, нет желания прогибаться под попытку переиначить исходные мои заявления, вычленить и рассмотреть только часть и т.д.
Опять же, дотнетный пул потоков под таски обычно в разы больше кол-ва ядер в системе.
Я как-то замерял — на моих 12 ядрах он создавал под 200 с лишним потоков в пуле на интенсивном использовании.
Поэтому, потенциальное блокирование из-за того, что реализация конкурентной очереди не удовлетворяет гарантиям lock-free, что потенциально может заморозить лишь +1 попавший в конфликт поток — это вроде как приписанное системе допущение. И тогда очередь остальных задач к потоку может разгребаться другими потоками.
Но эта парочка задач-неудачниц будет страдать. ))
Совсем другое дело, когда в нашем пуле ровно столько потоков, сколько ядер, гарантии lock-free соблюдаются, ни один поток не морозится.
Таски, таймеры и IO обслуживаются в этом общем пуле, процессоры переключают контексты исполнения крайне редко — когда нет данных, т.е. можно уйти в спячку до получения сигнала о пробуждении.
V>>И да, замена очереди и переосмысливание всей системы в конце всех концов делает асинхронщину в разы эффективнее, например, как у нас.
S>Ну, вы молоцы. Жалко, что кроме вас, об этом никто не знает
Индустрия знает, мы в лидерах, 1-2-е места по репортам тестовых лабораторий Intel.
V>>Ну, если фанаты будут обсуждать не технику игроков, а их одежду и даже стрижку вратаря — то где-то так и будет.
S>Так а как можно обсуждать технику, которой нет?
Можно обсуждать, какой она могла бы быть.
Тем более, что адрес одного из примеров был дан.
S>Нет кода — нет предмета обсуждения.
Слава богу, очень немногие коллеги так категорично ставят вопрос.
В основе всего лежит идея.
И даже не спорь. ))
"Дайте готовый код" — присказка уставших от жизни ленивцев.
S>Выходит так, что ваша часть дискуссии — это "ваш Месси плохо держит мяч, у меня есть игрок, который делает это лучше. Но я вам его не покажу, потому что он секретный. И вообще — есть множество других игроков, вполне публичных, которые играют лучше Месси. Но я вам их не назову — сами найдите да посмотрите".
Отсылка к футболу была твоей, аналогия малость хромает...
Можно взять аналогию ближе к инженерной, например, сравнить характеристики ракет потенциальных противников, где применённые технологии являются охраняемой тайной.
S>Предлагаю тему свернуть, потому как про воображаемый секретный код мне не очень интересно.
А как другой код поможет тебе понять, что именно происходит в дотнетных тасках сейчас?
Чем тебя не устраивает уже имеющийся дотнетный код для целей анализа происходящего?
Не интересно? (скорее всего)
У меня же не было перед глазами готового решения.
Я должен был проводить анализ происходящего, сравнивать различные подходы, внимательно смотреть как данные циркулируют, где и сколько раз дёргаются примитивы сигнализации, а нужно ли их там дёргать и т.д. и т.п.
V>>Т.е. тот же исходник, с чуть другим форматированием и идентификаторами?
S>Примерно так.
Это слив корпоративного ноу-хау.
V>>Исследования имеющихся lock-free алгоритмов и потенциальных способов их применимости в наших сценариях я делал за зарплату в рабочее время когда-то.
V>>Туда же изобретение собственных как алгоритмов, так и сценариев их применения.
S>Вы же в курсе, что алгоритмы не являются охраноспособными?
Только на алгоритмы и можно получить патент.
Но на конкретную реализацию алгоритма (вотчина авторского права) патент получить нельзя.
Далее.
Патент требует раскрытия алгоритма.
Срок патента ограничен.
Ограничена географическая область патента — охрана действительна только в стране выдачи и в странах, где действуют взаимные патентные соглашения со страной выдачи.
Патенты стоят денег, патентировать алгоритмы по всему миру дорого.
Не зря в программировании прижилось в основном "ноу-хау" — коммерческая тайна.
А крупные конторы патентируют обычно вещи, которые видны невооружённым взглядом, т.е. алгоритмы работы системы в целом, на высоком уровне.
И то, я как-то почитывал такие патенты — удивлялся.
Похоже, патентируют очевидные вещи сугубо в кач-ве защиты от патентных троллей.
Этим информационным мусором отбили всякое любопытство почитывать западные патенты.
S>А исходный код — это исходный код. В него входит и форматирование, и идентификаторы. ГК РФ запросто разрешает параллельно разрабатывать два кода, один из которых является служебным произведением, а второй — нет.
Да плевать на тонкости реализации и форматирования. ))
Не уверен, что требуется кому-либо объяснять это.
V>>Например, у нас при банальной отсылке данных в сокет совместно работает сразу 3 lock-free алгоритма.
V>>Каждый из них простейший, но их определённая комбинация рождает новый алгоритм более высокого уровня, который умудряется быть тем эффективней, чем больше нагрузка.
S>Хорошо вам.
Там кейз специфический — lock-free очередь соединена с примитивом сигнализации, на котором надо ожидать в отсутствии задач или IO.
В дотнете же для тасков используют встроенный пул, который в случае Windows и вовсе системный:
https://docs.microsoft.com/en-us/windows/win32/api/threadpoollegacyapiset/nf-threadpoollegacyapiset-queueuserworkitem
И потоки из пула ожидают на внутренних своих примитивах сигнализации внутри WinaAPI, где нет возможности добавить знание о происходящем в очереди в сам факт манипулирования примитивами сигнализации.
Например, дотнет должен обслуживать как потенциально-легковесную очередь задач самому себе, так и поступающие извне в поток UserWorkItem, даже если они к Task не имеют никакого отношения.
Я же говорю — тут требуется комплексное переосмысление происходящего.
Мне даже очередь таймеров пришлось переосмыслить от классической приоритетной очереди до, скажем так, своей релизации, более подходящей под наши сценарии.
Даже запрос текущего monotonic-системного времени был переосмыслен. ))
Кароч, всё то, что отжирало то тут, то там сотни наносекунд или даже до микросекунды на каждый чих, складываясь в общую задержку.
Стоимость своих альтернативных решений — единицы-десяки наносекунд на каждую такую операцию-кирпичик.
V>>Выглядит как "я хочу на блюдечке с голубой каёмочкой".
V>>Хотел бы по-настоящему, уже бы давал свои соображения по реализации (там есть на что обратить внимание).
S>Не, я не настолько квалифицирован в lock-free алгоритмах.
Ну, сложные lock-free алгоритмы не всегда в реальном использовании обгоняют простые на мьютексах, если блокировки мьютексов короткие и вероятность конфликтов низка.
По настоящему эффективными могут быть только предельно простые lock-free алгоритмы, их можно понять и без специальной подготовки.
Тогда задача перетекает в несколько другую плоскость — попытаться расписать работу всей системы на комбинации отдельных простых lock-free алгоритмов.
Для меня это неотъемлимый контекст по работе, с этих позиций и рассуждал.
Поэтому, нет желания прогибаться под попытку переиначить исходные мои заявления, вычленить и рассмотреть только часть и т.д.
Опять же, дотнетный пул потоков под таски обычно в разы больше кол-ва ядер в системе.
Я как-то замерял — на моих 12 ядрах он создавал под 200 с лишним потоков в пуле на интенсивном использовании.
Поэтому, потенциальное блокирование из-за того, что реализация конкурентной очереди не удовлетворяет гарантиям lock-free, что потенциально может заморозить лишь +1 попавший в конфликт поток — это вроде как приписанное системе допущение. И тогда очередь остальных задач к потоку может разгребаться другими потоками.
Но эта парочка задач-неудачниц будет страдать. ))
Совсем другое дело, когда в нашем пуле ровно столько потоков, сколько ядер, гарантии lock-free соблюдаются, ни один поток не морозится.
Таски, таймеры и IO обслуживаются в этом общем пуле, процессоры переключают контексты исполнения крайне редко — когда нет данных, т.е. можно уйти в спячку до получения сигнала о пробуждении.
V>>И да, замена очереди и переосмысливание всей системы в конце всех концов делает асинхронщину в разы эффективнее, например, как у нас.
S>Ну, вы молоцы. Жалко, что кроме вас, об этом никто не знает
Индустрия знает, мы в лидерах, 1-2-е места по репортам тестовых лабораторий Intel.
V>>Ну, если фанаты будут обсуждать не технику игроков, а их одежду и даже стрижку вратаря — то где-то так и будет.
S>Так а как можно обсуждать технику, которой нет?
Можно обсуждать, какой она могла бы быть.
Тем более, что адрес одного из примеров был дан.
S>Нет кода — нет предмета обсуждения.
Слава богу, очень немногие коллеги так категорично ставят вопрос.
В основе всего лежит идея.
И даже не спорь. ))
"Дайте готовый код" — присказка уставших от жизни ленивцев.
S>Выходит так, что ваша часть дискуссии — это "ваш Месси плохо держит мяч, у меня есть игрок, который делает это лучше. Но я вам его не покажу, потому что он секретный. И вообще — есть множество других игроков, вполне публичных, которые играют лучше Месси. Но я вам их не назову — сами найдите да посмотрите".
Отсылка к футболу была твоей, аналогия малость хромает...
Можно взять аналогию ближе к инженерной, например, сравнить характеристики ракет потенциальных противников, где применённые технологии являются охраняемой тайной.
S>Предлагаю тему свернуть, потому как про воображаемый секретный код мне не очень интересно.
А как другой код поможет тебе понять, что именно происходит в дотнетных тасках сейчас?
Чем тебя не устраивает уже имеющийся дотнетный код для целей анализа происходящего?
Не интересно? (скорее всего)
У меня же не было перед глазами готового решения.
Я должен был проводить анализ происходящего, сравнивать различные подходы, внимательно смотреть как данные циркулируют, где и сколько раз дёргаются примитивы сигнализации, а нужно ли их там дёргать и т.д. и т.п.
Re[71]: MS забило на дотнет. Питону - да, сишарпу - нет?
Здравствуйте, Sinclair, Вы писали:
V>>Т.е. тот же исходник, с чуть другим форматированием и идентификаторами?
S>Примерно так.
Это слив корпоративного ноу-хау.
V>>Исследования имеющихся lock-free алгоритмов и потенциальных способов их применимости в наших сценариях я делал за зарплату в рабочее время когда-то.
V>>Туда же изобретение собственных как алгоритмов, так и сценариев их применения.
S>Вы же в курсе, что алгоритмы не являются охраноспособными?
Только на алгоритмы и можно получить патент.
Но на конкретную реализацию алгоритма (вотчина авторского права) патент получить нельзя.
Далее.
Патент требует раскрытия алгоритма.
Срок патента ограничен.
Ограничена географическая область патента — охрана действительна только в стране выдачи и в странах, где действуют взаимные патентные соглашения со страной выдачи.
Патенты стоят денег, патентировать алгоритмы по всему миру дорого.
Не зря в программировании прижилось в основном "ноу-хау" — коммерческая тайна.
А крупные конторы патентируют обычно вещи, которые видны невооружённым взглядом, т.е. алгоритмы работы системы в целом, на высоком уровне.
И то, я как-то почитывал такие патенты — удивлялся.
Похоже, патентируют очевидные вещи сугубо в кач-ве защиты от патентных троллей.
Этим информационным мусором отбили всякое любопытство почитывать западные патенты.
S>А исходный код — это исходный код. В него входит и форматирование, и идентификаторы. ГК РФ запросто разрешает параллельно разрабатывать два кода, один из которых является служебным произведением, а второй — нет.
Да плевать на тонкости реализации и форматирования. ))
Не уверен, что требуется кому-либо объяснять это.
V>>Например, у нас при банальной отсылке данных в сокет совместно работает сразу 3 lock-free алгоритма.
V>>Каждый из них простейший, но их определённая комбинация рождает новый алгоритм более высокого уровня, который умудряется быть тем эффективней, чем больше нагрузка.
S>Хорошо вам.
Там кейз специфический — lock-free очередь обслуживает так же примитив сигнализации, на котором надо ожидать в отсутствии задач или IO.
В дотнете же для тасков используют встроенный пул, который в случае Windows и вовсе системный:
https://docs.microsoft.com/en-us/windows/win32/api/threadpoollegacyapiset/nf-threadpoollegacyapiset-queueuserworkitem
И потоки из пула ожидают на внутренних своих примитивах сигнализации внутри WinaAPI, где нет возможности добавить знание о происходящем в очереди в сам факт манипулирования примитивами сигнализации.
Например, дотнет должен обслуживать как потенциально-легковесную очередь задач самому себе, так и поступающие извне в поток UserWorkItem, даже если они к Task не имеют никакого отношения.
Я же говорю — тут требуется комплексное переосмысление происходящего.
Мне даже очередь таймеров пришлось переосмыслить от классической приоритетной очереди до, скажем так, своей релизации, более подходящей под наши сценарии.
Даже запрос текущего monotonic-системного времени был переосмыслен. ))
Кароч, всё то, что отжирало то тут, то там сотни наносекунд или даже до микросекунды на каждый чих, складываясь в общую задержку.
Стоимость своих альтернативных решений — единицы-десяки наносекунд на каждую такую операцию-кирпичик.
V>>Выглядит как "я хочу на блюдечке с голубой каёмочкой".
V>>Хотел бы по-настоящему, уже бы давал свои соображения по реализации (там есть на что обратить внимание).
S>Не, я не настолько квалифицирован в lock-free алгоритмах.
Ну, сложные lock-free алгоритмы не всегда в реальном использовании обгоняют простые на мьютексах, если блокировки мьютексов короткие и вероятность конфликтов низка.
По настоящему эффективными могут быть только предельно простые lock-free алгоритмы, их можно понять и без специальной подготовки.
Тогда задача перетекает в несколько другую плоскость — попытаться расписать работу всей системы на комбинации отдельных простых lock-free алгоритмов.
Для меня это неотъемлимый контекст по работе, с этих позиций и рассуждал.
Поэтому, нет желания прогибаться под попытку переиначить исходные мои заявления, вычленить и рассмотреть только часть и т.д.
Опять же, дотнетный пул потоков под таски обычно в разы больше кол-ва ядер в системе.
Я как-то замерял — на моих 12 ядрах он создавал под 200 с лишним потоков в пуле на интенсивном использовании.
Поэтому, потенциальное блокирование из-за того, что реализация конкурентной очереди не удовлетворяет гарантиям lock-free, что потенциально может заморозить лишь +1 попавший в конфликт поток — это вроде как приписанное системе допущение. И тогда очередь остальных задач к потоку может разгребаться другими потоками.
Но эта парочка задач-неудачниц будет страдать. ))
Совсем другое дело, когда в нашем пуле ровно столько потоков, сколько ядер, гарантии lock-free соблюдаются, ни один поток не морозится.
Таски, таймеры и IO обслуживаются в этом общем пуле, процессоры переключают контексты исполнения крайне редко — когда нет данных, т.е. можно уйти в спячку до получения сигнала о пробуждении.
V>>И да, замена очереди и переосмысливание всей системы в конце всех концов делает асинхронщину в разы эффективнее, например, как у нас.
S>Ну, вы молоцы. Жалко, что кроме вас, об этом никто не знает
Индустрия знает, мы в лидерах, 1-2-е места по репортам тестовых лабораторий Intel.
V>>Ну, если фанаты будут обсуждать не технику игроков, а их одежду и даже стрижку вратаря — то где-то так и будет.
S>Так а как можно обсуждать технику, которой нет?
Можно обсуждать, какой она могла бы быть.
Тем более, что адрес одного из примеров был дан.
S>Нет кода — нет предмета обсуждения.
Слава богу, очень немногие коллеги так категорично ставят вопрос.
В основе всего лежит идея.
И даже не спорь. ))
"Дайте готовый код" — присказка уставших от жизни ленивцев.
S>Выходит так, что ваша часть дискуссии — это "ваш Месси плохо держит мяч, у меня есть игрок, который делает это лучше. Но я вам его не покажу, потому что он секретный. И вообще — есть множество других игроков, вполне публичных, которые играют лучше Месси. Но я вам их не назову — сами найдите да посмотрите".
Отсылка к футболу была твоей, аналогия малость хромает...
Можно взять аналогию ближе к инженерной, например, сравнить характеристики ракет потенциальных противников, где применённые технологии являются охраняемой тайной.
S>Предлагаю тему свернуть, потому как про воображаемый секретный код мне не очень интересно.
А как другой код поможет тебе понять, что именно происходит в дотнетных тасках сейчас?
Чем тебя не устраивает уже имеющийся дотнетный код для целей анализа происходящего?
Не интересно? (скорее всего)
У меня же не было перед глазами готового решения.
Я должен был проводить анализ происходящего, сравнивать различные подходы, внимательно смотреть как данные циркулируют, где и сколько раз дёргаются примитивы сигнализации, а нужно ли их там дёргать и т.д. и т.п.
V>>Т.е. тот же исходник, с чуть другим форматированием и идентификаторами?
S>Примерно так.
Это слив корпоративного ноу-хау.
V>>Исследования имеющихся lock-free алгоритмов и потенциальных способов их применимости в наших сценариях я делал за зарплату в рабочее время когда-то.
V>>Туда же изобретение собственных как алгоритмов, так и сценариев их применения.
S>Вы же в курсе, что алгоритмы не являются охраноспособными?
Только на алгоритмы и можно получить патент.
Но на конкретную реализацию алгоритма (вотчина авторского права) патент получить нельзя.
Далее.
Патент требует раскрытия алгоритма.
Срок патента ограничен.
Ограничена географическая область патента — охрана действительна только в стране выдачи и в странах, где действуют взаимные патентные соглашения со страной выдачи.
Патенты стоят денег, патентировать алгоритмы по всему миру дорого.
Не зря в программировании прижилось в основном "ноу-хау" — коммерческая тайна.
А крупные конторы патентируют обычно вещи, которые видны невооружённым взглядом, т.е. алгоритмы работы системы в целом, на высоком уровне.
И то, я как-то почитывал такие патенты — удивлялся.
Похоже, патентируют очевидные вещи сугубо в кач-ве защиты от патентных троллей.
Этим информационным мусором отбили всякое любопытство почитывать западные патенты.
S>А исходный код — это исходный код. В него входит и форматирование, и идентификаторы. ГК РФ запросто разрешает параллельно разрабатывать два кода, один из которых является служебным произведением, а второй — нет.
Да плевать на тонкости реализации и форматирования. ))
Не уверен, что требуется кому-либо объяснять это.
V>>Например, у нас при банальной отсылке данных в сокет совместно работает сразу 3 lock-free алгоритма.
V>>Каждый из них простейший, но их определённая комбинация рождает новый алгоритм более высокого уровня, который умудряется быть тем эффективней, чем больше нагрузка.
S>Хорошо вам.
Там кейз специфический — lock-free очередь обслуживает так же примитив сигнализации, на котором надо ожидать в отсутствии задач или IO.
В дотнете же для тасков используют встроенный пул, который в случае Windows и вовсе системный:
https://docs.microsoft.com/en-us/windows/win32/api/threadpoollegacyapiset/nf-threadpoollegacyapiset-queueuserworkitem
И потоки из пула ожидают на внутренних своих примитивах сигнализации внутри WinaAPI, где нет возможности добавить знание о происходящем в очереди в сам факт манипулирования примитивами сигнализации.
Например, дотнет должен обслуживать как потенциально-легковесную очередь задач самому себе, так и поступающие извне в поток UserWorkItem, даже если они к Task не имеют никакого отношения.
Я же говорю — тут требуется комплексное переосмысление происходящего.
Мне даже очередь таймеров пришлось переосмыслить от классической приоритетной очереди до, скажем так, своей релизации, более подходящей под наши сценарии.
Даже запрос текущего monotonic-системного времени был переосмыслен. ))
Кароч, всё то, что отжирало то тут, то там сотни наносекунд или даже до микросекунды на каждый чих, складываясь в общую задержку.
Стоимость своих альтернативных решений — единицы-десяки наносекунд на каждую такую операцию-кирпичик.
V>>Выглядит как "я хочу на блюдечке с голубой каёмочкой".
V>>Хотел бы по-настоящему, уже бы давал свои соображения по реализации (там есть на что обратить внимание).
S>Не, я не настолько квалифицирован в lock-free алгоритмах.
Ну, сложные lock-free алгоритмы не всегда в реальном использовании обгоняют простые на мьютексах, если блокировки мьютексов короткие и вероятность конфликтов низка.
По настоящему эффективными могут быть только предельно простые lock-free алгоритмы, их можно понять и без специальной подготовки.
Тогда задача перетекает в несколько другую плоскость — попытаться расписать работу всей системы на комбинации отдельных простых lock-free алгоритмов.
Для меня это неотъемлимый контекст по работе, с этих позиций и рассуждал.
Поэтому, нет желания прогибаться под попытку переиначить исходные мои заявления, вычленить и рассмотреть только часть и т.д.
Опять же, дотнетный пул потоков под таски обычно в разы больше кол-ва ядер в системе.
Я как-то замерял — на моих 12 ядрах он создавал под 200 с лишним потоков в пуле на интенсивном использовании.
Поэтому, потенциальное блокирование из-за того, что реализация конкурентной очереди не удовлетворяет гарантиям lock-free, что потенциально может заморозить лишь +1 попавший в конфликт поток — это вроде как приписанное системе допущение. И тогда очередь остальных задач к потоку может разгребаться другими потоками.
Но эта парочка задач-неудачниц будет страдать. ))
Совсем другое дело, когда в нашем пуле ровно столько потоков, сколько ядер, гарантии lock-free соблюдаются, ни один поток не морозится.
Таски, таймеры и IO обслуживаются в этом общем пуле, процессоры переключают контексты исполнения крайне редко — когда нет данных, т.е. можно уйти в спячку до получения сигнала о пробуждении.
V>>И да, замена очереди и переосмысливание всей системы в конце всех концов делает асинхронщину в разы эффективнее, например, как у нас.
S>Ну, вы молоцы. Жалко, что кроме вас, об этом никто не знает
Индустрия знает, мы в лидерах, 1-2-е места по репортам тестовых лабораторий Intel.
V>>Ну, если фанаты будут обсуждать не технику игроков, а их одежду и даже стрижку вратаря — то где-то так и будет.
S>Так а как можно обсуждать технику, которой нет?
Можно обсуждать, какой она могла бы быть.
Тем более, что адрес одного из примеров был дан.
S>Нет кода — нет предмета обсуждения.
Слава богу, очень немногие коллеги так категорично ставят вопрос.
В основе всего лежит идея.
И даже не спорь. ))
"Дайте готовый код" — присказка уставших от жизни ленивцев.
S>Выходит так, что ваша часть дискуссии — это "ваш Месси плохо держит мяч, у меня есть игрок, который делает это лучше. Но я вам его не покажу, потому что он секретный. И вообще — есть множество других игроков, вполне публичных, которые играют лучше Месси. Но я вам их не назову — сами найдите да посмотрите".
Отсылка к футболу была твоей, аналогия малость хромает...
Можно взять аналогию ближе к инженерной, например, сравнить характеристики ракет потенциальных противников, где применённые технологии являются охраняемой тайной.
S>Предлагаю тему свернуть, потому как про воображаемый секретный код мне не очень интересно.
А как другой код поможет тебе понять, что именно происходит в дотнетных тасках сейчас?
Чем тебя не устраивает уже имеющийся дотнетный код для целей анализа происходящего?
Не интересно? (скорее всего)
У меня же не было перед глазами готового решения.
Я должен был проводить анализ происходящего, сравнивать различные подходы, внимательно смотреть как данные циркулируют, где и сколько раз дёргаются примитивы сигнализации, а нужно ли их там дёргать и т.д. и т.п.