Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Да уж. Качественно написано, ничего не скажешь. Для интерпретатора несложного языка не хватает 3 GHz и 2-3 Gb.
Скорее всего достаточно качественно, большинство похожих интерпретаторов близкое быстродействие имеют.
Но я про другое, если посмотреть с другой стороны вот есть питон и его стандартный тест быстродействия pystone,
я тут погуглил и получилось такое:
PowerMac 5400 (180 MHz 603e) = 890
iMac (266 MHz G3) = 4800
Sun (4 x 250 MHz Ultrasparc II) = 2200
Sun (1 x 350 MHz Ultrasparc IIi ) = 2600
Pentium II 266MHz = 2821
Pentium III 450MHz = 5800
Сейчас у меня Pentium E6500 (по современным меркам слабенький) на этот тест выдает 77410.
Что по сути означает что сейчас на питоне вполне можно писать приложения которые 10 лет назад
было необходимо по быстродействию писать на C++.
И при этом пользователи разницы в качестве (как определяешь ее ты) не заметят.
Здравствуйте, FR, Вы писали:
FR>Что по сути означает что сейчас на питоне вполне можно писать приложения которые 10 лет назад FR>было необходимо по быстродействию писать на C++.
То есть 10 лет назад были при качественном написании (на С++) компьютеры того времени вполне справлялись с этой задачей так же, как нынешние компьютеры с многократно увеличенной памятью и частотой могут с ней справиться, если писать даже на Питоне ? Верно. Это вполне подтверждает мою мысль, что при качественном написании для многого вполне хватило бы P-100, ну а коль уж памяти и скорости много — можно тратить понапрасну и писать софт, который работает в 10-20 раз медленнее, чем мог бы.
FR>И при этом пользователи разницы в качестве (как определяешь ее ты) не заметят.
Я ? Скорее мои оппоненты — они по времени реакции определяют. Я же определяю качество совсем иначе
PD>То есть 10 лет назад были при качественном написании (на С++) компьютеры того времени вполне справлялись с этой задачей так же, как нынешние компьютеры с многократно увеличенной памятью и частотой могут с ней справиться, если писать даже на Питоне ? Верно. Это вполне подтверждает мою мысль, что при качественном написании для многого вполне хватило бы P-100, ну а коль уж памяти и скорости много — можно тратить понапрасну и писать софт, который работает в 10-20 раз медленнее, чем мог бы.
Большинство хороших программ написанных скажем на C++ в теории используя например суперкомпиляцию можно ускорить скажем в несколько а то и в 10 раз. Суперкомпиляцию вполне можно заменить на кучу хороших специалистов по оптимизации, наверно нужно все бросать и заняться этим?
Кстати скоро могут наступит совсем тяжелые времена если аппаратура окончательно и быстро повернет в сторону многоядерности то
получится такая ситуация у нас 128 ядер а большинство программ могут максимум утилизовать 5 — 6 из них
Ну и по питону. Я например пишу на нем код эквивалентный по функциональности коду на C++ примерно в три раза быстрее. То есть я могу написать
одинаковую по качеству, но в три раза более функциональную программу чем 10 лет назад, а мой конкурент на C++ не может.
FR>>И при этом пользователи разницы в качестве (как определяешь ее ты) не заметят.
PD>Я ? Скорее мои оппоненты — они по времени реакции определяют. Я же определяю качество совсем иначе
Здравствуйте, FR, Вы писали:
FR>Большинство хороших программ написанных скажем на C++ в теории используя например суперкомпиляцию можно ускорить скажем в несколько а то и в 10 раз.
Едва ли. Все это именно теория. Доказательства есть ?
>Суперкомпиляцию вполне можно заменить на кучу хороших специалистов по оптимизации,
Опять едва ли. Intel C++ делает код, по быстродействию сравнимый с кодом на асме.
>наверно нужно все бросать и заняться этим?
Проще купить Intel C++.
FR>Кстати скоро могут наступит совсем тяжелые времена если аппаратура окончательно и быстро повернет в сторону многоядерности то FR>получится такая ситуация у нас 128 ядер а большинство программ могут максимум утилизовать 5 — 6 из них
Это верно. Более того, пока что работа с многоядерностью более напоминает умелое шаманство, чем нечто такое, что можно применять обычному специалисту, не вдаваясь в детали реализации. Поясню. Вот пишу я заголовок цикла for(int i = 0; i < N; i++) — и не очень вдаюсь, как там это будет реализовано. Полагаюсь на компилятор, что он сделает хорошо. А вот запускаю я поток — и не могу просто написать _beginthreadex, должен еще о десятке факторов думать. Кэш там, к примеру, синхронизация и т.д.
FR>Ну и по питону. Я например пишу на нем код эквивалентный по функциональности коду на C++ примерно в три раза быстрее. То есть я могу написать FR>одинаковую по качеству, но в три раза более функциональную программу чем 10 лет назад,
Ты сейчас можешь написать программу, которую ты называешь одинаковой по качеству с программой на С++ десятилетней давности. Чем гордишься-то ? Тем, что железо стало на порядок мощнее и позволяет тебе транжирить ресурсы ? Так это не твоя заслуга.
>а мой конкурент на C++ не может.
Почему не может ? Он может написать программу, которая использует эти ресурсы как следует, а не транжирит 70-80% из них. Поэтому он может написать то, что ты написать не можешь вообще.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Едва ли. Все это именно теория. Доказательства есть ?
Конечно, все легко гуглится.
Суперкомпиляция делает и алгоритмические оптимизации и выносит все что возможно в compile-time, по сути современные
компиляторы когда оптимизируют вусмерть целые функции заменяя их константой ее и применяют.
>>Суперкомпиляцию вполне можно заменить на кучу хороших специалистов по оптимизации, PD>Опять едва ли. Intel C++ делает код, по быстродействию сравнимый с кодом на асме.
Intel C++ уже научился править архитектуру приложений и делать алгоритмическую оптимизацию?
>>наверно нужно все бросать и заняться этим?
PD>Проще купить Intel C++.
Не поможет.
Кстати лет пять назад не на числодробильных алгоритмах интел часто сливал VC.
PD>Это верно. Более того, пока что работа с многоядерностью более напоминает умелое шаманство, чем нечто такое, что можно применять обычному специалисту, не вдаваясь в детали реализации. Поясню. Вот пишу я заголовок цикла for(int i = 0; i < N; i++) — и не очень вдаюсь, как там это будет реализовано. Полагаюсь на компилятор, что он сделает хорошо. А вот запускаю я поток — и не могу просто написать _beginthreadex, должен еще о десятке факторов думать. Кэш там, к примеру, синхронизация и т.д.
PD>Ты сейчас можешь написать программу, которую ты называешь одинаковой по качеству с программой на С++ десятилетней давности.
Нет я сейчас с теми же трудозатратами могу написать в три раза лучшую программу чем 10 лет назад.
PD>Чем гордишься-то ? Тем, что железо стало на порядок мощнее и позволяет тебе транжирить ресурсы ? Так это не твоя заслуга.
Моя, я уже шесть лет назад писал на питоне, и железнячники лучше шевелились в том числе и для того чтобы мои программы шустрее работали
>>а мой конкурент на C++ не может.
PD>Почему не может ? Он может написать программу, которая использует эти ресурсы как следует, а не транжирит 70-80% из них. Поэтому он может написать то, что ты написать не можешь вообще.
Так у него функциональности будет в три раза меньше, и он будет просто конкурентоспособен.
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Едва ли. Все это именно теория. Доказательства есть ?
FR>Конечно, все легко гуглится. FR>Суперкомпиляция делает и алгоритмические оптимизации и выносит все что возможно в compile-time, по сути современные FR>компиляторы когда оптимизируют вусмерть целые функции заменяя их константой ее и применяют.
Мне не пояснения нужны, а пример того, что эта самая суперкомпиляция хорошо оптимизированную Intel C++ программу ускорила в 10 раз.
>>>Суперкомпиляцию вполне можно заменить на кучу хороших специалистов по оптимизации, PD>>Опять едва ли. Intel C++ делает код, по быстродействию сравнимый с кодом на асме.
FR>Intel C++ уже научился править архитектуру приложений и делать алгоритмическую оптимизацию?
>>>наверно нужно все бросать и заняться этим?
PD>>Проще купить Intel C++.
FR>Не поможет.
Опять же доказательства ?
FR>Кстати лет пять назад не на числодробильных алгоритмах интел часто сливал VC.
Он и у меня однажды слил. Делал программу, VC++, оптимизировал, оптимизировал, а в глубине души думаю — вот как сделаю, откомпилирую ICC и скажу заказчику — а можно еще процентов 10-20 получить, если его купите . Наконец сделал все, что мог, установил триал ICC, запустил — 5% проигрыша. Обидно было
Но все это проценты, а не разы. В разы программу , откомпилированную VC++ или ICC — доказательства, пожалуйста. С исходниками
PD>>Это верно. Более того, пока что работа с многоядерностью более напоминает умелое шаманство, чем нечто такое, что можно применять обычному специалисту, не вдаваясь в детали реализации. Поясню. Вот пишу я заголовок цикла for(int i = 0; i < N; i++) — и не очень вдаюсь, как там это будет реализовано. Полагаюсь на компилятор, что он сделает хорошо. А вот запускаю я поток — и не могу просто написать _beginthreadex, должен еще о десятке факторов думать. Кэш там, к примеру, синхронизация и т.д.
FR>
А что тут смешного ?
PD>>Ты сейчас можешь написать программу, которую ты называешь одинаковой по качеству с программой на С++ десятилетней давности.
FR>Нет я сейчас с теми же трудозатратами могу написать в три раза лучшую программу чем 10 лет назад.
Я тоже с теми же трудозатратами напишу больше, чем 10 лет назад. Ну хотя бы потому, что компилятор работает быстрее, что он удобнее и т.д. Может, не в 3 раза, не считал. Но это не моя заслуга.
PD>>Чем гордишься-то ? Тем, что железо стало на порядок мощнее и позволяет тебе транжирить ресурсы ? Так это не твоя заслуга.
FR>Моя, я уже шесть лет назад писал на питоне, и железнячники лучше шевелились в том числе и для того чтобы мои программы шустрее работали
Ты на питоне играешь на том, что тебе нужно в 3, скажем, раза меньше времени, чтобы написать нечто, чем на С++, при том, что программа будет работать в 3, скажем, раза, медленнее, и памяти кушать в 3 раза больше, но рост того и другого все покроет. Таким образом, ты просто воспользуешься тем, что имел место резкий рост ресурсов, позволяющий тебе писать неэффективный код, так как при таких ресурсах этого никто не заметит.
А вот написать программу, которой и нынешних ресурсов мало, ты можешь ? Я мог 10 лет назад, и могу сейчас. Разумеется, это разные задачи, 10 лет назад я за нынешнюю и не взялся бы. А ты мою задачу нынешнюю решить не сможешь, потому что твой питон сделает тебе код, в 3 раза медленнее, чем мой С++ и вылетишь ты с этим кодом в трубу. Ну а пока твои задачи таковы, что можно себе в 3 раза медленнее делать — делай, на здоровье.
>>>а мой конкурент на C++ не может.
PD>>Почему не может ? Он может написать программу, которая использует эти ресурсы как следует, а не транжирит 70-80% из них. Поэтому он может написать то, что ты написать не можешь вообще.
FR>Так у него функциональности будет в три раза меньше, и он будет просто конкурентоспособен.
Опять же смотря где. В той задаче, о которой я чуть выше написал, где надо все нынешние возможности на 100% задействовать — ты мне вообще не конкурент, так как написать такое не в состоянии на своем питоне. Я могу какие угодно условия по времени разработки ставить, не обращая на тебя внимания (но на других С++ — программистов обращать внимание должен )
Вот сейчас у меня как раз такая задача. Некая обработка картинки размером примерно 500 на 500. Делать могу , что хочу, никаких ограничений. Время — меньше 5 мсек. Пока что получается 7-10. Ничего, будет и 5 .
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Мне не пояснения нужны, а пример того, что эта самая суперкомпиляция хорошо оптимизированную Intel C++ программу ускорила в 10 раз.
Суперкомпиляция пока в детских штанишках, так что пока все скорее в теории, что-то минмимально работающее есть только
для рефала и явы http://www.supercompilers.com/white_paper.shtml.
PD>Опять же доказательства ?
Для большинства программ векторизация основной конек интела мало что даст.
PD>Он и у меня однажды слил. Делал программу, VC++, оптимизировал, оптимизировал, а в глубине души думаю — вот как сделаю, откомпилирую ICC и скажу заказчику — а можно еще процентов 10-20 получить, если его купите . Наконец сделал все, что мог, установил триал ICC, запустил — 5% проигрыша. Обидно было PD>Но все это проценты, а не разы. В разы программу , откомпилированную VC++ или ICC — доказательства, пожалуйста. С исходниками
Так пять лет назад интел похуже был, а VC почти такой же как сейчас. Точно не помню уже, но раза полтора было.
FR>>
PD>А что тут смешного ?
Сама ситуация.
PD>>>Ты сейчас можешь написать программу, которую ты называешь одинаковой по качеству с программой на С++ десятилетней давности.
FR>>Нет я сейчас с теми же трудозатратами могу написать в три раза лучшую программу чем 10 лет назад.
PD>Я тоже с теми же трудозатратами напишу больше, чем 10 лет назад. Ну хотя бы потому, что компилятор работает быстрее, что он удобнее и т.д. Может, не в 3 раза, не считал. Но это не моя заслуга.
Угу больше процентов на 5.
FR>>Моя, я уже шесть лет назад писал на питоне, и железнячники лучше шевелились в том числе и для того чтобы мои программы шустрее работали
PD>Ты на питоне играешь на том, что тебе нужно в 3, скажем, раза меньше времени, чтобы написать нечто, чем на С++, при том, что программа будет работать в 3, скажем, раза, медленнее, и памяти кушать в 3 раза больше, но рост того и другого все покроет. Таким образом, ты просто воспользуешься тем, что имел место резкий рост ресурсов, позволяющий тебе писать неэффективный код, так как при таких ресурсах этого никто не заметит.
Нет я говорю что такого резкого роста ресурсов не было бы если бы я (и много миллионов других программистов) не писали на питоне (и других не самых быстрых языках).
Так что это ты пользуешься тем что сделал я
Кстати я вообще дважды герой так как немало поработал в игрострое которые является тоже мощным двигателем для железок.
PD>А вот написать программу, которой и нынешних ресурсов мало, ты можешь ? Я мог 10 лет назад, и могу сейчас. Разумеется, это разные задачи, 10 лет назад я за нынешнюю и не взялся бы. А ты мою задачу нынешнюю решить не сможешь, потому что твой питон сделает тебе код, в 3 раза медленнее, чем мой С++ и вылетишь ты с этим кодом в трубу.
Я как раз могу, сейчас я как-раз в основном пишу на C++. Ну и игродел психику сильно портит, после него оптимизаторство практически неизлечимо
PD>Ну а пока твои задачи таковы, что можно себе в 3 раза медленнее делать — делай, на здоровье.
А как же качество?
FR>>Так у него функциональности будет в три раза меньше, и он будет просто конкурентоспособен.
PD>Опять же смотря где. В той задаче, о которой я чуть выше написал, где надо все нынешние возможности на 100% задействовать — ты мне вообще не конкурент, так как написать такое не в состоянии на своем питоне. Я могу какие угодно условия по времени разработки ставить, не обращая на тебя внимания (но на других С++ — программистов обращать внимание должен )
Угу, но ты почему-то не воспринимаешь что в той задаче про которую вел речь я, ты со своим C++ тоже совершенно не конкурент.
Здравствуйте, FR, Вы писали:
FR>Суперкомпиляция пока в детских штанишках, так что пока все скорее в теории, что-то минмимально работающее есть только
Вот когда вырастет и покажет, что умеет в 10 раз ускорять, тогда и поговорим. А пока говорить не о чем. А то, что некоторые компиляторы умеют в compile-time цикл for(i=0; i < 10; i++) k+=i; исполнять — это, конечно, очень интересно , но к серьезной разработке имеет очень небольшое отношение.
FR>Для большинства программ векторизация основной конек интела мало что даст.
Иногда дает, иногда нет. Тут порой то же шаманство, что и с потоками.
FR>Так пять лет назад интел похуже был, а VC почти такой же как сейчас. Точно не помню уже, но раза полтора было.
Я для себя резюме простое сделал — полагаться на то, что ICC даст лучшие результаты, не стоит. Хотя проверить всегда надо.
PD>>Я тоже с теми же трудозатратами напишу больше, чем 10 лет назад. Ну хотя бы потому, что компилятор работает быстрее, что он удобнее и т.д. Может, не в 3 раза, не считал. Но это не моя заслуга.
FR>Угу больше процентов на 5.
Может быть.
PD>>Ты на питоне играешь на том, что тебе нужно в 3, скажем, раза меньше времени, чтобы написать нечто, чем на С++, при том, что программа будет работать в 3, скажем, раза, медленнее, и памяти кушать в 3 раза больше, но рост того и другого все покроет. Таким образом, ты просто воспользуешься тем, что имел место резкий рост ресурсов, позволяющий тебе писать неэффективный код, так как при таких ресурсах этого никто не заметит.
FR>Нет я говорю что такого резкого роста ресурсов не было бы если бы я (и много миллионов других программистов) не писали на питоне (и других не самых быстрых языках).
Срочно перехожу на JavaScript. Он, как я понимаю, медленнее всего (если не так — скажи, что там медленнее всего, перейду на него). Пусть производители мне ресурсы увеличивают
FR>Так что это ты пользуешься тем что сделал я
PD>>А вот написать программу, которой и нынешних ресурсов мало, ты можешь ? Я мог 10 лет назад, и могу сейчас. Разумеется, это разные задачи, 10 лет назад я за нынешнюю и не взялся бы. А ты мою задачу нынешнюю решить не сможешь, потому что твой питон сделает тебе код, в 3 раза медленнее, чем мой С++ и вылетишь ты с этим кодом в трубу.
FR>Я как раз могу, сейчас я как-раз в основном пишу на C++.
То-то и оно. Как припрет — забудете вы все , господа и про свои языки, и про свои идеи, и вернетесь на старый добрый С++
PD>>Ну а пока твои задачи таковы, что можно себе в 3 раза медленнее делать — делай, на здоровье.
FR>А как же качество?
Страдает и плачет горючими слезами. Но не могу же я тебе запретить писать некачественно
FR>>>Так у него функциональности будет в три раза меньше, и он будет просто конкурентоспособен.
PD>>Опять же смотря где. В той задаче, о которой я чуть выше написал, где надо все нынешние возможности на 100% задействовать — ты мне вообще не конкурент, так как написать такое не в состоянии на своем питоне. Я могу какие угодно условия по времени разработки ставить, не обращая на тебя внимания (но на других С++ — программистов обращать внимание должен )
FR>Угу, но ты почему-то не воспринимаешь что в той задаче про которую вел речь я, ты со своим C++ тоже совершенно не конкурент.
А вот это еще вопрос. Мне трудно судить, я питона не знаю. В двух словах — что там такое есть, чего в С++ быть не может ? (подчеркиваю, именно так, аргументы вроде "там есть такая навороченная библиотека, какой на С++ ты нигде не найдешь)" — не принимаются.
Здравствуйте, Pavel Dvorkin, Вы писали:
FR>>Я как раз могу, сейчас я как-раз в основном пишу на C++.
PD>То-то и оно. Как припрет — забудете вы все , господа и про свои языки, и про свои идеи, и вернетесь на старый добрый С++
Чушь. Числодробилки это далеко не самое главное. Это было актуально еще 10 лет назад.
Сейчас отрыв веника от проца с памятью настолько высокий, что в большинстве насущных задач уже смысла нет оптимизировать быстродействие вычислений.
А вот ускорять ввод-вывод, вводить кеширование и тд и тд — здесь уже С++ толком ничем помочь и не может.
FR>>Угу, но ты почему-то не воспринимаешь что в той задаче про которую вел речь я, ты со своим C++ тоже совершенно не конкурент.
PD>А вот это еще вопрос. Мне трудно судить, я питона не знаю. В двух словах — что там такое есть, чего в С++ быть не может ?
Теоретически все что на питоне да руби может быть и на ассемблере написано.
Инструменты для С++ практически отсутствуют — и это факт.
Как правило, чем более высокий уровень дает язык, тем лучше получаются на нём высокоуровневые оптимизации.
Чем мощнее инструменты — тем больше времени высвобождается для высокоуровневых оптимизаций.
Ну а буде где затык — спокойно можно критические участки оформить хоть на С++, хоть на ассемблере.
Здравствуйте, Pavel Dvorkin, Вы писали:
>>наверно нужно все бросать и заняться этим?
PD>Проще купить Intel C++.
А если уже используется ICC, как ускорить код без суперкомпиляции ?
PD>Полагаюсь на компилятор, что он сделает хорошо. А вот запускаю я поток — и не могу просто написать _beginthreadex, должен еще о десятке факторов думать. Кэш там, к примеру, синхронизация и т.д.
Это в с++ ты должен думать об этом, ибо либы говенные. Все это должна брать на себя платформа.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Вот когда вырастет и покажет, что умеет в 10 раз ускорять, тогда и поговорим. А пока говорить не о чем. А то, что некоторые компиляторы умеют в compile-time цикл for(i=0; i < 10; i++) k+=i; исполнять — это, конечно, очень интересно , но к серьезной разработке имеет очень небольшое отношение.
Компиляторостроители вовсю пользуются результатами таких теорий.
PD>Я для себя резюме простое сделал — полагаться на то, что ICC даст лучшие результаты, не стоит. Хотя проверить всегда надо.
Угу.
FR>>Нет я говорю что такого резкого роста ресурсов не было бы если бы я (и много миллионов других программистов) не писали на питоне (и других не самых быстрых языках).
PD>Срочно перехожу на JavaScript. Он, как я понимаю, медленнее всего (если не так — скажи, что там медленнее всего, перейду на него). Пусть производители мне ресурсы увеличивают
На руби из популярных языков именно он рекордсмен
FR>>Я как раз могу, сейчас я как-раз в основном пишу на C++.
PD>То-то и оно. Как припрет — забудете вы все , господа и про свои языки, и про свои идеи, и вернетесь на старый добрый С++
Тык я и не забывал никогда, так получалось что или параллельно с чем-то C++ или гибридное приложение.
Насчет будущего правда не так радужно новые языки как раз все больше в нишу C++ целят.
FR>>А как же качество?
PD>Страдает и плачет горючими слезами. Но не могу же я тебе запретить писать некачественно
Написал я тут утилитку на OCaml вернее смесь С++ и Ocaml, притом C++ всего одна низкоуровневая функция каталоги
считывает через NtQueryDirectoryFile, в общем грубо она всякую статистику по файловой системе собирает.
Строит в памяти дерево и много много раз по нему бегает разными функциями. И вот на миллионах файлов смотрю жрет
она метров 500 оперативки, в общем не качественно. Решил на C++ переписать убил столько же времени сколько
на первоначальное написание и добился того что стала жрать гиг оперативки.
Да я знаю что убив еще столько же времени я доведу обратно до 500, а убив еще вдвое больше может и до 300.
Но как-то желания соревноватся с GC OCaml'а (который кстати тут недавно ругали) как-то сразу пропало.
В общем наверно я так и буду некачественно писать
FR>>Угу, но ты почему-то не воспринимаешь что в той задаче про которую вел речь я, ты со своим C++ тоже совершенно не конкурент.
PD>А вот это еще вопрос. Мне трудно судить, я питона не знаю. В двух словах — что там такое есть, чего в С++ быть не может ? (подчеркиваю, именно так, аргументы вроде "там есть такая навороченная библиотека, какой на С++ ты нигде не найдешь)" — не принимаются.
В любых тьюринг полных языках как и в Греции есть все.
Так что быть может, но вопрос как всегда в цене.
Здравствуйте, Ikemefula, Вы писали:
PD>>То-то и оно. Как припрет — забудете вы все , господа и про свои языки, и про свои идеи, и вернетесь на старый добрый С++
I>Чушь.
Прелесть что за аргумент.
>Числодробилки это далеко не самое главное. Это было актуально еще 10 лет назад.
У кого какие задачи, можно было бы понять.
I>Сейчас отрыв веника от проца с памятью настолько высокий, что в большинстве насущных задач уже смысла нет оптимизировать быстродействие вычислений.
Это ты моему заказчику скажи. В моих задачах быстродействие винта вообще ни при чем, а вот по времени сказано уложиться в 5 мсек — и все.
I>А вот ускорять ввод-вывод, вводить кеширование и тд и тд — здесь уже С++ толком ничем помочь и не может.
А здесь вообще никто помочь не может. Скорость в/в определяется ОС. А кеширование почему это на С++ нельзя делать ?
I>Теоретически все что на питоне да руби может быть и на ассемблере написано.
Вот уж это вне сомнения. Хотел бы я посмотреть на нечто такое, что теоретически не может быть написано на ассемблере (то есть в командах процессора )
I>Инструменты для С++ практически отсутствуют — и это факт.
Какие ? Для задач построения сайтов — да, но никто сайты на С++ и не пишет.
I>Как правило, чем более высокий уровень дает язык, тем лучше получаются на нём высокоуровневые оптимизации.
Не согласен. Это может быть верно только в той части, на которую он заточен. Как только надо что-то нетипичное для этого языка сделать — все, плохо. Возьми тот же Linq и попробуй пройди там матрицу не по строкам и не по столбцам, а по диагоналям. Ну а мне все равно на С++.
Здравствуйте, Ikemefula, Вы писали:
I>А если уже используется ICC, как ускорить код без суперкомпиляции ?
Эта самая суперкомпиляция — скорее абстрактное теоретическое понятие, чем реально действующий механизм.
PD>>Полагаюсь на компилятор, что он сделает хорошо. А вот запускаю я поток — и не могу просто написать _beginthreadex, должен еще о десятке факторов думать. Кэш там, к примеру, синхронизация и т.д.
I>Это в с++ ты должен думать об этом, ибо либы говенные. Все это должна брать на себя платформа.
Ну и аргумент. Определять возможности языка наличием или отсутствием библиотек — ну и ну. Не плохие они, а просто для других задач сделаны.
Вот, кстати, пример. Лучшие библиотеки для математики — на Фортране. Следует ли из этого что-то в пользу Фортрана или С++ ?
Здравствуйте, Pavel Dvorkin, Вы писали:
I>>А если уже используется ICC, как ускорить код без суперкомпиляции ?
PD>Эта самая суперкомпиляция — скорее абстрактное теоретическое понятие, чем реально действующий механизм.
Пока что да. Не так давно оптимизирующий компилятор был теоретическим понятием.
I>>Это в с++ ты должен думать об этом, ибо либы говенные. Все это должна брать на себя платформа.
PD>Ну и аргумент. Определять возможности языка наличием или отсутствием библиотек — ну и ну.
Библиотеки являются следствием из языка.
Если для языка нельзя написать хороший инструмент, например, для генерации кода, то естественно и библиотек требующих генерацию кода, никогда не появится.
>Не плохие они, а просто для других задач сделаны.
Потому и не надо нести чушь про расходование ресурсов ибо "для других задач"
Здравствуйте, Pavel Dvorkin, Вы писали:
>>Числодробилки это далеко не самое главное. Это было актуально еще 10 лет назад.
PD>У кого какие задачи, можно было бы понять.
Кол.во задач растет мягко говоря нелинейно.
Задачи, решение которых экономит миллиарды долларов уже давным давно не решаются на С++.
Всё, забудь.
I>>Сейчас отрыв веника от проца с памятью настолько высокий, что в большинстве насущных задач уже смысла нет оптимизировать быстродействие вычислений.
PD>Это ты моему заказчику скажи. В моих задачах быстродействие винта вообще ни при чем, а вот по времени сказано уложиться в 5 мсек — и все.
Такие задачи сейчас уже редкость.
Сейчас, например, актуально оптимизировать логистику — не самый эффективный алгоритм на питоне или хоть джаваскрипте сэкономи предприятию вагон денег и для этого С++ просто не нужен.
Перепиши ты его на самом аццком С++ пользы не увеличится а может и уменьшиться из за того, что для сопровождения придется искать сиплюсника
I>>А вот ускорять ввод-вывод, вводить кеширование и тд и тд — здесь уже С++ толком ничем помочь и не может.
PD>А здесь вообще никто помочь не может. Скорость в/в определяется ОС. А кеширование почему это на С++ нельзя делать ?
Всё можно сделать. Ты уверен, что С++ является наиболее удобным языком для математиков или узких специалистов ?
У меня в этом сильное сомнение.
I>>Инструменты для С++ практически отсутствуют — и это факт. PD>Какие ? Для задач построения сайтов — да, но никто сайты на С++ и не пишет.
Дело не только в сайтах.
Оптимизация, рефакторинг, анализ, генерация кода.
I>>Как правило, чем более высокий уровень дает язык, тем лучше получаются на нём высокоуровневые оптимизации.
PD>Не согласен. Это может быть верно только в той части, на которую он заточен. Как только надо что-то нетипичное для этого языка сделать — все, плохо. Возьми тот же Linq и попробуй пройди там матрицу не по строкам и не по столбцам, а по диагоналям. Ну а мне все равно на С++.
Обход по диагоналям это по твоему высокоуровневая оптимизация ?
Здравствуйте, FR, Вы писали:
PD>>Вот когда вырастет и покажет, что умеет в 10 раз ускорять, тогда и поговорим. А пока говорить не о чем. А то, что некоторые компиляторы умеют в compile-time цикл for(i=0; i < 10; i++) k+=i; исполнять — это, конечно, очень интересно , но к серьезной разработке имеет очень небольшое отношение.
FR>Компиляторостроители вовсю пользуются результатами таких теорий.
Пусть себе пользуются и цикл выше оптимизируют. Пока я не увижу конкретного рецепта, как я (именно я) могу ускорить пусть не в 10, а хотя бы в 2 раза — все это может быть только любопытным фактом. А вот если дашь мне ссылку на то, как это сделать реально в моей программе — я тебе тройки буду ставить ежедневно до конца года
FR>>>Нет я говорю что такого резкого роста ресурсов не было бы если бы я (и много миллионов других программистов) не писали на питоне (и других не самых быстрых языках).
PD>>Срочно перехожу на JavaScript. Он, как я понимаю, медленнее всего (если не так — скажи, что там медленнее всего, перейду на него). Пусть производители мне ресурсы увеличивают
FR>На руби из популярных языков именно он рекордсмен
Заказчик только меня не поймет.
FR>Тык я и не забывал никогда, так получалось что или параллельно с чем-то C++ или гибридное приложение. FR>Насчет будущего правда не так радужно новые языки как раз все больше в нишу C++ целят.
И пусть целят. Пока достаточно задействовать 10% тактовой частоты — пусть резвятся. Когда 100% потребуется задействовать — тогда посмотрим.
Чудес же не может быть. C++ — не совсем точно и не совсем верно, но можно назвать языком с нулевым оверхедом. В нем лишнее не делается, а качество кода отличается от идеального только тем, что оптимизатор все же до идеала довести не может, немного хуже. В новых языках есть оверхед — делается то, что можно не делать. JIT- компиляция, вские проверки и т.д. На это время тратится. И это неустранимо. Лучше С++ в этом плане может быть только язык, который так же, как он , дает мне полное управление, но лучше его по качеству. Тут я согласен — синтаксис и семантика С++ отнюдь не идеал.
FR>Написал я тут утилитку на OCaml вернее смесь С++ и Ocaml, притом C++ всего одна низкоуровневая функция каталоги FR>считывает через NtQueryDirectoryFile, в общем грубо она всякую статистику по файловой системе собирает. FR>Строит в памяти дерево и много много раз по нему бегает разными функциями. И вот на миллионах файлов смотрю жрет FR>она метров 500 оперативки, в общем не качественно. Решил на C++ переписать убил столько же времени сколько FR>на первоначальное написание и добился того что стала жрать гиг оперативки.
Гм... При миллионе файлов и с хранением имени файла (имена каталогов можно хранить один раз, пренебрежем) со средней длиной пусть 30-40 имеем на имена файлов 30-40 Мб. Ну пусть еще оверхед на элемент дерева, байт 16-32, это еще столько же. По идее на 1 миллион файлов можно в 100 Мб уложиться. А больше на что ?
Для 10 миллионов будет 1 Гб, меньше и не сделаешь, если только не позволить себе доступ частями (view на mmf), тут можно и в 64 Кб уложиться, но за счет скорости.
FR>Да я знаю что убив еще столько же времени я доведу обратно до 500, а убив еще вдвое больше может и до 300.
Просто я подозреваю, что ты лишнюю память захватил.
FR>Но как-то желания соревноватся с GC OCaml'а (который кстати тут недавно ругали) как-то сразу пропало. FR>В общем наверно я так и буду некачественно писать
Здравствуйте, Ikemefula, Вы писали:
PD>>Эта самая суперкомпиляция — скорее абстрактное теоретическое понятие, чем реально действующий механизм.
I>Пока что да. Не так давно оптимизирующий компилятор был теоретическим понятием.
Когда будет "нет" — тогда и обсудим. Мне программу писать надо. Если можешь сказать, как мне эту суперкомпиляцию употребить в дело — я тебе благодарен буду, а теоретические вопросы мне сейчас не нужны.
I>>>Это в с++ ты должен думать об этом, ибо либы говенные. Все это должна брать на себя платформа.
PD>>Ну и аргумент. Определять возможности языка наличием или отсутствием библиотек — ну и ну.
I>Библиотеки являются следствием из языка.
Что значит следствием ? Это вообще непонятно. Если же говорить об их наличии, то являются они частью системы программирования или берутся из других источников — какая мне разница. Для меня что вызов strcpy, что вызов GetWindowText — одно и то же.
I>Если для языка нельзя написать хороший инструмент, например, для генерации кода, то естественно и библиотек требующих генерацию кода, никогда не появится.
Ничего не понял. Вроде как такой инструмент компилятором называется.
I>Потому и не надо нести чушь про расходование ресурсов ибо "для других задач"
Слушай, если ты хочешь, чтобы я прекратил с тобой дискуссию, используй такие аргументы и приемы дискутирования. Мне, честно говоря, надоело.
I>Вот в этих "других задач" и пользуй свой С++.
Что я и делаю. А разве я предлагал его использовать для написания сайтов ? Не предлагал и не предложу. У нас и так задач хватает.
Здравствуйте, Pavel Dvorkin, Вы писали:
I>>Библиотеки являются следствием из языка.
PD>Что значит следствием ?
Это значит, что если функции сделаны, как с++, то стоит ожидать бред вроде stl или boost.
А долгая компиляция, макросы, синтаксис означают, что не стоит ожидать появления библиотек с понятным дизайном.
I>>Если для языка нельзя написать хороший инструмент, например, для генерации кода, то естественно и библиотек требующих генерацию кода, никогда не появится.
PD>Ничего не понял. Вроде как такой инструмент компилятором называется.
Сразу видно, ты про генерацию кода ничего не слышал, потому тебе и мерещится компилятор.
Генерация кода — это автоматизация рутины. Как толькл появился хороший фреймворк то многие задачи на оном можно автоматизировать.
А в С++ все надо делать или копипастом, или руками, или выращиванием шаблонов как в стл или буст.
PD>Что я и делаю. А разве я предлагал его использовать для написания сайтов ? Не предлагал и не предложу. У нас и так задач хватает.
Здравствуйте, Pavel Dvorkin, Вы писали:
FR>>Компиляторостроители вовсю пользуются результатами таких теорий.
PD>Пусть себе пользуются и цикл выше оптимизируют. Пока я не увижу конкретного рецепта, как я (именно я) могу ускорить пусть не в 10, а хотя бы в 2 раза — все это может быть только любопытным фактом. А вот если дашь мне ссылку на то, как это сделать реально в моей программе — я тебе тройки буду ставить ежедневно до конца года
А представь завтра выходит такой компилятор и все твои программы мгновенно становятся некачественными
FR>>На руби из популярных языков именно он рекордсмен
PD>Заказчик только меня не поймет.
Зато благодарные потомки тебя не забудут
PD>И пусть целят. Пока достаточно задействовать 10% тактовой частоты — пусть резвятся. Когда 100% потребуется задействовать — тогда посмотрим.
Не ты не понял под новыми языками я имел в виду действительно новые, а не шарп с явой и питоном.
Это гуглевский Go или Ржавчина
или D (хоть и не совсем новый)
Они и 99% вполне могут задействовать.
PD>Чудес же не может быть. C++ — не совсем точно и не совсем верно, но можно назвать языком с нулевым оверхедом. В нем лишнее не делается, а качество кода отличается от идеального только тем, что оптимизатор все же до идеала довести не может, немного хуже. В новых языках есть оверхед — делается то, что можно не делать. JIT- компиляция, вские проверки и т.д. На это время тратится. И это неустранимо. Лучше С++ в этом плане может быть только язык, который так же, как он , дает мне полное управление, но лучше его по качеству. Тут я согласен — синтаксис и семантика С++ отнюдь не идеал.
Ну вот в последнее время по моему и начали появляться реальные кандидаты на замену C++.
PD>Гм... При миллионе файлов и с хранением имени файла (имена каталогов можно хранить один раз, пренебрежем) со средней длиной пусть 30-40 имеем на имена файлов 30-40 Мб. Ну пусть еще оверхед на элемент дерева, байт 16-32, это еще столько же. По идее на 1 миллион файлов можно в 100 Мб уложиться. А больше на что ?
Там не только имена хранились еще всякая доп. информация типа размера файлов, атрибутов и хешей, набегало около 200 — 300 байт на файл. Ну и файлов было немного больше лимона.
PD>Для 10 миллионов будет 1 Гб, меньше и не сделаешь, если только не позволить себе доступ частями (view на mmf), тут можно и в 64 Кб уложиться, но за счет скорости.
Слишком медленно частями там десятки пробежок нужны.
