Добрый день! Наверное, вопрос не по адресу, но всё-таки попробую задать. В Алисе, как по мне в инструменте повышения доступности в связи с разделением Яндекса пропала функция тематических новостей. Раньше можно было попросить рассказать новости науки или музыки или еще чего. Сейчас - только выбрать провайдера из списка, где нет таких удобных навыков. Планируется ли вернуть? У меня слабовидящая мама и ей было очень тяжело воспринять исчезновение этой функции
Я также заметил связь прямую между состоянием туалета и отношением к сотрудникам. Если там уродское помещение, двери с щелями до косяка, бумага, рвущаяся еще до попадания в цель, это говорит об экономии на людях. Не удивлюсь если у руководства в таких компаниях свой туалет.
Поэтому на собеседовании я также посещаю и эту комнату :)
ну совсем грубо -- от 0,3 до 1,0 млн итераций цикла сложения двух чисел. Это значит, что до определенного объёма работ -- когда издержки в 0,3 - 1,0 млн итераций более 5% от общего объёма работ -- это будет дорого. Это по сути значит, что чтобы %% по издержкам сравнялись с ThreadPool, длина методов должна стать больше в 300 раз (см. данные по таблицам). Иначе запускать таким образом -- через `new Thread().. Start()` станет дорого.
Блокирующий вызов увеличивает время работы метода, исключая возможность равномерно нагрузить пул: метод типа работает, а по факту не использует CPU.
Причём тут вообще ForkJoinPool в Java?
Алгоритмов пулинга потоков великое множество. В Microsoft сделали пул по-умолчанию и абстракцию SynchronizationContext, которая своим названием скорее путает чем помогает понять что это -- слой абстракции над неким пулом потоков. Поэтому у нас путаное знание о пулах потоков. Он у нас один и нигде не описано как он работает. Это -- проблема, порождающая заблуждения, что блокировки на пуле потоков -- это нормально.
А что не так с async/await?
Один человек из тысячи понимает как он работает. Потому что выглядит просто: как что-то, что не надо изучать, как это работает. А по факту внутри ящик пандоры.
Единственная причина, по которой пул потоков считает свои "статистики" — это возможность блокирующих вызовов в потоках пула. Каким таким интересным образом условный счётчик заблокированных потоков может "испортиться" от использования по назначению?
Вы так категоричны, будто смотрели его код. "Статистиками" ThreadPool является алгоритм предсказания уровня необходимого параллелизма исходя из данных алгоритма Hill Climbing, работающего поверх дискретного преобразования Фурье алгоритмом Гёрцеля. Соответственно данные эти используются для того чтобы понять, сколько потоков необходимо создать. Это прямо влияет на уровень загруженности CPU, что влияет на производительность всей остальной системы. Соответственно его задача -- правильно предсказывать оптимальный уровень параллелизма. Чего он не делает. На определенном уровне количества работы стандартный пул потоков работает в сумме по всем потокам -- медленнее чем собственная реализация в разы. Да и линейно также проигрывает. Блокирующие вызовы тут не при чём: они -- скорее возможность (см. статью) отделить CPU-/IO-bound операции на слое ОС.
Что значит "не предназначен", когда блокирующие вызовы — единственная причина, по которой в пуле бывает потоков больше чем у процессора ядер?
Вы правы относительно предложенной модели компанией Microsoft но абсолютно не правы в целом. Например, в Java нет "стандартного пула потоков". Там их много и у каждого свой алгоритм. То, что сделали work-around не значит, что вставать в блокировку на пуле потоков надо. Вы сталкивались с ситуацией полностью заблокированного пула потоков, когда все потоки там вошли в блокировку? Это значит что пул потоков расширяется до некоторого максимума. Это значит, что каждый последующий вошедший в блокировку поток снижает его пропускную способность и как следствие -- производительность приложения. Наличие workaround'a в ThreadPool для тех, кто не понимает, что так делать не стоит, но чтобы помочь им: чтобы приложение по прежнему отрабатывало. Аналогичный workaround в пуле с авторазблокированием пула в .NET 6. Я против таких workaound'ов. По мне так лучше пусть разработчик учит мат часть. Расплодили async/await и прочих "сахаров" да помощников. Выглядит красиво, а что это по факту никто по сути сказать не может.
Соблюдение закона, который был когда-то установлен? Ну и + что когда СССР распался, там не было столь ошеломляющих данных, ради которых стоило публиковать раньше? :)
Попробуйте https://www.nuget.org/packages/MemoryPools.Collections/. По подключении nuget делаете .AsPooling() между источником и LINQ вызовами и всё. Главное чтобы это участвовало бы в местах с вызовом Dispose над IEnumerator. Например, в foreach(). заворачивает экземпляры инстансов классов от Select/Where/… в пул.
Не соглашусь, во-первых даже если где-то используются разработки Союза не вижу в этом ничего такого. Интел до сих пор использует наработки 80-х в своих процессорах. На кой чёрт отказываться от чего-то хорошего чтобы... Что? Ублажить тех, кто считает это дурными манерами? А во-вторых и с наукой и с технологиями все в порядке. Страну свою надо любить, тогда и замечать начнёте. Что за спутники мы выводим, что за свои спутники мы выводим, что они делают. Там много и науки и технологий
И как им воспользоваться?
Добрый день! Наверное, вопрос не по адресу, но всё-таки попробую задать. В Алисе, как по мне в инструменте повышения доступности в связи с разделением Яндекса пропала функция тематических новостей. Раньше можно было попросить рассказать новости науки или музыки или еще чего. Сейчас - только выбрать провайдера из списка, где нет таких удобных навыков. Планируется ли вернуть? У меня слабовидящая мама и ей было очень тяжело воспринять исчезновение этой функции
Я также заметил связь прямую между состоянием туалета и отношением к сотрудникам. Если там уродское помещение, двери с щелями до косяка, бумага, рвущаяся еще до попадания в цель, это говорит об экономии на людях. Не удивлюсь если у руководства в таких компаниях свой туалет.
Поэтому на собеседовании я также посещаю и эту комнату :)
Ну как бы тому кто видит бпла в таких условиях как-то нет времени разбираться, сколько он грамм и что он несёт.
Поздравляю разработчиков с проходом через ад адаптации, наверняка, кучи легаси кода на работу в Linux )
Там же написано: "всех заинтересованных в разработке на Java, С++, C#, JS, TS". Т.е. не для вас )
С миллионом.
ну совсем грубо -- от 0,3 до 1,0 млн итераций цикла сложения двух чисел. Это значит, что до определенного объёма работ -- когда издержки в 0,3 - 1,0 млн итераций более 5% от общего объёма работ -- это будет дорого. Это по сути значит, что чтобы %% по издержкам сравнялись с ThreadPool, длина методов должна стать больше в 300 раз (см. данные по таблицам). Иначе запускать таким образом -- через `new Thread().. Start()` станет дорого.
Блокирующий вызов увеличивает время работы метода, исключая возможность равномерно нагрузить пул: метод типа работает, а по факту не использует CPU.
Алгоритмов пулинга потоков великое множество. В Microsoft сделали пул по-умолчанию и абстракцию SynchronizationContext, которая своим названием скорее путает чем помогает понять что это -- слой абстракции над неким пулом потоков. Поэтому у нас путаное знание о пулах потоков. Он у нас один и нигде не описано как он работает. Это -- проблема, порождающая заблуждения, что блокировки на пуле потоков -- это нормально.
Один человек из тысячи понимает как он работает. Потому что выглядит просто: как что-то, что не надо изучать, как это работает. А по факту внутри ящик пандоры.
Вы так категоричны, будто смотрели его код. "Статистиками" ThreadPool является алгоритм предсказания уровня необходимого параллелизма исходя из данных алгоритма Hill Climbing, работающего поверх дискретного преобразования Фурье алгоритмом Гёрцеля. Соответственно данные эти используются для того чтобы понять, сколько потоков необходимо создать. Это прямо влияет на уровень загруженности CPU, что влияет на производительность всей остальной системы. Соответственно его задача -- правильно предсказывать оптимальный уровень параллелизма. Чего он не делает. На определенном уровне количества работы стандартный пул потоков работает в сумме по всем потокам -- медленнее чем собственная реализация в разы. Да и линейно также проигрывает. Блокирующие вызовы тут не при чём: они -- скорее возможность (см. статью) отделить CPU-/IO-bound операции на слое ОС.
Вы правы относительно предложенной модели компанией Microsoft но абсолютно не правы в целом. Например, в Java нет "стандартного пула потоков". Там их много и у каждого свой алгоритм. То, что сделали work-around не значит, что вставать в блокировку на пуле потоков надо. Вы сталкивались с ситуацией полностью заблокированного пула потоков, когда все потоки там вошли в блокировку? Это значит что пул потоков расширяется до некоторого максимума. Это значит, что каждый последующий вошедший в блокировку поток снижает его пропускную способность и как следствие -- производительность приложения. Наличие workaround'a в ThreadPool для тех, кто не понимает, что так делать не стоит, но чтобы помочь им: чтобы приложение по прежнему отрабатывало. Аналогичный workaround в пуле с авторазблокированием пула в .NET 6. Я против таких workaound'ов. По мне так лучше пусть разработчик учит мат часть. Расплодили async/await и прочих "сахаров" да помощников. Выглядит красиво, а что это по факту никто по сути сказать не может.
ForkJoinPool в Java:
Соблюдение закона, который был когда-то установлен? Ну и + что когда СССР распался, там не было столь ошеломляющих данных, ради которых стоило публиковать раньше? :)
Ну велосипед - не велосипед, а всё, что связано с лингвистикой у меня трепет вызывает ))
Это очень круто! :)
Ну главный ИТ сайт :) Они просто статьи не пишут через свой редактор, видать :)
Попробуйте https://www.nuget.org/packages/MemoryPools.Collections/. По подключении nuget делаете .AsPooling() между источником и LINQ вызовами и всё. Главное чтобы это участвовало бы в местах с вызовом Dispose над IEnumerator. Например, в foreach(). заворачивает экземпляры инстансов классов от Select/Where/… в пул.
del
Безаварийные пуски, например. Большое дело между прочим.
Наша тоже будет. А что нам, не посещать две? Из принципа чтоли? ;)
Не соглашусь, во-первых даже если где-то используются разработки Союза не вижу в этом ничего такого. Интел до сих пор использует наработки 80-х в своих процессорах. На кой чёрт отказываться от чего-то хорошего чтобы... Что? Ублажить тех, кто считает это дурными манерами? А во-вторых и с наукой и с технологиями все в порядке. Страну свою надо любить, тогда и замечать начнёте. Что за спутники мы выводим, что за свои спутники мы выводим, что они делают. Там много и науки и технологий
Прям бальзам на сердце :)