Здравствуйте, Pzz, Вы писали:
Pzz>А Вы за что платите, за решение проблемы, или за потраченное время?
Pzz>Впрочем, денег у Вас все равно нет, так что ответ не важен
Не, маленько не так. Правильнее: денег я все равно не дам .
Здравствуйте, Gaperton,
GN>>Понятно. Чисто теоретический предел возможностей мозга.
G>Напротив, исключительно практический предел. Один из этих объективных пределов — объем т.н. оперативной памяти мозга. Никакая тренировка не позволит вам запоминать более 9 предметов
[]
Да, это я и называю — теория. Практика — это когда человек сам пишет, и делает выводы.
GN>>Все эти факторы визуально показывают соответствующие средства анализа. Которыми никто не запрещает пользоваться.
G>Как уже говорили — не все.
Примеры будут?
Я вот могу привести примеры: http://files.rsdn.ru/45067/sse.PNG http://files.rsdn.ru/45067/pipeline.PNG
Ну и какой компилятор владеет подобной информацией?
G>И все равно — компилятор сделает это лучше вас и быстрее, так как он железный, и не путается. И начиная с некоторого размера, он вас превзойдет.
Я не поддаюсь убеждениям.
Аргументы с радостью выслушаю.
GN>>Никогда не сталкивался с этим. Погуглил — пока не вижу каких-то подводных камней. Вот Вы, как программист на ассемблере, скажите — а какие там могут быть сложности? Я пока чижу лишь одну — времени может больше уйти на написание.
G>"Больше времени" — не то слово. Время на получение результата такого же качества, как IC++ у вас будет расти быстрее, чем объем кода. И начиная с некоторого, небольшого размера кода — оно начнет скачком сремится к бесконечности.
Стоп. Про время я уже говорил.
Ответа на вопрос так и нет.
Здесь нет никакого ассемблера.
Может ли компилятор принимать подобные решения сам?
С теорией я плохо знаком, но практика говорит — нет.
G>Ваша теоретическая возможность справиться с этой работой за 100 лет, как вы говорите, никому не интересна, и никто ее всерьез рассматривать не будет — всех интересует "то, что они могут использовать в работе." Тема, опять же — для меня очевидна, очевидна на самом деле и вам (я вам уже говорил, что ошибаются все? Ничего, это можно пережить), так что давайте прекратим тратить место на жестком диске сервера RSDN.
Вы опять повторяете мои же слова своим языком.
Теоретически, самый хороший язык — это ассемблер. Знаете как на нём всё быстро будет работать после ручной оптимизации? А если автоматическую прикрутить? Почему же на нём не пишут? Может быть, люди хотят синицу в руках сейчас, а не журавля в небе к старости?
Может быть, не совсем удачно про время я сказал, но этот фактор я и сам прекрасно осознаю.
Итак, других помех ассемблеру, как я вижу, нет.
Кстати, если Вы не забыли — отквоченное говорилось исключительно, что бы показать, что теоретическое преимущество OCaml перед С++ никого не интересует. Теперь мне даказывается, что никого не интересует теоретическое преимущество ассемблера. Браво!
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Здравствуйте, Gaperton,
Pzz>>Впрочем, денег у Вас все равно нет, так что ответ не важен
G>Не, маленько не так. Правильнее: денег я все равно не дам .
Ну, если challenge будет интересным, можно и без денег. Щастье же не в них
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Здравствуйте, c-smile, Вы писали:
CS>Здравствуйте, alexeiz, Вы писали:
CS>>>>>D как язык для UI лучше чем C++ скажем в разы. Это я со всей отвественностью CS>>>>>могу сказать.
A>>>>А причины не трудно описать? По пунктам и конкретно. А то не очень-то верится.
CS>>>1) GC. GC helps a lot managing DOM/windows/elements structure. This is huge in fact. Simplifies significantly code. Makes it clean and compact thus more robust.
A>>Мне кажется, что это просто аргумент в пользу GC, а не конкретно GC для программирования UI. В UI обычно у каждого элемента есть свой owner, который его и освобождает. Так устроено в MFC, QT, да и даже в старом Motif'е. Может быть внутри фреймвока и легче отслеживать время жизни элементов с помощью GC, но для пользователя это никогда не было проблемой.
CS>owner — да но так же есть и reference на parent. Т.е. имеем циклическую ссылку CS>которую естесственным образом в C++ не решить.
Я не знаю есть ли проблема. Покажи мне, например, где данная проблема проявляется в MFC (MFC приводится просто как пример UI библиотеки на C++).
A>>Кстати, о проблемах с GC в UI. Бывает и так: пользователь открывает новое окно/диалог, который отъедает кучу ресурсов. Пользователь закончил свою работу с окном, закрыл его. А ресурсы всё ещё в памяти. GC ни сном ни духом не ведает, что при закрытии окна нужно что-то освободить. А пользователь жалуется. Мол окно уже закрыто, почему программа до сих пор столько памяти держит? И вот GC ждёт пока другое такое ресурсопрожорливое окно откроется, тогда он сразу спохватится, начнёт освобождать. А окно в это время тормозит.
CS>Какое отношение имеет "ресурсопрожорливое окно" к GC?
GC не имеет представления о usage pattern'е. Его работа в данном примере интерферирует с работой пользователя.
A>>Да и на C++ это дело можно сделать, так как GC имеются, а в большинстве случаев smart pointer'ов дольжно быть достаточно.
CS>В теории да. На практике нет.
И в теории и на практике. Существование C++ UI библиотек тому доказательство.
A>>Поэтому тут по возможностям D не перекрывает C++.
CS>Перекрывает именно наличием встроенного GC.
Для C++ есть GC, если тебе это необходимо. Наличие встроенного GC в D не является приемуществом.
CS>>>2) Closures/Delegates. This in fact is not so critical as I am using sinking/bubbling. Let's say it is nice to have feature — allows to simplify code and make it more understandable an regular.
A>>boost::function, boost::signal? win32 gui generics использует этот же механизм. C++ не нужно иметь delegates в языке, т.к. они есть в библиотеке.
CS>к сожалению они не завязяны на GC. CS>Система UI объектов и их ссылок как правило имеет очень сложную струтуру с циклами. CS>Иногда в принципе нельзя отследить кто кого держит. CS>Для таких ситуаций GC это то что доктор прописал. Зело упрощает все эти танцы со смарт указателями.
Мне очень сильно кажется, что у тебя просто архитектура библиотеки опирается на GC. Конечно, ты не представляешь, как твою библиотеку можно реализовать без GC, потому что ты изначально проектировал её, расчитывая на GC, как на один из базовых компонент.
CS>>>3) Properties (getters/setters). Ideally reduces twice methods you need to remember. Again, it is about simplification.
A>>Если бы ты упомянул свойства для создания компонент с их последующем использовании в дизайнере, то это бы имело смысл. А иначе свойства представляют спорный вопрос, опять же не имеющий отношение к UI per se.
CS>Дело вкуса конечно.
CS>>>4) There are more features in D helping UI development e.g. mixins and templates parametrized by character strings, etc., I'll skip them here.
A>>Миксины есть в C++. Curiously recurring template pattern, policies — это всё имеет отношение к миксинам.
CS>Это не те mixins. Вернее не только те.
Я видел примеры, которые ты приводил в одной из дискуссий про D. Они достаточно близко реализумы на C++. Может быть ты предпочитаешь мыслить о миксинах как-то по другому, но для меня связь с приведёнными концепциями C++ очевидна.
Здравствуйте, gear nuke, Вы писали:
G>>Напротив, исключительно практический предел. Один из этих объективных пределов — объем т.н. оперативной памяти мозга. Никакая тренировка не позволит вам запоминать более 9 предметов GN>[]
GN>Да, это я и называю — теория. Практика — это когда человек сам пишет, и делает выводы.
Называйте как хотите. Практика — это когда человек учавствовал в разработке комплексов размером от миллиона строк и выше, причем это было не приложение баз данных. И в поддержке подобных комплексов. Представляет себе на практике, короче, где именно лежит эта пресловутая граница возможностей мозга, и потому не болтает попусту. А форумную болтовню и умствования я называю одним нецензурным словом — на п начинается на ж кончается.
GN>Я не поддаюсь убеждениям. GN>Аргументы с радостью выслушаю.
Помилуйте, я не собираюсь вас ни в чем убеждать — думайте что хотите .
GN>А вот я могу привести элементарный пример, когда компилятор идёт лесом. GN>Проверить n>30 float-ов на принадлежность интервалу
GN>Здесь нет никакого ассемблера.
Пример не в эту ветку. Во-первых, потому, что здесь нет никакого ассемблера.
GN>Может ли компилятор принимать подобные решения сам?
В стремлении победить в споре, вы начинаете приписывать собеседнику собственные фантазии. Я не понимаю с кем вы спорите — судя по этому пассажу — не со мной точно. Найдите какого-нибудь идиота, который будет утверждать что компилятор способен на алгоритмические оптимизации лучше человека (пусть даже низкоуровневые), и спорьте с ним — я такой глупости не говорил.
GN>С теорией я плохо знаком, но практика говорит — нет.
Так ознакомьтесь с "теорией" — и не будете путать алгоритмическую оптимизацию с оптимизациями при кодогенерации. Теория еще не вредила ни одному практику. А вот плохое с ней знакомство — вредит постоянно. Как в работе, так и при трудоустройстве.
Здравствуйте, Gaperton, Вы писали:
G>Называйте как хотите. Практика — это когда человек учавствовал в разработке комплексов размером от миллиона строк и выше, причем это было не приложение баз данных. И в поддержке подобных комплексов. Представляет себе на практике, короче, где именно лежит эта пресловутая граница возможностей мозга, и потому не болтает попусту. А форумную болтовню и умствования я называю одним нецензурным словом — на п начинается на ж кончается.
То есть, Вы участвовали в подобных проектах, написанных полностью на ассемблере? Мы же о нём говорим.
GN>>А вот я могу привести элементарный пример, когда компилятор идёт лесом. GN>>Проверить n>30 float-ов на принадлежность интервалу
GN>>Здесь нет никакого ассемблера. G>Пример не в эту ветку. Во-первых, потому, что здесь нет никакого ассемблера.
А Вы в понятие ассемблер что вкладываете? mov eax, ebx? — дык это просто мнемоники, этимим мнемониками можно и С программу переписать, только в последнем случае компилятор С скорее всего победит.
Ассемблер предполагает использование машинно-зависимых представлений данных и операций над ними. Что и было проделано в моём случае. Ну что ж, внешне всё это закомуфлировано под С, но за такой код могут и руки оторвать!
И, кстати, возвращаясь к OCaml — как там у него с подобными трюками?
GN>>Может ли компилятор принимать подобные решения сам? G>В стремлении победить в споре, вы начинаете приписывать собеседнику собственные фантазии.
Я ни о чём не спорю. Подхватил Вашу идею насчёт теоретического преимущества OCaml по скорости, начал проводить параллели, что бы показать, что в теории не только у OCaml всё хорошо.
G>Я не понимаю с кем вы спорите — судя по этому пассажу — не со мной точно. Найдите какого-нибудь идиота, который будет утверждать что компилятор способен на алгоритмическиеоптимизации лучше человека (пусть даже низкоуровневые), и спорьте с ним — я такой глупости не говорил.
Нет там никакой алгоритмической оптимизации. Даже операции сохранились теже. Изменилось только "представление данных", отдаваемых этим операциям. Замена || на | — вот это не может компилятор делать сам — из-за свойств языка. Хотя в простейших случаях — делает.
Подчеркну — в подобных (но более простых) случаях компилятор (именно IC++C) делает аналогичную оптимизацию сам. Я это видел. Так что в теории как раз похоже, что всё Ок. Но на практике не всегда работает.
GN>>С теорией я плохо знаком, но практика говорит — нет. G>Так ознакомьтесь с "теорией" — и не будете путать алгоритмическую оптимизацию с оптимизациями при кодогенерации. Теория еще не вредила ни одному практику. А вот плохое с ней знакомство — вредит постоянно. Как в работе, так и при трудоустройстве.
С какой теорией предлагаете ознакомиться, можно ключевые слова? А то совет очень похож на "как жить дальше"
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Здравствуйте, gear nuke, Вы писали:
GN>Здравствуйте, Gaperton, Вы писали:
G>>Называйте как хотите. Практика — это когда человек учавствовал в разработке комплексов размером от миллиона строк и выше, причем это было не приложение баз данных. И в поддержке подобных комплексов. Представляет себе на практике, короче, где именно лежит эта пресловутая граница возможностей мозга, и потому не болтает попусту. А форумную болтовню и умствования я называю одним нецензурным словом — на п начинается на ж кончается.
GN>То есть, Вы участвовали в подобных проектах, написанных полностью на ассемблере? Мы же о нём говорим.
Ну что вы . Это был С++. И знаете — все равно граница возможностей мозга ощущается очень отчетливо, не как нечто абстрактно-теоретическое, а как нечто вполне конкретное и осязаемое. Для ассемблера хватит сотни тысяч строк, я думаю, чтобы человек ощутил явно эту границу, и не смог за разумные сроки выполнять глобальные оптимизации лучше компьютера. Или даже десятка тыщ — в зависимости от степени связности кода. Речь, естественно, не идет об алгоритмических оптимизациях — их компилятор делать не умеет и не имеет права делать, кстати.
GN>>>А вот я могу привести элементарный пример, когда компилятор идёт лесом. GN>>>Проверить n>30 float-ов на принадлежность интервалу
GN>>>Здесь нет никакого ассемблера. G>>Пример не в эту ветку. Во-первых, потому, что здесь нет никакого ассемблера.
GN>А Вы в понятие ассемблер что вкладываете? mov eax, ebx? — дык это просто мнемоники, этимим мнемониками можно и С программу переписать, только в последнем случае компилятор С скорее всего победит.
Да, ассемблером я называю именно ассемблер в обычном понимании этого слова, а не что-нибудь другое. Программирование на уровне мнемоник, регистров, и адресов.
GN>Ассемблер предполагает использование машинно-зависимых представлений данных и операций над ними. Что и было проделано в моём случае. Ну что ж, внешне всё это закомуфлировано под С, но за такой код могут и руки оторвать!
Ассемблер полагает предельную близость к машине и полное отсутсвие оптимизаций при кодогенерации. Т.е. программируя на ассемблере вы определяете непосредственно команды, их последовательность, регистровые раскладки, и т.д. Компилятор IC++ умеет готовить смесь команд в такой пропорции, чтобы суперскаларные устройства и конвейры были нагружены оптимальным образом. Ваш код на С не содержит соответствующую информацию, и потому далек от ассемблера.
GN>И, кстати, возвращаясь к OCaml — как там у него с подобными трюками?
Никак, по очевидной причине. С ближе к аппаратуре. А ОCaml выше уровнем, чем С. Что дает вам меньше контроля над машиной, но одновременно дает компилятору больше возможностей для агрессивных оптимизаций. Например компилятор хорошо оптимизирует pattern matching — очень приятную конструкцию, отсутствующую в С как явление.
И я это расцениваю скорее как плюс — в конце концов, в редком крайнем случае можно короткой вставкой на С обойтись — линкуется вместе без проблем.
Здравствуйте, Gaperton, Вы писали:
G>Да, ассемблером я называю именно ассемблер в обычном понимании этого слова, а не что-нибудь другое. Программирование на уровне мнемоник, регистров, и адресов.
Никто не мешает вместо мнемоники mov использовать знак = по крайней мере, в мире x86.
А вот операции с флагами, добавил бы.
Программируя только на уровне "мнемоник, регистров, и адресов" человек находится на уровне С.
G>Ассемблер полагает предельную близость к машине и полное отсутсвие оптимизаций при кодогенерации.
У Вашему сведению: ассемблеры уже давно занимаются оптимизацией. Выбирают меньший по размеру опкод при генерации команды.
G>Т.е. программируя на ассемблере вы определяете непосредственно команды, их последовательность, регистровые раскладки, и т.д.
Нет, не угадали. Я могу оставить выбор регистров транслятору. С последовательностью команд тоже можно так делать, но после написания некторого количесва макросов возникнет вопрос целесообразности.
G>Компилятор IC++ умеет готовить смесь команд в такой пропорции, чтобы суперскаларные устройства и конвейры были нагружены оптимальным образом.
Оптимальный — не значит лучший, я правильно понял?
А вот человек используя соответствующие средства анализа может после некоторого количества модификаций исходного кода получить лучший по производительности код. Естественно, лучший — по его субъективной оценке.
Только про время ничего не говорите — мы же его не принимаем в расчёт в нашем теоретическом соревновании.
Кстати, что бы не было иллюзий о компиляторе — смотрим "IA-32 Intel® Architecture Optimization Reference Manual", раздел "Assembly/Compiler Coding Rules" — там все эти правила построения смеси команд расписаны. Конечно же тяжело всё это руками выполнять. И да — ICC некоторые из них иногда нарушает
G>Ваш код на С не содержит соответствующую информацию, и потому далек от ассемблера.
Не понял, какую.
G>ОCaml выше уровнем, чем С. Что дает вам меньше контроля над машиной, но одновременно дает компилятору больше возможностей для агрессивных оптимизаций. Например компилятор хорошо оптимизирует pattern matching — очень приятную конструкцию, отсутствующую в С как явление.
G>И я это расцениваю скорее как плюс — в конце концов, в редком крайнем случае можно короткой вставкой на С обойтись — линкуется вместе без проблем.
Линкуется-то без проблем, но нарушает:
Assembly/Compiler Coding Rule 5. (MH impact, MH generality)
Selectively inline a function where doing so decreases code size or if the function is small and the call site is frequently executed.
и, косвенно:
Assembly/Compiler Coding Rule 7. (ML impact, ML generality)
If there are more than 16 nested calls and returns in rapid succession; consider transforming the program with inline to reduce the call depth.
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
G>Да, ассемблером я называю именно ассемблер в обычном понимании этого слова, а не что-нибудь другое. G>Программирование на уровне мнемоник, регистров, и адресов.
>Никто не мешает вместо мнемоники mov использовать знак = по крайней мере, в мире x86. >А вот операции с флагами, добавил бы. >Программируя только на уровне "мнемоник, регистров, и адресов" человек находится на уровне С.
Ну вот, в пылу дискуссии вы дошли наконец до совершенно некорректного высказывания. В соответствии с тактикой ведения споров, популярной здесь, мне следует теперь методично и неторопливо вас порвать, не так ли? А вам полагается петлять, менять тему, и делать вид, что вы что-то настолько умное имели в виду, что понять это никак невозможно .
Короче, это все несложно проделать, но давайте опустим это. Объяснять ничего больше вам не буду. Потому как мне надоел бессмысленный разговор, мне надоело отвечать на дикие высказывания, и надоели ваши попытки доказать, что вы умнее меня, компилятора IC++, и всех сразу вместе взятых.
Здравствуйте, Gaperton,
G>>Программируя только на уровне "мнемоник, регистров, и адресов" человек находится на уровне С. G>Ну вот, в пылу дискуссии вы дошли наконец до совершенно некорректного высказывания.
Что же в нём некорректного с Вашей точки зрения? Всё выделенное делается в С, в асме можно много больше
G>В соответствии с тактикой ведения споров, популярной здесь, мне следует теперь методично и неторопливо вас порвать, не так ли? А вам полагается петлять, менять тему, и делать вид, что вы что-то настолько умное имели в виду, что понять это никак невозможно.
Прошу обратить внимание на выделенное...
G>Короче, это все несложно проделать, но давайте опустим это. Объяснять ничего больше вам не буду. Потому как мне надоел бессмысленный разговор, мне надоело отвечать на дикие высказывания, и надоели ваши попытки доказать, что вы умнее меня, компилятора IC++, и всех сразу вместе взятых.
бессмысленного спора — я был обвинён в подтасовке результатов, т.к. использовал не какой-то там абстрактный С++ компилятор, который теоретически проигрывает OCaml, а вполне конкретный, который выигрывает.
Вместо аргументации своей точки зрения, Вы старательно начали доказывать, что С++ компиляторы производят код гораздо лучше написанного вручную. Ok, поиграли в эту игру...
И в качестве "логического завершения" спора применён хитрый тактический ход — выше выделил его часть.
Очень подходит под начало:
Сравнивайте gcc с OCamlopt — так будет честно
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
.
Примеры будут? 
А то совет очень похож на "как жить дальше" 
