Здравствуйте, Разраб, Вы писали:
Р>Замерял вывод 1млн интов. Р>питон(!) быстрее печатает. Р>кресты вообще в несколько раз быстрее через cout << x << endl чем релизный код на .net8
Р>PS clang++-11 не понимает числовые литералы с разделителем типа 1000_000. Легкий шок.
Здравствуйте, Разраб, Вы писали:
Р>Замерял вывод 1млн интов.
А для чего это нужно?
Мне сложно представить полезную задачу с таким огромным выводом в консоль. Всё с чем доводилось сталкиваться печатало справку, прогресс работы, логи...
И прямо чтобы это стало камнем преткновения — не натыкался.
Здравствуйте, Михаил Романов, Вы писали:
МР>Здравствуйте, Разраб, Вы писали:
Р>>Замерял вывод 1млн интов. МР>А для чего это нужно? МР>Мне сложно представить полезную задачу с таким огромным выводом в консоль. Всё с чем доводилось сталкиваться печатало справку, прогресс работы, логи... МР>И прямо чтобы это стало камнем преткновения — не натыкался.
Здравствуйте, Разраб, Вы писали:
Р>Замерял вывод 1млн интов. Р>питон(!) быстрее печатает. Р>кресты вообще в несколько раз быстрее через cout << x << endl чем релизный код на .net8
Перенаправлять вывод в файл пробовал, сравнивал результат?
Здравствуйте, Разраб, Вы писали:
Р>Замерял вывод 1млн интов. Р>питон(!) быстрее печатает. Р>кресты вообще в несколько раз быстрее через cout << x << endl чем релизный код на .net8
Думается что дело в буферизации вывода внутри С/С++ рантайма vs вывод каждой строки отдельно.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, pagid_, Вы писали:
_>Здравствуйте, Разраб, Вы писали:
Р>>Замерял вывод 1млн интов. Р>>питон(!) быстрее печатает. Р>>кресты вообще в несколько раз быстрее через cout << x << endl чем релизный код на .net8
_>Перенаправлять вывод в файл пробовал, сравнивал результат?
запускал по ssh (.net8 publish release)
console на экран 31 сек, в файл 11
streamwriter на экран 5 сек, в файл 0.5
Здравствуйте, Разраб, Вы писали:
_>>Перенаправлять вывод в файл пробовал, сравнивал результат?
Р>запускал по ssh (.net8 publish release) Р>console на экран 31 сек, в файл 11 Р>streamwriter на экран 5 сек, в файл 0.5
Наверное рендеринг шрифтов, несколько более долгая операция чем просто посылка байтов в буффер
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S> Наверное рендеринг шрифтов, несколько более долгая операция чем просто посылка байтов в буффер
Вообще, как-то несколько лет назад всплывало обсуждение, что команда Windows признала, что их реализация консоли очень медленная (и кстати, я после этого начал замечать, что если программа выводит очень много в консоль, то стоит свернуть окно консоли и скорость работы может возрасти кратно!)
Они тогда объяснили тем, что консолью никто особо не планировал пользоваться в режиме массового вывода (как в том же Linux) и потому задачи оптимизации никогда не ставилось.
А несколько лет назад это стало уже критичным (там всякие пошли Core Server, облака, ... ) и за задачу взялись.
Но, как я понял, совместимость всё же пришлось оставить и некоторые софтины переключаются туда https://learn.microsoft.com/en-us/windows/console/legacymode
Впрочем, не исключаю, что и для новой консоли разница между выводом на экран и записью в файл может быть заметной.
S>> Наверное рендеринг шрифтов, несколько более долгая операция чем просто посылка байтов в буффер МР>Вообще, как-то несколько лет назад всплывало обсуждение, что команда Windows признала, что их реализация консоли очень медленная (и кстати, я после этого начал замечать что если программа выводит очень много в консоль, то стоит свернуть окно консоли и скорость работы может возрасти кратно!)
Ну это понятно. Если окно не видно, то нафиг его и рендерить. Там же не только вывод строки, но и смещение экрана.
Тут можно посмотреть вывод не одного сообщения, а буфер например 10 кб и по времени если в буфере есть данные, но какое то время не было сообщений
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Михаил Романов, Вы писали:
МР>Но, как я понял, совместимость всё же пришлось оставить и некоторые софтины переключаются туда https://learn.microsoft.com/en-us/windows/console/legacymode
Я переключил system-wide на старую ибо глюки "новой" консоли в FAR мне не понравились категорически.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
CC>Я переключил system-wide на старую ибо глюки "новой" консоли в FAR мне не понравились категорически.
А что именно за проблемы?
Я просто пользуюсь FAR и консоль включена новая (по крайне мере галочка "использовать legacy" не стоит), но никаких особо заметных проблем не вылезло.
Здравствуйте, Михаил Романов, Вы писали:
CC>>Я переключил system-wide на старую ибо глюки "новой" консоли в FAR мне не понравились категорически. МР>А что именно за проблемы?
Я уже точно не помню, год назад было. Выключать обратно неохота, ибо это через ребут
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
CC>Думается что дело в буферизации вывода внутри С/С++ рантайма vs вывод каждой строки отдельно.
Похоже на фирменный стиль mircosoft, в WPF они тоже решили отправлять в видеопамять каждый widget при каждом изменении по отдельности, т. е. каждый раз устанавливая блокировку заново. Причём всё так и оставляют навсегда, покуда их очередное творение совсем не вымрет.
Здравствуйте, pagid_, Вы писали:
_>Здравствуйте, peiv, Вы писали:
P>> P>>Передаешь другой консольной утилите на вход. _>Но жалуешься при этом на именно на скорость вывода на экран
Причем тут экран? вот результаты тестов 8 корки:
console на экран 31 сек, в файл > 11
streamwriter на экран 5 сек, в файл > 0.5
консоль в 20(!) раз медленнее стрима даже в пайплайне
Здравствуйте, Serginio1, Вы писали:
S>>> Наверное рендеринг шрифтов, несколько более долгая операция чем просто посылка байтов в буффер МР>>Вообще, как-то несколько лет назад всплывало обсуждение, что команда Windows признала, что их реализация консоли очень медленная (и кстати, я после этого начал замечать что если программа выводит очень много в консоль, то стоит свернуть окно консоли и скорость работы может возрасти кратно!) S> Ну это понятно. Если окно не видно, то нафиг его и рендерить. Там же не только вывод строки, но и смещение экрана. S> Тут можно посмотреть вывод не одного сообщения, а буфер например 10 кб и по времени если в буфере есть данные, но какое то время не было сообщений
Просто надо делать адекватную архитектуру.
Буфер это одно. К отрисовке он вообще не должен никакого отношения иметь. Программа просто пишет в кольцевой буфер что хочет. Скорость ограничена только скоростью оперативной памяти.
Отрисовка консоли это другое. 60 раз в секунду (или какая там частота экрана у юзера) — брать видимую часть из буфера и отрисовывать её.
В итоге накладных расходов будет около нуля, а юзер получит идеальную скорость отрисовки.
Здравствуйте, vsb, Вы писали:
S>>>> Наверное рендеринг шрифтов, несколько более долгая операция чем просто посылка байтов в буффер МР>>>Вообще, как-то несколько лет назад всплывало обсуждение, что команда Windows признала, что их реализация консоли очень медленная (и кстати, я после этого начал замечать что если программа выводит очень много в консоль, то стоит свернуть окно консоли и скорость работы может возрасти кратно!) S>> Ну это понятно. Если окно не видно, то нафиг его и рендерить. Там же не только вывод строки, но и смещение экрана. S>> Тут можно посмотреть вывод не одного сообщения, а буфер например 10 кб и по времени если в буфере есть данные, но какое то время не было сообщений
vsb>Просто надо делать адекватную архитектуру.
vsb>Буфер это одно. К отрисовке он вообще не должен никакого отношения иметь. Программа просто пишет в кольцевой буфер что хочет. Скорость ограничена только скоростью оперативной памяти.
vsb>Отрисовка консоли это другое. 60 раз в секунду (или какая там частота экрана у юзера) — брать видимую часть из буфера и отрисовывать её.
vsb>В итоге накладных расходов будет около нуля, а юзер получит идеальную скорость отрисовки.
Ну самому то несложно сделать буферизацию. Но консоль то нужна, для того что бы оперативно читать, если скорость отрисовки выше скорости чтения, то зачем вообще выводить на консоль?
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
vsb>>В итоге накладных расходов будет около нуля, а юзер получит идеальную скорость отрисовки. S> Ну самому то несложно сделать буферизацию.
Я про то, как она должна быть сделана в системе, чтобы не нужно было сворачивать cmd.exe для ускорения работы программы (про этот эффект я сам в курсе).
S> Но консоль то нужна, для того что бы оперативно читать, если скорость отрисовки выше скорости чтения, то зачем вообще выводить на консоль?
Хотят и выводят, законом не запрещено. 99.(9)% логов никто никогда не прочитает. Но их всё равно выводят, хранят и индексируют.
Здравствуйте, vsb, Вы писали:
vsb>Хотят и выводят, законом не запрещено. 99.(9)% логов никто никогда не прочитает. Но их всё равно выводят, хранят и индексируют.
Выводят, но не на экран! А только для дальнейшего поиска ошибок, предупреждений итд.
Выводить на экран миллион сообщений, и жаловаться, что медленно это ...
То есть использовать консоль для отладки в современных средствах разработки это какой то атавизм на заре программирования. Помню в том, же турбо-паскале уже консолями не пользовались
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
vsb>>Хотят и выводят, законом не запрещено. 99.(9)% логов никто никогда не прочитает. Но их всё равно выводят, хранят и индексируют. S> Выводят, но не на экран! А только для дальнейшего поиска ошибок, предупреждений итд.
В современных приложениях логи выводятся в stdout. При правильном деплое — да, конечно это всё перенаправляется в файлы и тд. Но если ты в процессе разработки просто запускаешь приложение, то логи выводятся на экран.
S> Выводить на экран миллион сообщений, и жаловаться, что медленно это ...
Это норма. Человек рассчитывает на оптимальную реализацию фундаментальных API.
S> То есть использовать консоль для отладки в современных средствах разработки это какой то атавизм на заре программирования. Помню в том, же турбо-паскале уже консолями не пользовались
Здравствуйте, vsb, Вы писали:
vsb>>>Хотят и выводят, законом не запрещено. 99.(9)% логов никто никогда не прочитает. Но их всё равно выводят, хранят и индексируют. S>> Выводят, но не на экран! А только для дальнейшего поиска ошибок, предупреждений итд.
vsb>В современных приложениях логи выводятся в stdout. При правильном деплое — да, конечно это всё перенаправляется в файлы и тд. Но если ты в процессе разработки просто запускаешь приложение, то логи выводятся на экран.
Ну да, что бы посмотреть результат! Который занимает максимум 10 строчек.
S>> Выводить на экран миллион сообщений, и жаловаться, что медленно это ...
vsb>Это норма. Человек рассчитывает на оптимальную реализацию фундаментальных API.
Это не норма. Это идиотизм! Нахрена миллион строк?
S>> То есть использовать консоль для отладки в современных средствах разработки это какой то атавизм на заре программирования. Помню в том, же турбо-паскале уже консолями не пользовались
vsb>Нет, это не атавизм, это норма.
Для кого? Я не пользуюсь для отладки консолью с миллионами строк!
Не нужно. Это идиотизм!
Опять, же даже для вывода в лог выводят не все сообщения, а по филтрам. И фильтров таких большое количество (информация, предупреждения, ошибки итд)
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, vsb, Вы писали:
vsb>Это норма. Человек рассчитывает на оптимальную реализацию фундаментальных API.
Фундаментальный API как раз работает как надо — каждый вывод гарантирует что ты эту строку увидишь даже если твоя аппа упадёт мордой об стол сразу после.
Это с кэшированными постоянная проблема с необходимостью вручную делать flush чтоб добиться таких же гарантий.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, vsb, Вы писали:
vsb>>Это норма. Человек рассчитывает на оптимальную реализацию фундаментальных API. CC>Фундаментальный API как раз работает как надо — каждый вывод гарантирует что ты эту строку увидишь даже если твоя аппа упадёт мордой об стол сразу после. CC>Это с кэшированными постоянная проблема с необходимостью вручную делать flush чтоб добиться таких же гарантий.
Ну как я раньше писал, нужно надеяться не на кэш, а на задержку между сообщениями.
Но консоль то как раз и интересна тем, что за выводом экрана можно визуально следить.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Разраб, Вы писали:
Р>консоль в 20(!) раз медленнее стрима даже в пайплайне
Ну просто считай что вне unix/linux мира передавать такие объемы информации через перенаправление вывода моветон. И никто и никогда не парился по поводу скорости. Да и мало ли на каких отдельных операциях Net медленнее Си/С++ в десяток раз, не новость это.
