> Кстати у Вас идет противоречие:
> В прочих случаях никакой Unwrap не нужен
> +
> Unwrap нужен с любым типом результата
Под «любым типом результата» подразумевался не результат функции, а TResult — хоть dynamic, хоть int. Так что тут нет противоречия.
С двойным await каюсь, был невнимателен.
> если будет выбрана перегрузка с простым Action, а внутри окажется таск, то, соответсвенно, это уже будет асинхронная лямбда с возвращаемым типом void.
Не совсем понял, внутри чего окажется таск? И я что-то в три часа ночи уже не соображу, как совместить перегрузку по Action (который и сам синхронный и не возвращает ничего асинхронного) с асинхронной лямбдой? Ну если только не ставить async-и и лямбды бездумно куда ни попадя.
Да, есть проблема, но, как и у g_DiGGeR, проблема в понимании: зачем в Compute передавать Task; a если уж приспичило передавать именно Task, то зачем его там стартовать вместо того, чтобы сразу отдать (безо всякого return await); а если вдруг нужно дождаться результата inner и использовать внутри Compute, то почему не использовать await inner напрямую, без StartNew с асинхронной блямбдой и т.п.?
> Всегда используйте метод-расширение Unwrap для Task.Factory.StartNew()
Вызывать Unwrap после StartNew нужно лишь в случае когда передаётся асинхронный делегат в качестве параметра (как в вашем примере), потому что такой делегат вернёт Task, который завернётся в ещё один Task, и его нужно развернуть. В прочих случаях никакой Unwrap не нужен.
См. http://blogs.msdn.com/b/pfxteam/archive/2011/10/24/10229468.aspx
А dynamic тут вообще не при чём — Unwrap нужен с любым типом результата. Task.Run уже содержит внутри Unwrap() (там, где это нужно), так что да, Run — это не просто StartNew с дефолтными параметрами.
Вместо Unwrap можно использовать двойной await (return await await ...)
CPU-bound задачи вообще никогда не следует заворачивать в асинхронные функции типа ComputeAsync. Если эта задача выполняется при обработке запроса в нагруженном веб-сервисе, то выгоднее вызвать HighCpuFunc() напрямую и синхронно, ибо нет никакого смысла создавать новый поток и переключаться в него. Если же задача выполняется в пользовательском приложении с UI, и нужно позаботиться об отзывчивости, то это задача приложения вызвать Task.Run(() => HighCpuFunc()).
Сигнатура функции типа ComputeAsync() предполагает, что в ней делается I/O-bound задача, и использовать её для CPU-bound — это вводить пользователей этой функции в заблуждение, чреватое серьёзными проблемами.
Имеется в виду то, что в C есть пространство тегов структур/объединений/перечислений, отдельное от пространства имён типов. Т.е. в объявлении «struct T {… }» имя структуры (тег) «T» не является именем типа, ибо настоящим именем типа является «struct T». Отсюда извраты с повсеместным «typedef struct T {… } T»
В С++ это не так — тег класса (и, по аналогии, структуры/объединения/перечисления) автоматически объявляет новый тип, и можно запросто писать «T *t;» вместо «struct T *t;»
А какое из множества равенств (т.е. отношений эквивалентности) вы считаете более «нормальным»:
1) идентичность: a == b истинно лишь когда a и b — один и тот же объект
2) бинарное равенство: a == b истинно лишь когда содержимое a и b одинаково вплоть до каждого бита
3) посимвольное равенство: a == b истинно, если содержат одинаковые символы текста, даже если у них разная кодировка
4) смысловое равенство: a == b истинно, если содержат текст с одинаковым смыслом, даже если отличаются кодировка, регистр, некоторые символы заменены эквивалентами (например, немецкое двойное с) и т.п.
Да не, они напишут такие программы — и переквалифицируются в program manager-ов (теперь буквально). Они будут передавать задания этим программам, переводя требования заказчика на язык, понимаемый ИИ, будут контролировать выполнение задания и его качество, будут нести ответственность за косяки ИИ, будут отчитываться перед боссом (program managers' manager-ом). Wait! Oh, sh…
Кроме того, топливо используется эффективнее, если разгонные импульсы делаются всегда в перицентре эллиптической орбиты, где скорость максимальная (см. https://ru.wikipedia.org/wiki/Эффект_Оберта). Если длительность разгона, требуемая, чтобы достичь другого тела, велика, то имеет смысл его разбить на несколько этапов, постепенно поднимая апоцентр импульсами из перицентра. На иллюстрации видно, что активные участки всегда были в перигее.
Вместо сборки шаблона на сервере сериализуйте эту вашу конфигурацию в JSON, передайте клиенту и раздайте её директивам/контроллерам. Пусть они решают, что конкретно сделать на основе этих данных. Директивы сами могут генерить себе нужные шаблоны, динамически на основе входной конфигурации. Серверу вообще негоже знать о том, кто и как отображает его данные, он должен лишь отдать их и сообщить, какие данные ожидает взамен. Если вы захотите кардинально поменять поведение на клиенте (скажем, не дизейблить контролы, а менять их видимость, или показывать сообщение, или вообще выкинуть Ангуляр и воткнуть что-то другое), то вам нужно будет поменять лишь клиентскую компоненту, и не нужно будет трогать сервер.
То же самое для валидации — сделайте сервисы валидации на клиенте и на сервере, вынесите правила валидации в отдельную модель/конфигурацию, передавайте её обоим сервисам как параметр. Пусть клиент делает свою часть как он умеет, а сервер — свою, и друг о друге им знать не надо.
КДП электросети, зарядного и батареи всяко выше кдп нефтеперерабатывающего завода, который, кстати, тоже потребляет электроэнергию.
> Подсчитано, что всего пара десятков крупнейших кораблей даёт столько же ядовитых выбросов, сколько весь автопарк планеты.
А в расчёте на единицу совершаемой работы? Что было бы, если бы те грузы, которые перевозятся кораблями, перевозились бы автомобилями? Насколько я в курсе, корабельные тихоходные дизели — одни из самых экономичных.
Газ, имхо, всё же лучше тратить на парогазовых установках, а не в двс — и проще, и эффективнее, и безопаснее. И вкладываться лучше в развитие электросетей, потому что появляются новые источники электроэнергии, у которыэ EROEI растёт, а не падает, как у ископаемого топлива, и им нужна сеть. Да и угля ещё много, а его больше особо не на что тратить, кроме как в ТЭС сжигать.
Брать нужно номинальную мощность, а не максимальную. Номинальная мощность для тяговых электродвигателей обычно раза в два-три ниже максимальной, из-за сложного профиля нагрузок. А если там ещё и векторное управление (что наверняка), то кпд не будет падать практически до нуля нагрузки.
Согласно цифрам от EPA, в городском цикле расход 2.7 eL/100 km, против 2.6 eL/100 km на хайвее, так что в городском цикле общий кпд падает не драматично. Плюс отсутствие холостого хода на стоянках перед светофорами. Плюс, электромотору от городского цикла не плохеет так, как двс, для которого это режим повышенного износа, с соотв. уменьшением интервалов ТО.
При нагрузке 25% номинала и выше, кпд привода меняется в пределах ~5% от номинального, что на фоне общего кпд 80-90% сущая мелочь. Проблему нагрузки ниже 25% можно сравнительно легко снять увеличением числа электромоторов (два, четыре) и работой только части из них.
Вот только эти «40-45%, в перспективе 50-55%» нужно ещё умножить на кпд получения топлива для двс, и после этого сравнить с «50%, в перспективе 60%». Заодно сравнить запасы топлива для каждого типа (газ vs нефть).
А если считать по-большому, то нужно ещё добавить затраты на поддержание сети АЗС, затраты на производство и утилизацию моторных и трансмиссионных масел и фильтров, и сравнить со стоимостью поддержания электрохозяйства (пропорционально доле электромобилей в общем потреблении) и амортизацию батареи.
Но такой детальный расчёт довольно сложно сделать, поэтому проще всего просто смотреть на цену километра пробега — в неё косвенно входят все затраты на всех этапах. Разумеется, нужно брать несубсидированные цены на бензин/электроэнергию, и заодно учесть, что Тесла сейчас дорогая не столько из-за технологии, сколько из-за необходимости «снять сливки» с рынка, чтобы покрыть R&D, постройку сети зарядных станций с нуля в одиночку и т.п., и что в ближайшем будущем цены будут ощутимо падать.
Без указания, какая именно ТЭС, говорить о кпд бессмысленно. 35% — это кпд паросиловых установок, которых действительно много понастроили. Но из срок службы заканчивается, и им на смену вводят более современные парогазовые (combined cycle), с кпд от 50% и выше.
Почему? Он с небес даром льётся, что-ли? Где вы проводите границы системы? Если вы не учитываете энергию, затрачиваемую на транспортировку топлива, то нужно также перестать учитывать энергию, затрачиваемую на транспортировку электричества.
> В прочих случаях никакой Unwrap не нужен
> +
> Unwrap нужен с любым типом результата
Под «любым типом результата» подразумевался не результат функции, а TResult — хоть dynamic, хоть int. Так что тут нет противоречия.
С двойным await каюсь, был невнимателен.
> если будет выбрана перегрузка с простым Action, а внутри окажется таск, то, соответсвенно, это уже будет асинхронная лямбда с возвращаемым типом void.
Не совсем понял, внутри чего окажется таск? И я что-то в три часа ночи уже не соображу, как совместить перегрузку по Action (который и сам синхронный и не возвращает ничего асинхронного) с асинхронной лямбдой? Ну если только не ставить async-и и лямбды бездумно куда ни попадя.
Да, есть проблема, но, как и у g_DiGGeR, проблема в понимании: зачем в Compute передавать Task; a если уж приспичило передавать именно Task, то зачем его там стартовать вместо того, чтобы сразу отдать (безо всякого return await); а если вдруг нужно дождаться результата inner и использовать внутри Compute, то почему не использовать await inner напрямую, без StartNew с асинхронной блямбдой и т.п.?
> Всегда используйте метод-расширение Unwrap для Task.Factory.StartNew()
Вызывать Unwrap после StartNew нужно лишь в случае когда передаётся асинхронный делегат в качестве параметра (как в вашем примере), потому что такой делегат вернёт Task, который завернётся в ещё один Task, и его нужно развернуть. В прочих случаях никакой Unwrap не нужен.
См. http://blogs.msdn.com/b/pfxteam/archive/2011/10/24/10229468.aspx
А dynamic тут вообще не при чём — Unwrap нужен с любым типом результата. Task.Run уже содержит внутри Unwrap() (там, где это нужно), так что да, Run — это не просто StartNew с дефолтными параметрами.
Вместо Unwrap можно использовать двойной await (return await await ...)
Сигнатура функции типа ComputeAsync() предполагает, что в ней делается I/O-bound задача, и использовать её для CPU-bound — это вводить пользователей этой функции в заблуждение, чреватое серьёзными проблемами.
В С++ это не так — тег класса (и, по аналогии, структуры/объединения/перечисления) автоматически объявляет новый тип, и можно запросто писать «T *t;» вместо «struct T *t;»
1) идентичность: a == b истинно лишь когда a и b — один и тот же объект
2) бинарное равенство: a == b истинно лишь когда содержимое a и b одинаково вплоть до каждого бита
3) посимвольное равенство: a == b истинно, если содержат одинаковые символы текста, даже если у них разная кодировка
4) смысловое равенство: a == b истинно, если содержат текст с одинаковым смыслом, даже если отличаются кодировка, регистр, некоторые символы заменены эквивалентами (например, немецкое двойное с) и т.п.
То же самое для валидации — сделайте сервисы валидации на клиенте и на сервере, вынесите правила валидации в отдельную модель/конфигурацию, передавайте её обоим сервисам как параметр. Пусть клиент делает свою часть как он умеет, а сервер — свою, и друг о друге им знать не надо.
> Подсчитано, что всего пара десятков крупнейших кораблей даёт столько же ядовитых выбросов, сколько весь автопарк планеты.
А в расчёте на единицу совершаемой работы? Что было бы, если бы те грузы, которые перевозятся кораблями, перевозились бы автомобилями? Насколько я в курсе, корабельные тихоходные дизели — одни из самых экономичных.
Газ, имхо, всё же лучше тратить на парогазовых установках, а не в двс — и проще, и эффективнее, и безопаснее. И вкладываться лучше в развитие электросетей, потому что появляются новые источники электроэнергии, у которыэ EROEI растёт, а не падает, как у ископаемого топлива, и им нужна сеть. Да и угля ещё много, а его больше особо не на что тратить, кроме как в ТЭС сжигать.
Согласно цифрам от EPA, в городском цикле расход 2.7 eL/100 km, против 2.6 eL/100 km на хайвее, так что в городском цикле общий кпд падает не драматично. Плюс отсутствие холостого хода на стоянках перед светофорами. Плюс, электромотору от городского цикла не плохеет так, как двс, для которого это режим повышенного износа, с соотв. уменьшением интервалов ТО.
А если считать по-большому, то нужно ещё добавить затраты на поддержание сети АЗС, затраты на производство и утилизацию моторных и трансмиссионных масел и фильтров, и сравнить со стоимостью поддержания электрохозяйства (пропорционально доле электромобилей в общем потреблении) и амортизацию батареи.
Но такой детальный расчёт довольно сложно сделать, поэтому проще всего просто смотреть на цену километра пробега — в неё косвенно входят все затраты на всех этапах. Разумеется, нужно брать несубсидированные цены на бензин/электроэнергию, и заодно учесть, что Тесла сейчас дорогая не столько из-за технологии, сколько из-за необходимости «снять сливки» с рынка, чтобы покрыть R&D, постройку сети зарядных станций с нуля в одиночку и т.п., и что в ближайшем будущем цены будут ощутимо падать.
Вы взяли максимальную мощность турбины, поделили на максимальную мощность реактора и назвали это кпд? Лихо…
Эффективнее _любых_ электростанций автомобили не могут быть, в силу термодинамики, кардинального отличия режимов и возможностей их оптимизации.