[00:37:45] <vlad2> http://newsland.com/news/detail/id/937116/
[00:46:56] <jordan36957> Какой ключ у msvc, генерирует только асм код без компиляции?
[00:49:36] <jordan36957> Нашёл, /FA
[01:16:04] <jordan36957> Если хранить в векторе указатели, кэш промахи будут так же, как при использовании списка?
[01:17:14] <vlad2> ХЗ :)
[01:17:29] <vlad2> Такие же как при хранении указателей в массиве
[01:18:39] <jordan36957> Наверно да.
[01:19:38] <vlad2> Почему тебя волнуцют подобные оптимизации?
[01:21:12] <jordan36957> Для общего развития, самая лучшая оптимизация это выбор эффективного алгоритма, то есть тот который подходит для задачи. Да и просто интересуюсь.
[01:26:13] <jordan36957> Читаю вот эту статью об оптимизации http://dev.wikitt.com/wiki/C++/%D0%9E%D0%BF%D1%82%D0%B8%D0%BC%D0%B8%D0%B7%D0%B0%D1%86%D0%B8%D1%8F-%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC-%D0%BD%D0%B0-%D1%8F%D0%B7%D1%8B%D0%BA%D0%B5-C++
[01:27:35] <TRUE> а место, в котором нужен алгоритм, который подходит для задачи, определяется несколькими способами, самый популярный и наглядный из которых - профилировщик.
[01:28:29] <TRUE> Профилировщик обычно запускают, когда кода написано предостаточно. Иногда так случается, что о промахах кэша вообще не вспоминают
[01:29:00] <TRUE> мне, например, никогда до такого уровня спускаться не приходилось
[01:30:37] <valexey> TRUE: зато мне приходилось. :-)
[01:31:06] <valexey> но это действительно когда нужно что-то делать ОЧЕНЬ быстро.
[01:31:18] <valexey> то есть это не бизнес-логика.
[01:32:25] <TRUE> я лишь хотел сказать, что при планировании оптимизации промахи кэша имеют меньший приоритет, чем некоторые другие вещи.
[01:33:04] <jordan36957> Ок.
[01:33:32] <valexey> ну, да. та самая векторизация и ошибка предсказаний переходов - дороже чем промах кэша (в некоторых случаях)
[01:36:37] <valexey> http://users1.jabry.com/adastudio/ada_yes_yes_yes.pdf
[01:45:21] <vlad2> Да, для общего развития неплохая статья (явных ляпов не увидел просмотрев по диагонали).
[01:46:47] <vlad2> (это я про статью об оптимизации)
[01:50:44] <jordan36957> Такой вопрос по статье, часто читал что вызывать системную функцию дорогая операция, но ведь любая библиотека обращается, к примеру к write read в linuxe. Или как всё устроено.
[01:51:05] <valexey> кэшировение/буферизация
[01:51:38] <TRUE> рисовать на экране не точки, а сразу полотно
[01:51:53] <jordan36957> Теперь понял.
[01:52:11] <valexey> то есть то что ты попросил там вывести на консоль или в файл выводится не сразу (то есть не на каждый символ дергается write), а когда явно об этом попросят, или когда буфер закончится.
[01:52:45] <jordan36957> Ок.
[01:52:57] <valexey> jordan36957: но, замечу, это не в любой операционке так. в однозадачных/не защищенных всё иначе таки.
[01:53:05] <TRUE> valexey: i++, ++i, i--, --i особенно в вызовах функций
[01:53:12] <TRUE> а что в вызовах функций?
[01:53:24] <TRUE> это из статьи про аду
[01:53:26] <valexey> ась?
[01:53:29] <jordan36957> i++, ++i, i--, --i  это вечный холивар.
[01:53:39] <TRUE> не, есть различия?
[01:53:47] <TRUE> в яве, например
[01:53:59] <TRUE> а, в яве, вроде, нет
[01:54:23] <TRUE> если эта штука к итераторам не применима
[01:55:19] <valexey> TRUE: ну, имеется ввиде какое значение будет такие передано в функцию. То есть оно там типо не явно, может временная переменная быть передана.
[01:55:22] <TRUE> Использование выражений i++, ++i, i--, --i особенно в вызовах функций
[01:55:45] <valexey> Ну, понятно что у суровых плюсовиков проблем это не вызывает. Но вот у не суровых - да. :-)
[01:56:08] <TRUE> временная переменная с новым значением, да?
[01:56:19] <jordan36957> То есть если операционка умная, то на последующие fget символы будут браться из бцыера. Или юзать fgets и читать самому в буфер.
[01:57:01] <jordan36957> *буфера
[01:59:27] <valexey> jordan36957: это не от операционки зависит, а от библиотеки. От операционки зависит только syscalls.
[02:00:31] <valexey> TRUE: угу. Вообще, проблема например такая. foo(++i, ++i); // с какими параметрами будет вызвана foo?
[02:00:52] <valexey> пусть i=0 до вызова функции.
[02:01:01] <jordan36957> 2
[02:01:12] <TRUE> 1, 2
[02:01:14] <TRUE> ой
[02:01:27] <TRUE> i++, i++
[02:01:28] <valexey> :-)
[02:01:33] <TRUE> 1, 2
[02:01:33] <valexey> :-D
[02:01:40] <valexey> с чего бы? :-)
[02:01:42] <TRUE> если тип сложный
[02:01:53] <valexey> порядок вычисления аргументов функции не определен :-D
[02:01:59] <TRUE> или 1 1
[02:02:05] <valexey> То есть он зависит от реализации.
[02:02:08] <TRUE> а
[02:02:29] <TRUE> то есть, i++ - неопределённое поведение?
[02:02:45] <valexey> Не, это не UB. Это unspecifed behavour вроде бы.
[02:02:52] <valexey> То есть оно как-то будет, но всё будет хорошо.
[02:03:08] <jordan36957> Ну и жуть, для чего вообще нужны разные i++ или ++i.
[02:03:25] <jordan36957> Получается UB на ровном месте
[02:03:28] <valexey> Но это проблема не только с ++i, это с любым действием имеющим побочный эффект.
[02:03:31] <TRUE> то есть - хорошо? 1, 1 и 1, 2 - это не хорошо для меня
[02:03:43] <valexey> foo(boo(); boo());
[02:03:46] <valexey> то же самое.
[02:04:13] <valexey> int boo() {i=i+1; return i;}
[02:04:23] <valexey> В обероне - то же самое будет.
[02:04:51] <TRUE> ++i возвращает тот же объект, а i++ копию, так?
[02:05:13] <valexey> угу
[02:05:37] <jordan36957> Так какой ответ?
[02:05:57] <jordan36957> На это foo(++i, ++i);
[02:05:58] <TRUE> В Обероне не прописано, но предполагается, что будет выполняться в порядке появления в тексте.
[02:06:10] <valexey> TRUE: не предполагается :-)
[02:07:16] <valexey> jordan36957: либо 1,2 либо 2,1 :-)
[02:07:52] <TRUE> это для foo(i++,i++)
[02:08:29] <valexey> для foo(i++, i++); будет уже undefined behavour, то есть будет всё плохо
[02:09:09] <TRUE> а в яве так же?
[02:09:16] <valexey> в случае же foo(++i,++i) будет unspecified behaviour
[02:09:19] <TRUE> я просто никогда этими штуками не пользовался...
[02:09:22] <valexey> в яве - хз.
[02:10:52] <valexey> в жабе так:
[02:10:55] <valexey>

   15.7.4 Argument Lists are Evaluated Left-to-Right

   In a method or constructor invocation or class instance creation expression, argument expressions may appear within the parentheses, separated by commas. Each argument expression appears to be fully evaluated before any part of any argument expression to its right.

[02:18:00] <valexey> так что там порядок определен.
[02:18:16] <valexey> но один фиг в аргументы пихать нечто с побочным эффектом - плохая идея. не годная.
[02:19:48] <jordan36957> Возможно идея наивная, если собрать список вопросв для уточнения рапорта об обероне 07 и послать их Вирту, может он выпустит уточняющий рапорт?
[02:22:09] <valexey> более развернуты репорт не выпустит, но на письмо скорее всего ответит. по пунктам.
[02:47:27] <vlad2> Угу. Ибо в 16 страниц уложиться надо ;)
[02:47:51] <vlad2> Я, кстати, чего-то еще хотел дописать в список. Но уже забыл. Че-то мы тут еще бурно обсуждали.
[03:00:59] <jordan36957> Смысл в этих страницах, если точности нет, каждый пишет компилятор как понимает. Вроде похожи, потом начинаются проблемы, и несовместимости. Можно уменьшить шрифт и вписаться хоть в 10 страниц :-)
[03:03:02] <jordan36957> Интересно, можно ли ещё сократить язык, но оставить его полным по тюрингу, но не сделать из него брэнфак.
[03:09:05] <valexey> можно
[03:09:13] <valexey> выкинут к чертям модули и процедуры
[03:09:15] <valexey> и типы
[03:09:23] <valexey> (достаточно INTEGER'а)
[03:09:31] <valexey> оставить WHILE и выражения
[03:09:42] <valexey> больше вроде бы ничего не нужно
[03:24:47] <vlad2> Будет почти брэйнфак :)
[03:26:26] <vlad2> Все выкидиывания будут только в угоду чему-то, а не по общим соображениям. Потому что выкинуть уже нечего :)
[03:30:17] <valexey> просто будет не general urpose language
[03:30:24] <valexey> а, например, только чисто алгоритмика
[03:30:57] <valexey> то самое подмножество языка, что у Вирта лучше всего описано - всякие IF, циклы и так далее
[03:31:47] <valexey> вполне годится для скриптинга :-)
[03:37:07] <valexey> и для обучению алгоритмике
[03:37:41] <valexey> жаль только, что некоторые профессора никак не поймут, что алгоритмика составляет малую часть от современного программирования.
[03:44:55] <jordan36957> Ты имеешь в виду, изучение сред и библиотек?
[03:45:37] <valexey> я имею ввиду построение языка абстракций.
[03:45:46] <valexey> данной предметной области
[03:45:50] <vlad2> Медлирование предметной области.
[03:46:16] <vlad2> В понятной одновременно для человека и машины форме.
[03:46:41] <valexey> а также механизмов и абстракций служебного назначения, позволяющих поддерживать прграмную систему в работоспособном состоянии.
[03:47:04] <valexey> в частности - адаптировать её к изменяющимся условиям, например изменению предметной области.
[22:50:53] <jordan36957> поэтому большие системы отлично живут на Аде, и хреново живут на Оберонах - Так где используют оберон? Только на оберкоре? :-)
[22:51:50] <valexey> Ну, вон Кемет использует.
[22:52:00] <valexey> Но там не труъ оберон, там модификация толстая :-)
[22:52:16] <valexey> И они потихоньку хотят на Модулу-3 перейти.
[22:52:28] <vlad2> Вирт использует оберон. Весьма успешно, как я понимаю.
[22:52:39] <jordan36957> Для преподавания?
[22:52:47] <vlad2> Ну и для ЛА.
[22:52:53] <jordan36957> ЛА?
[22:53:08] <vlad2> Ну и ОС он написал, специализированную правда.
[22:53:26] <vlad2> Летательный Аппарат
[22:58:07] <jordan36957> Последний язык Вирта, который широко применялся и применяется(?), была модула 2?
[23:02:47] <jordan36957> Сейчас постигаю азы ООП на с++, вроде понятно.
[23:03:24] <jordan36957> Скоро наверно и до лямбд, доберусь. :-)
[23:04:28] <valexey> но это таки мелкие проекты
[23:04:32] <valexey> до 100 000 строк кода
[23:04:40] <TRUE> если цель лямбды, то лучше сразу на них
[23:05:02] <valexey> алсо эту ось он скорее консультировал вроде.
[23:05:04] <TRUE> 100 000 - это уже не мелкие
[23:05:26] <valexey> мелкие. 200-600 - средние
[23:05:34] <valexey> 600 - 2000 крупные
[23:05:39] <valexey> еще больше - очень крупные.
[23:05:57] <jordan36957> А самый большой проэкт по строкам какой?
[23:06:12] <valexey> думаю под сотню миллионов строк кода.
[23:06:30] <jordan36957> Типа windows?
[23:07:19] <valexey> авионика разная думаю. ну и винда тоже, да.
[23:07:36] <valexey> вопрос в том какая надежность требуется. к винде требования пониже.
[23:08:01] <jordan36957> Интересно сколько будут компилится 100 мильёнов строк. Неделю, две?
[23:08:19] <jordan36957> Или зависит от компьютера на котором собирают.
[23:08:22] <valexey> ну, билд-ферма же. думаю день.
[23:08:35] <valexey> компиляция же в основном раздельная.
[23:08:42] <valexey> задача отлично параллелится
[23:09:01] <valexey> ну и надо понимать, что такие проекты живут десятки лет, 10-20-30-40 лет живут. они переживают своих создателей. там сильно другие требования и к языку и инструментарию
[23:09:18] <jordan36957> А если на обычном компе? Просто для интереса, если прикинуть?
[23:13:11] <jordan36957> Алексей и Влад, вы обычно с какими прэктами работаете, в строках?
[23:32:59] <valexey> У меня втечение 2-х лет было экспериментальное. Поэтому проекты мелкие - до 6 тыс строк кода (точнее это одно приложение до 6 тыс. строк кода, приложений таких несколько и они работают в комплексе).
[23:33:09] <valexey> Со следующей недели будет покрупнее :-)
[23:33:18] <vlad2> Я не считал в строках. codebase сейчас для винды - ~100.000 файлов *.cpp/*.h. Там сколько-то мусора (процентов 10).
[23:34:30] <valexey> 100 тыс. файлов?
[23:34:52] <valexey> то есть порядка 10ти лямов строк кода видимо.
[23:35:15] <vlad2> Короче много :)
[23:39:26] <vlad2> В конкретном большом проекте ~3000 единиц компиляции.
[23:39:36] <vlad2> (.cpp)
[23:40:10] <vlad2> C появлением мултикорных компов с компиляцие все хорошо. Минут за 20 можно собрать с нуля.
[23:40:46] <vlad2> Было плохо на маках до появления интеловских процов (~8 часов компилилось).
[23:42:39] <vlad2> Ну и лет 6 назад на винде тоже плохо было - темплейты уже были, а вот процы были слабенькие :)