Здравствуйте, DarkEld3r, Вы писали:
DE>Не замечаешь подвоха?
подвоха? — нет. но замечаю объяснение того, что некоторым людям вообще не понятен смысл существования венды.
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Здравствуйте, niXman, Вы писали:
X>Здравствуйте, DiZSl, Вы писали:
DZS>>Мне кажется все в точности наоборот. Скорость компиляции = удобство и скорость разработки. X>а вы постоянно компилируете код, после реализации пары-тройки выражений?
Когда как, но при интенсивной разработке, такой режим работы — норма
DZS>>Впрочем, я встречал людей, которым пофиг на скорость было — они в это время могли чаек попить и помедитировать X>а мне приходилось работать с людьми, которые по несколько раз в день пересобирали проект находясь в стадии разработки...
Это лишь говорит о том, что вы судите по себе
Здравствуйте, DiZSl, Вы писали:
DZS>Это лишь говорит о том, что вы судите по себе
а это не говорит?: DZS>Когда как, но при интенсивной разработке, такой режим работы — норма
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Здравствуйте, niXman, Вы писали:
X>Здравствуйте, DiZSl, Вы писали:
DZS>>Это лишь говорит о том, что вы судите по себе X>а это не говорит?: DZS>>Когда как, но при интенсивной разработке, такой режим работы — норма
Я сразу же оговорился, что допускаю, что кому-то важно кому-то нет. Вы же писали: >>думается мне, что кроме тебя и c-smile, время компиляции больше никого не интересует
Кроме того, могу сказать, что 15 лет назад, когда я учился в универе абсолютно все работали в таком же режиме —
минута кодинга (как правило этого хватало — компиляция, параллельно обдумывание, далее кодинг — компиляция...
П.С. хотя нашему преподу это очень не нравилось, — "надо сначала спроектировать, написать, потом компилировать" — на практике такой метод в разы более медленный по разработке
Здравствуйте, DiZSl, Вы писали:
DZS>Кроме того, могу сказать, что 15 лет назад, когда я учился в универе абсолютно все работали в таком же режиме — DZS>минута кодинга (как правило этого хватало — компиляция, параллельно обдумывание, далее кодинг — компиляция...
разве это нормально?
есть хоть одна рациональная причина делать это? (ну, кроме, помаяться дурью)
DZS>... на практике такой метод в разы более медленный по разработке
ну вот, снова только слова.
есть хоть какое-то обоснование постоянно компилировать код?
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Здравствуйте, niXman, Вы писали:
DZS>>Кроме того, могу сказать, что 15 лет назад, когда я учился в универе абсолютно все работали в таком же режиме — DZS>>минута кодинга (как правило этого хватало — компиляция, параллельно обдумывание, далее кодинг — компиляция... X>разве это нормально? X>есть хоть одна рациональная причина делать это? (ну, кроме, помаяться дурью)
ну смотри — к примеру есть проект и тесты. Если компиляция и прогон тестов занимает пару секунд — то внес изменения — прогнал, внес — прогнал. Это быстрее, чем поменять 10 мест, а потом выяснять, на каком из них стрельнул тест...
Если компиляция и прогон занимает несколько (десятков) минут — то тут уже надо смотреть
E>>Ну кодишь, копилишь, запускаешь, пока работает, кодишь компилишь дальше.... X>а отвлекаться на "компилишь — не компилится — фиксишь, запускаешь — бажет — фиксишь — компилишь" — времени не жалко? наверное приличный процент времени уходит на это? X>я вот "компилю — не компилится — фикшу — снова компилю, запускаю — тестирую — бажет — фикщу — снова компилю" — по определенным стадиям, если проект в разработке. если проект в стадии этапного тестирования — стратегия немного другая.
X>дело в том, что, как я заметил по себе(но есть и еще люди, которые работают по такому же принципу), если стадия разработки — то компиляция и тестирование на этой стадии только отвлекает, и суммарно получаются большие затраты времени, плюс "вылет и головы" контекста мыслей необходимых для реализации конкретной задачи. просто подумай, и, возможно захочешь попробовать
X>по поводу же времени компиляции — зачем же перекомпилировать весь проект? если речь идет о частой компиляции, то, могу предположить, что ты находишься в стадии фиксинга, и, таким образом, врядли фикс затрагивает бОльшую часть проекта. обычно, в компиляции нуждается несколько единиц трансляции. допустим, на компиляцию единици трансляции требуется ~10 сек(должна быть большая единица ), а у нас есть минимум четыре ядра. по своему опыту скажу, что если проект написан не в стиле "main.cpp + все в хидерах", то тут довольно высока вероятность того, что фикс не затронет больше четырех единици трансляции.
Важно не то, как часто ты отвлекаешься на компиляцию и тесты, а то, сколько времени проходит между созданием баги в коде и ее обнаружением. Если ты поправил где-то код и внес ошибку, но при этом сразу это обнаружил — контекст все еще у тебя в голове и ты можешь быстро и не напрягаясь ее поправить. Если после внесения ошибки ты успел переключиться на другую задачу и, например, отредактировать код в другом файле, а уже потом обнаружил ошибку — исправление ошибки потребует больше времени и больших ментальных усилий. Лично я наиболее продуктивно пишу код на питоне с использованием autonose. Это такая тулза, которая запускает тесты тогда, когда ты сохраняешь исходник. Я открывал редактор на одном мониторе а консоль с autonose на другом и сразу видел что что-то сломалось и мог это быстро исправить. Правда чтобы это работало нужен хороший coverage. С плюсами не остается ничего другого, кроме как часто компилировать и запускать тесты.
Здравствуйте, jazzer, Вы писали:
J>Здравствуйте, tlp, Вы писали:
tlp>>Если сравнить gcc и MSVC по всем критериям, все будет совсем не так плохо. Сразу выяснится, что gcc дико медленный и часто генерирует код, хуже, чем MSVC.
J>После таких громких слов неплохо бы и ссылочку привести, в подтверждение
nixman сравнивает скорость выполнения разных кусков кода, у него на гсс скорость куска jahr в 3 раза меньше, чем nixman. Я попробовал запустить этот код в vc2013 — скорость jahr получилась почти такая же, как и nixman,в полтора раза больше, а не в три, как в гсс.) Мне кажется, это что-то говорит о качестве оптимизации и написания std у микрософта — он отлично соптимизировал явно не оптимальный код.
Скорость компиляции имеет значения когда компилишь что-то большое типа qt, boost, etc. Есть разница, компилишь ты что-то сутки или 6 часов.)
nixman сравнивает скорость выполнения разных кусков кода, у него на гсс скорость куска jahr в 3 раза меньше, чем nixman. Я попробовал запустить этот код в vc2013 — скорость jahr получилась почти такая же, как и nixman,в полтора раза больше, а не в три, как в гсс.)
какая версия MSVC, какая архитектура?
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
nixman сравнивает скорость выполнения разных кусков кода, у него на гсс скорость куска jahr в 3 раза меньше, чем nixman. Я попробовал запустить этот код в vc2013 — скорость jahr получилась почти такая же, как и nixman,в полтора раза больше, а не в три, как в гсс.) X>какая версия MSVC, какая архитектура?
Мне кажется, Вы слишком эмоционално реагируете на сравнение разных компиляторов, у всех есть свои плюсы и минусы, компилятор без плюсов перестал бы существовать очень быстро, несмотря на любую поддержку любой корпорации.) Оптимизация, насколько я знаю, традиционно считалась сильной стороной микрософтовского компилятора, именно за это ему прощают ограниченную поддержку стандарта.
nixman сравнивает скорость выполнения разных кусков кода, у него на гсс скорость куска jahr в 3 раза меньше, чем nixman. Я попробовал запустить этот код в vc2013 — скорость jahr получилась почти такая же, как и nixman,в полтора раза больше, а не в три, как в гсс.) Мне кажется, это что-то говорит о качестве оптимизации и написания std у микрософта — он отлично соптимизировал явно не оптимальный код.
Стоп-стоп. А вариант скомпилированный gcc ты на своём компьютере запускал? Иначе мне не понятно, почему из двух версий, что оптимизатор msvc хороший или плохой, так однозначно выбирается первая. Может выравнивание времени работы функций говорит как раз об обратном — оптимизатор msvc настолько плох, что сумел испортить даже уже оптимизированную функцию А похожесть времён просто объясняется, что процессор у nixman медленнее, а у тебя быстрее.
Ну то есть я допускаю, что на этом коде один из компилятором может выдавать результат лучше другого, но нельзя решить какой из них лучше, если запустить на одной машине gcc, а на другой непохожей машине msvc, и потом сравнивать времена работы.
А также не могу не заметить, что приведённый тест неоднозначен (а соответственно плох в разрешении споров) ещё и по следующей причине: в нём замеряется время обработки строки из трёх (!) символов в цикле из десяти миллионов итераций. Что это означает? А то, что (если STL не использует SSO) огромное число времени код занимается не столько обработкой строк, сколько прыжками в crt и обратно для выделения и разрушения буфера под эту крошечную строку. То есть в этом тесте не только приведённый код меряется, но ещё и скорость работы crt на машине. А crt, например, вообще может быть всё равно каким компилятором собрана программа — сам crt собран давно и на него не влияют ни настройки оптимизации, ни выбор компилятора. Это такой же случайный фактор как и частота работы процессора.
В общем, если хотите сравнивать скорость работы программ, то сравнивайте правильно: на одной машине, в одном окружении, с одной версией crt, либо тестируйте код, который от crt зависит минимально (а не вызывает malloc на обработку каждых трёх символов). А сейчас — это не сравнение компиляторов.
У Вас нет ощущения, что Вы до столба докапываетесь?) Если посмотреть на код, то кажется довольно вероятным, что компилятор именно мой код соптимизировал, а не ухудшил код nixman'а, рантайм — это часть компилятора, и я не хотел сравнивать компиляторы, я просто поделился недавно случившимся со мной случаем, желающие могут провести полноценное исследование и поделиться результатами с нами.)
nixman сравнивает скорость выполнения разных кусков кода, у него на гсс скорость куска jahr в 3 раза меньше, чем nixman. Я попробовал запустить этот код в vc2013 — скорость jahr получилась почти такая же, как и nixman,в полтора раза больше, а не в три, как в гсс.) Мне кажется, это что-то говорит о качестве оптимизации и написания std у микрософта — он отлично соптимизировал явно не оптимальный код.
или nixman стал вдвое медленнее в vc2013
(они прознали, что он собирает gcc, и добавили его в черный список )
Имхо, в этом тесте гораздо большее значение имеет качество std, чем оптимизатора.
Я вот никак не могу добиться от gcc std той же скорости, которую я имел с stlport.
J>Скорость компиляции имеет значения когда компилишь что-то большое типа qt, boost, etc. Есть разница, компилишь ты что-то сутки или 6 часов.)
Это ты не мне писал, наверное
Здравствуйте, fdn721, Вы писали:
F>Писать можно по разному. Вот например тот же std::async в gcc просто тупо каждый раз заводит новый поток со всеми накладными расходами, а msvc использует пул потоков. F>100% поддержка стандарта любой ценой это как раз цель для студентов. А сделать нормальную годную реализацию, чтоб она не тормозила и не принесла в будущем кучу проблем требует времени и денег.
Интересно, в VS 2015 исправили эпичный std::call_once, который использовал единственный глобальный мьютекс на все приложение? В 2013 еще так.
А похожесть времён просто объясняется, что процессор у nixman медленнее, а у тебя быстрее. 
)
