Re[16]: Так подойдет, спасибо!
От: StatujaLeha на правах ИМХО
Дата: 16.09.17 22:10
Оценка:
Здравствуйте, _Raz_, Вы писали:

_R_>То есть он не ждет, а выполняет полезную работу. Так понятней, надеюсь


_R_>Я отвечал на то что до скобок.


Полезная работа Parallel.Invoke в целом такая же, как и полезная работа Task.WhenAll.
А вот busy waiting, который может произойти в Parallel.Invoke, можно избежать.

_R_>Так оно в любом случае будет. Не обязательно busy, но будет.


Разница в том, что на этот busy waiting из Parallel.Invoke будут тратится ресурсы потока из тред пула.
Хотя их можно потратить на другую работу.

_R_>Ты там смеющийся смайлик не заметил?


Ах, смайлик!

_R_>И в выделенном, и до выделенного, и после выделенного. Я все пытаюсь тебя подтолкнуть, что Parallel.Invoke это чуть больше запуска потоков — там и некоторая оптимизация и сбор ошибок.


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

_R_>Я спрашивал про тредпул. Как называется его метод отбирающий поток?


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

В свою очередь, хочу напомнить, как мы пришли к этому вопросу.
Ты написал http://rsdn.org/forum/dotnet/6904317.1:
Автор: _Raz_
Дата: 14.09.17

Вот и получилось, что держали-держали поток и сразу вышли

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

Комментарии будут?

_R_>Хватит уже щеки надувать. Ты меня не собеседуешь.


Ой все?
Как-то так выходит, что ты говорил одно, а работает оно иначе
Не смущает?

_R_>
...
_R_>


Авторского примера плз, его же обсуждаем.

_R_>Вот сейчас было ваще на отличненько


Да ладно. Не сравнится, с твоим "хватит щеки надувать" вместо ответа по существу :D

_R_>Значит даю направление: тредпул во всей этой истории не играет ни малейшей роли и ничего ни у кого не отбирает. Так же как и await — да, да, он все еще синтаксический сахар и не важно во что он там разворачивается


Ок, пусть async/await будет считать синтаксическим сахаром.
Но в свою очередь тоже даю тебе направление: иди учи матчасть.

_R_>(кстати, ты и тут ошибаешься: разворачивается async, а не await).


И не перевирай мои слова: я писал "async/await вообще-то заставляют компилятор трансформировать функцию".
А матчасть подучи. Тогда будешь понимать, что async — это флажок компилятору, что функцию надо трансформировать в State Machine, а количество состояний в этой State Machine зависит от количества await-ов.

_R_>А играют тут шедулер и контекст выполнения.


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

Как бы буду рад, если кто-то покажет мне, в чем я заблуждаюсь/не прав.
Код так не тривиальный, может я что-то и упустил.
Но явно я не буду как-то всерьез воспринимать доводы от авторов, которые тупо в матчасти плавают
Re[17]: Так подойдет, спасибо!
От: _Raz_  
Дата: 17.09.17 01:40
Оценка:
Здравствуйте, StatujaLeha, Вы писали:

SL>Полезная работа Parallel.Invoke в целом такая же, как и полезная работа Task.WhenAll.


Ты издеваешься?

SL>А вот busy waiting, который может произойти в Parallel.Invoke, можно избежать.

SL>Разница в том, что на этот busy waiting из Parallel.Invoke будут тратится ресурсы потока из тред пула.

Ты точно издеваешься. В первом предложении это предположение, а во втором уже утверждение.

SL>Хотя их можно потратить на другую работу.


Ну ты же понимаешь насколько это ерунда.

SL>Если можно, не подталкивай, а просто покажи


Ты же видел исходник Parallel.Invoke полностью и сказал, что понял его. Если ты его понял, то что тебе еще показать? Разницу между одной строкой и 197-ю строками?

SL>До сих пор ты только пишешь и ничем свои доводы не обосновываешь.

SL>При этом пример кода, когда твои слова явно не соответствуют действительности, уже был приведен.

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

SL>Ок, признаю: тред пул не отбирает поток.

SL>Поток тредпула, выделенный на задачу, сам туда возвращается

Это же твоя базовая аргументация:

Потоками тредпул рулит. А не таски.
И выделенное сообщение: суть await-а в том, что при его достижении тредпула отберет поток у задачи и не будет назначать до тех пор, пока таска под await-ом не завершится.


Хотя, да — в главном то ты прав

SL>Как все поменялось!


По-твоему не значительно?

SL>В свою очередь, хочу напомнить, как мы пришли к этому вопросу.

SL>Ты написал http://rsdn.org/forum/dotnet/6904317.1:
Автор: _Raz_
Дата: 14.09.17

SL>

SL>Вот и получилось, что держали-держали поток и сразу вышли

SL>Хотя в предыдущем сообщении была ссылка на листинг, из которого явно видно, что поток нифига не держится таской.

В собственном глазу соринку не замечаешь? "и в следующий раз будет разбужена только по завершении всех задач.".

SL>Как-то так выходит, что ты говорил одно, а работает оно иначе

SL>Не смущает?

Не смеши меня.

SL>Авторского примера плз, его же обсуждаем.


В авторском коде нет ни одного await-а.

_R_>>(кстати, ты и тут ошибаешься: разворачивается async, а не await).

SL>И не перевирай мои слова: я писал "async/await вообще-то заставляют компилятор трансформировать функцию".

Я и не перевираю. И ниже ты сам подтверждаешь мои слова — await не заставляет трансформировать функцию.

SL>А матчасть подучи. Тогда будешь понимать, что async — это флажок компилятору, что функцию надо трансформировать в State Machine, а количество состояний в этой State Machine зависит от количества await-ов.


Оставь менторский тон для зеркала.

SL>Вот ты постоянной что-то пишешь и ничем свои доводы не подкрепляешь.

SL>А уже ведь было выяснено, что твои доводы бывают явно не верными.

Вот нравится мне твоя категоричность. Это юношеский максимализм, похоже.

SL>Как бы буду рад, если кто-то покажет мне, в чем я заблуждаюсь/не прав.

SL>Код так не тривиальный, может я что-то и упустил.

Ты главное упустил — никому не интересно сколько ресурсов занимает ожидание.
... << RSDN@Home 1.3.108 alpha 5 rev. 56>>
Re[18]: Так подойдет, спасибо!
От: StatujaLeha на правах ИМХО
Дата: 18.09.17 21:55
Оценка:
Здравствуйте, _Raz_, Вы писали:

_R_>Ты издеваешься?


Так аргументируй, если не согласен.
Показал бы, где я не прав

_R_>Ты точно издеваешься. В первом предложении это предположение, а во втором уже утверждение.


Нет. Просто ты уже за отсутствием аргументов цепляешься к словам
А сценарий, где это busy waiting возникает, выше был приведен. Для него это утверждение справедливо.

_R_>Ну ты же понимаешь насколько это ерунда.


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

_R_>Ты же видел исходник Parallel.Invoke полностью и сказал, что понял его. Если ты его понял, то что тебе еще показать? Разницу между одной строкой и 197-ю строками?


Понимаешь, я посмотрел исходники Parallel.Invoke и там 198 строк. И это учитывая заглавие функции, комментарии, пустые строки, строки, где какая-нибудь фигня написана, типа одной скобки, логирование.
Строк, реализующих логику, в лучшем случае половина. Как видишь, строк только формально 198

А еще, я посмотрел исходники Task.WhenAll.
И ты удивишься, но там в сумме выходит 124 строки, при чем комментов и прочего барахла поменьше

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

_R_>Для меня очевидно, что ты мухлюешь и передергиваешь.


Really?
А я думаю, что мухлеж и передергивание — это вот только что выше от тебя было, при сравнении размера кода Paralle.Invoke и Task.WhenAll
Ты при этом еще и выделил слово "полностью"

_R_>И твои голословные обвинения идут лесом.


Код, который явно работает не так, как ты писал, я не убирал и не подправлял

_R_>И тот кусок был приведен тобой для подтверждения твоей же позиции — как тут я могу быть не прав?


Ну и кто тут передергивает и мухлюет?
Ты не согласился с моим утверждением и сделал свое(ссылку на него я привел).
Я признал, что в моем утверждении есть неточности и поправил их.
И привел пример того, как твои слова полностью противоречат тому, как работает.

_R_>К тому-же позициции, которую ты поменял в двух последовательных сообщениях.


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

_R_>Это же твоя базовая аргументация:

_R_>

_R_>Потоками тредпул рулит. А не таски.
_R_>И выделенное сообщение: суть await-а в том, что при его достижении тредпула отберет поток у задачи и не будет назначать до тех пор, пока таска под await-ом не завершится.


_R_>Хотя, да — в главном то ты прав


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

SL>>Как все поменялось!


В контексте вопроса, из которого зародился этот спор, не поменялось ничего.

_R_>"и в следующий раз будет разбужена только по завершении всех задач.".


Это утверждение я пока не снимал
Если считаешь, что оно не справедливо, то вперед, буду рад, если опровергнешь

_R_>Не смеши меня.


Да это не смешно...

_R_>В авторском коде нет ни одного await-а.


Ок
Если про мой вариант, то тогда этого:
Task.Run(() => first()).ContinueWith(async (_) => await Task.WhenAll(Task.Run(after1), Task.Run(after2), Task.Run(after3))).Unwrap().Wait();


_R_>Я и не перевираю. И ниже ты сам подтверждаешь мои слова — await не заставляет трансформировать функцию.


Я вижу, что ты очень креативно повыдергивал слова из моего утверждения. У меня была пара async/await, ты оставил только async. И вуаля, "он не прав"!

_R_>Оставь менторский тон для зеркала.


Нет смысла, я и так постоянно что-то изучаю.

_R_>Вот нравится мне твоя категоричность. Это юношеский максимализм, похоже.


А, т.е. если тебя просят подкрепить свои слова чем-то, то это сразу юношеский максимализм?
Класс, чо.

_R_>Ты главное упустил — никому не интересно сколько ресурсов занимает ожидание.


Дак я согласен, что наша дискуссия может оказаться бесплодной. Какие-нибудь 1-2% по времени.

Ранее ты писал, что "играют тут шедулер и контекст выполнения".
Прояснишь ситуацию? Или "маэстро" не видит в этом необходимости?
Re[19]: Так подойдет, спасибо!
От: _Raz_  
Дата: 19.09.17 18:24
Оценка:
Здравствуйте, StatujaLeha, Вы писали:

SL>Так аргументируй, если не согласен.

SL>Показал бы, где я не прав

Так ты выдвигаешь голословные утверждения. Я не собираюсь искать аргументы против категоричного и для меня очевидно ошибочного "Полезная работа Parallel.Invoke в целом такая же, как и полезная работа Task.WhenAll.".

_R_>>Ты точно издеваешься. В первом предложении это предположение, а во втором уже утверждение.

SL>Нет. Просто ты уже за отсутствием аргументов цепляешься к словам

Аргументируй, если не согласен.

_R_>>Ну ты же понимаешь насколько это ерунда.

SL>Если ты имеешь ввиду, что выигрыш от исключения busy waiting в приведенном мной сценарии мизерный, то, может и так.
SL>У меня замеров нет, но допускаю, что мы говорим о каких-то процентах.

Это не мы говорим, это ты говоришь.

SL>Понимаешь, я посмотрел исходники Parallel.Invoke и там 198 строк. И это учитывая заглавие функции, комментарии, пустые строки, строки, где какая-нибудь фигня написана, типа одной скобки, логирование.

SL>А еще, я посмотрел исходники Task.WhenAll.

Опять мухлюешь — здесь речь идет о сравнении с "await Task.WhenAll(Task.Run(after1), Task.Run(after2), Task.Run(after3))"

_R_>>Для меня очевидно, что ты мухлюешь и передергиваешь.

SL>Really?

Да. В каждом посте.

SL>А я думаю, что мухлеж и передергивание — это вот только что выше от тебя было, при сравнении размера кода Paralle.Invoke и Task.WhenAll

SL>Ты при этом еще и выделил слово "полностью"

Да, потому что без подтасовок сравнение было с одной строкой.

_R_>>И твои голословные обвинения идут лесом.

SL>Код, который явно работает не так, как ты писал, я не убирал и не подправлял

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

SL>Ну и кто тут передергивает и мухлюет?

SL>Ты не согласился с моим утверждением и сделал свое(ссылку на него я привел).
SL>Я признал, что в моем утверждении есть неточности и поправил их.
SL>И привел пример того, как твои слова полностью противоречат тому, как работает.

Понимаешь, все это — исключительно в твоей вселенной.

SL>В то же время, твоя позиция до сих пор как была некорректной, так и осталась.

SL>Просто ты этого не признаешь и все.

Просто ты не можешь сформулировать свои мысли. Все что я видел — это голословные обвинения.

SL>Ну как базовая? Она была исходной, но я признал, что там есть неточности, и поправил свою позицию.

SL>В контексте вопроса, из которого зародился этот спор, не поменялось ничего.

Это называется юлить.

_R_>>"и в следующий раз будет разбужена только по завершении всех задач.".

SL>Это утверждение я пока не снимал
SL>Если считаешь, что оно не справедливо, то вперед, буду рад, если опровергнешь

Не хочу идти на новую итерацию сего интереснейшего кхм... разговора.

_R_>>В авторском коде нет ни одного await-а.

SL>Если про мой вариант, то тогда этого:

Не-а. Не буду код писать. Догадаешься почему? Подсказка — дело не во мне.

SL>Я вижу, что ты очень креативно повыдергивал слова из моего утверждения. У меня была пара async/await, ты оставил только async. И вуаля, "он не прав"!


Именно так — только async. И, представь себе, что бы оставить только async — это слово надо выдернуть.

SL>Ранее ты писал, что "играют тут шедулер и контекст выполнения".

SL>Прояснишь ситуацию? Или "маэстро" не видит в этом необходимости?

Необходимости и раньше не было, а вот готовность поговорить об этом была. Но не в подобном русле.
... << RSDN@Home 1.3.108 alpha 5 rev. 56>>
Re[20]: Так подойдет, спасибо!
От: StatujaLeha на правах ИМХО
Дата: 20.09.17 20:27
Оценка:
Здравствуйте, _Raz_, Вы писали:

_R_>Так ты выдвигаешь голословные утверждения. Я не собираюсь искать аргументы против категоричного и для меня очевидно ошибочного "Полезная работа Parallel.Invoke в целом такая же, как и полезная работа Task.WhenAll.".


Настолько "очевидного", что даже не можешь в открытых листингах фреймворка показать, в чем же я не прав

_R_>Опять мухлюешь — здесь речь идет о сравнении с "await Task.WhenAll(Task.Run(after1), Task.Run(after2), Task.Run(after3))"


Ты просто мастер сравнений.
Есть код
await Task.WhenAll(Task.Run(after1), Task.Run(after2), Task.Run(after3))

а есть код
Parallel.Invoke(after1, after2, after3)


Любому первокласснику очевидно, что это в обоих примерах по одной строке кода.
Ну так казалось, до твоего "сравнения"...
Мы же не знали, что надо посмотреть, сколько строк занимает Parallel.Invoke, при этом не смотря на размер Task.WhenAll..
Только тогда станет очевидно, что второй пример в 198 раз больше!
Спасибо, что просвятил!

_R_>>>Для меня очевидно, что ты мухлюешь и передергиваешь.

SL>>Really?

_R_>Да. В каждом посте.


Ясно, понятно. Я не терапевт, дальше бессилен.
В дальнейшей беседе смысла не вижу: в мой адрес уже только и летят фразы "голословные обвинения", а вот с подкреплением делом этих слов пока движа нет
Свои аргументы я изложил, сообщения не редактировал, все на месте. Исходники фреймворка тоже открыты.
Если кому интересно, то проблем чекнуть справедливость моих слов нет. Ну или опровергнуть их
Удачи!
Re[21]: Так подойдет, спасибо!
От: _Raz_  
Дата: 20.09.17 21:46
Оценка:
Здравствуйте, StatujaLeha, Вы писали:

_R_>>Так ты выдвигаешь голословные утверждения. Я не собираюсь искать аргументы против категоричного и для меня очевидно ошибочного "Полезная работа Parallel.Invoke в целом такая же, как и полезная работа Task.WhenAll.".

SL>Настолько "очевидного", что даже не можешь в открытых листингах фреймворка показать, в чем же я не прав

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

SL>Есть код

SL>
SL>await Task.WhenAll(Task.Run(after1), Task.Run(after2), Task.Run(after3))
SL>

SL>а есть код
SL>
SL>Parallel.Invoke(after1, after2, after3)
SL>


И есть твои слова относительно этого кода:

Таски в обоих вариантах запускаются идентично.

Все еще их придерживаешься?

SL>Любому первокласснику очевидно, что это в обоих примерах по одной строке кода.


Не любому, а умеющему юлить и передергивать.

SL>Ну так казалось, до твоего "сравнения"...


Не до моего, а до твоего. Ты не сравнивал количество строк, но ты сравнивал одну строку с WhenAll и кусок фреймворка.

SL>Мы же не знали, что надо посмотреть, сколько строк занимает Parallel.Invoke, при этом не смотря на размер Task.WhenAll..


Конечно, потому что смотрели на вызов из одной строки и всю функцию.

SL>Только тогда станет очевидно, что второй пример в 198 раз больше!


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

SL>Ясно, понятно. Я не терапевт, дальше бессилен.

SL>В дальнейшей беседе смысла не вижу: в мой адрес уже только и летят фразы "голословные обвинения", а вот с подкреплением делом этих слов пока движа нет

Ариведерчи
... << RSDN@Home 1.3.108 alpha 5 rev. 56>>
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.