Вы прекрасно знаете в каких условиях существовал СССР. Варшавский блок был гораздо слабее НАТО, и эту разницу в силе пришлось выравнивать народу СССР. Руководство времён СССР, при всех своих минусах, очень чётко понимало, что можно ждать от НАТО и США в частности. Например, как только у США появилось атомное оружие, они тут же применили его на гражданских людях. Перспективы их действий в отношении нас также позитивом не отличались.
Что меня удивляет в ваших комментариях, это почему вы всего этого не видите или не озвучиваете. Уровень жизни людей характеризуется не только достатком видеомагнитофонов на душу населения. Это, прежде всего, гражданская свобода, возможность получить образование, многое другое.
Многоцелевой космический корабль многоразового использования — это перспективная экономия в квадрате. Особенно при дальнейшем совершенствовании материально-технической базы. Точно также, как переход с телеги на более дорогой и технологичный транспорт не только сэкономил массу денег на перевозку в XX веке, но и вывел социум на совершенной новый уровень жизни. Странно что вы этого не понимаете.
Кстати, если это бесперспективно и «говно», то зачем вы потратили много лет своей жизни на говно? Вам нравилось? Или всё-таки это не говно?
По поводу логичной группировки — вы напишите, напишите. Здесь есть хорошие дизайнеры, с опытом. Почитаете комментарии. А может и правы окажетесь — тогда вообще хорошо.
И — нет, заметка не запоздает. Не помню хорошего обсуждения нового интерфейса Офиса на Хабре.
Ваше утверждение по поводу «великолепного юзабилити» Офиса-2010 как минимум спорно. Хотите рассказать какой это замечательный интерфейс — напишите заметку. С удовольствием почитаю и прокомментирую.
На скриншоте приведён жутко неудобный и перегруженный интерфейс, к которому с трудом привыкаешь, особенно после прошлой версии Офиса. Автор действительно считает приведённую картинку образцом для подражания?
Много вы видели гомогенных массивов и их обработчиков в классических гуишных приложениях? Авторы утверждают, что это позволит сэкономить массу тактов процессора даже для «обычных» программ. Весь вопрос в том, чтобы не превратить код в трудночитаемую кашу.
К сожалению, это опять не про С++, поскольку он гарантирует соответствие между описание класса и его байтовым представлением в памяти. За счёт этого ему удаётся усидеть сразу на двух стульях «достаточно системного» и «объектно-ориентированного» языка.
Это как раз та причина, по которой ничего подобного нет в С++0х и вряд ли будет в следующих версиях. Векторизация данных и функций-членов будет либо реализована в другом языке, который не гарантирует соответствие объявлений классов и их представления в памяти, либо появится какой-то новый подход к написанию программ под С++.
Самый «сильный» комментарий к статье на данный момент, спасибо. Всё написано здраво. Добавить могу лишь следующее.
1. Под Win32 плотно пользуюсь компилятором от M$ начиная с 2003 версии (на самом деле и раньше, но там был небольшой перерыв). Так вот, мои замеры изменения производительности показывают мало заметный прирост скорости при переходе на новую версию компилятора, при этом объём оперативной памяти, который кушает программа, непрерывно увеличивается от версии к версии. И дело здесь не в новых версиях STL (которые, кстати, тоже становятся всё более монструозными от версии к версии; как бы там ни было — я STL не пользуюсь вообще, пользуюсь другим фреймворком). То есть, компилятор особо не спасает в плане скорости.
2. Что касается уродования низкоуровневыми оптимизациями и удорожание поддержки кода — согласен на 100%. Как раз думаю о том, как сделать их максимально прозрачно.
3. По поводу будущих архитектур ПК, могу лишь предположить что всё пока движется ортогонально к тематике статьи: скорее всего, будут повышать параллелизм и увеличивать кэши, так что код по идее не должен тормозить сильнее. Параллелизм будет увеличивать «отрыв» асинхронной и многоядерной структуры ЦП от непараллельной памяти.
Что касается кешей процессора, про это очень хорошо написал автор доклада, ссылку на который я также привёл.
Из таблички хорошо видно, что процессор хорошо растет, размер памяти хорошо растет, bandwidth памяти опять же зашибато, а вот latency со времен VAX — стало всего в три раза лучше. В расчете на такты (последняя строка) — ухудшилось в 150 раз.
…
Напоследок, краткие медитативные цифирки (я брал у себя на домашней машине):
floating point mul: 0.5-4 cycles (на одном ядре)
L1 access (~16-32 kb): ~2-3 cycles
L2 access (~2-4 mb): ~15 cycles
Random Memory Access: ~200 cycles < — !!(прим. mt_)
Sequential Access with Prefetch: ~2 bytes/cycle»
Разумеется, хорошо бы, чтобы компилятор решал за меня эту, а вместе с ней и ещё пару десятков задач. Но когда это будет — неизвестно, и будет ли вообще.
Моя статья — для тех, кого интересует повышение эффективности кода «здесь и сейчас».
Впрочем, это может предполагать и другой подход к написанию кода самим программистом. Поскольку тема для меня новая, могу лишь предполагать.
Насколько будет читаем такой код? Вот интересный вопрос.
Я программист. И хотел бы, в идеале, чтобы за меня эту проблему решал компилятор.
Пока конкретных предложений со стороны разработчиков с++ компиляторов не поступало, я ищу способы делать программы эффективнее самому. С учётом, разумеется, того, что оптимизировать, тем более агрессивно, следует лишь часто исполняемые участки кода.
Критичность моего комментария связана с тем, что, по-моему, ваше изделие несколько не доделано. На мой взгляд, сравнительно грубо обработанный кусок дерева несколько проигрывает белому, идеально гладкому пластику с термическим тиснением, округлыми формами и сравнительно стильным дизайном. Вспомните, положа руку на сердце, как жалко Вам было её разламывать.
Уверен, что после более тонкой обработки и, не побоюсь этого слова, резьбы, именно деревянная флэшка, как у вас, будет выглядеть отменно.
Но, если Вам больше нравится Ваш вариант — комментарий снимаю.
Что меня удивляет в ваших комментариях, это почему вы всего этого не видите или не озвучиваете. Уровень жизни людей характеризуется не только достатком видеомагнитофонов на душу населения. Это, прежде всего, гражданская свобода, возможность получить образование, многое другое.
Кстати, если это бесперспективно и «говно», то зачем вы потратили много лет своей жизни на говно? Вам нравилось? Или всё-таки это не говно?
По поводу логичной группировки — вы напишите, напишите. Здесь есть хорошие дизайнеры, с опытом. Почитаете комментарии. А может и правы окажетесь — тогда вообще хорошо.
И — нет, заметка не запоздает. Не помню хорошего обсуждения нового интерфейса Офиса на Хабре.
1. Под Win32 плотно пользуюсь компилятором от M$ начиная с 2003 версии (на самом деле и раньше, но там был небольшой перерыв). Так вот, мои замеры изменения производительности показывают мало заметный прирост скорости при переходе на новую версию компилятора, при этом объём оперативной памяти, который кушает программа, непрерывно увеличивается от версии к версии. И дело здесь не в новых версиях STL (которые, кстати, тоже становятся всё более монструозными от версии к версии; как бы там ни было — я STL не пользуюсь вообще, пользуюсь другим фреймворком). То есть, компилятор особо не спасает в плане скорости.
2. Что касается уродования низкоуровневыми оптимизациями и удорожание поддержки кода — согласен на 100%. Как раз думаю о том, как сделать их максимально прозрачно.
3. По поводу будущих архитектур ПК, могу лишь предположить что всё пока движется ортогонально к тематике статьи: скорее всего, будут повышать параллелизм и увеличивать кэши, так что код по идее не должен тормозить сильнее. Параллелизм будет увеличивать «отрыв» асинхронной и многоядерной структуры ЦП от непараллельной памяти.
Что касается кешей процессора, про это очень хорошо написал автор доклада, ссылку на который я также привёл.
«Memory latency (cycles) 1.4 210 -150x (!!!!!!).
Из таблички хорошо видно, что процессор хорошо растет, размер памяти хорошо растет, bandwidth памяти опять же зашибато, а вот latency со времен VAX — стало всего в три раза лучше. В расчете на такты (последняя строка) — ухудшилось в 150 раз.
…
Напоследок, краткие медитативные цифирки (я брал у себя на домашней машине):
floating point mul: 0.5-4 cycles (на одном ядре)
L1 access (~16-32 kb): ~2-3 cycles
L2 access (~2-4 mb): ~15 cycles
Random Memory Access: ~200 cycles < — !!(прим. mt_)
Sequential Access with Prefetch: ~2 bytes/cycle»
Моя статья — для тех, кого интересует повышение эффективности кода «здесь и сейчас».
Насколько будет читаем такой код? Вот интересный вопрос.
Пока конкретных предложений со стороны разработчиков с++ компиляторов не поступало, я ищу способы делать программы эффективнее самому. С учётом, разумеется, того, что оптимизировать, тем более агрессивно, следует лишь часто исполняемые участки кода.
Уверен, что после более тонкой обработки и, не побоюсь этого слова, резьбы, именно деревянная флэшка, как у вас, будет выглядеть отменно.
Но, если Вам больше нравится Ваш вариант — комментарий снимаю.