Помогите навести ясность.
Рекламируя функциональные языки, их сторонники утверждают, что программы на этих языках чуть ли не атоматически распараллеливаются.
С другой стороны, уважаемые авторы, резюмируя текущее состояние дел в области автоматического распараллеливания программ — утверждают, что серебряной пули еще нет и даже на горизонте не видно.
В чем подвох?
Ну понятно, что если программа специально разбита на куски, изолированные по данным, с использованием специальных библиотек в императивных языках или специальных языковых конструкций, как в эрланге, будут параллелиться и исполняться эффективно,
но приимуществ собственно функциональной парадигмы тут, вроде, не видно.
Так есть ли в этом плане реальные преимущества у ФЯ?
Здравствуйте, Chrome, Вы писали:
C>Помогите навести ясность. C>Рекламируя функциональные языки, их сторонники утверждают, что программы на этих языках чуть ли не атоматически распараллеливаются. C>С другой стороны, уважаемые авторы, резюмируя текущее состояние дел в области автоматического распараллеливания программ — утверждают, что серебряной пули еще нет и даже на горизонте не видно. C>В чем подвох? C>Ну понятно, что если программа специально разбита на куски, изолированные по данным, с использованием специальных библиотек в императивных языках или специальных языковых конструкций, как в эрланге, будут параллелиться и исполняться эффективно, C>но приимуществ собственно функциональной парадигмы тут, вроде, не видно. C>Так есть ли в этом плане реальные преимущества у ФЯ?
Ключевая фраза у тебя это "чуть ли".
Реально же Ф-код сам собой не становится параллельным. Но распараллелить Ф-код проще. И уж точно проще проектировать параллельную программу с использованием ФП.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, IT, Вы писали: IT>Теоретически или практически?
Возьмем среднестатистическую программу на современном императивном языке, которая создавалась без прицела на параллельное исполнение. Мне видится, что и теоретически и практически, для того, что бы заставить ее параллелиться на многоядерной архитектуре, ее следует переписать.
Возьмем аналогичную программу на функциональном языке.
Возможно ли, Теоретически или практически, не переписывая ее, добиться реального масштабирования на на многоядерной архитектуре?
C>Возможно ли, Теоретически или практически, не переписывая ее, добиться реального масштабирования на на многоядерной архитектуре?
Частично переписывать все равно придется Потому что принуждение к распараллеливанию из ниоткуда не возьмется
А сам вопрос о распараллеливании программы зависит, естественно, от программы
Здравствуйте, VladD2, Вы писали:
VD>Ключевая фраза у тебя это "чуть ли".
VD>Реально же Ф-код сам собой не становится параллельным. Но распараллелить Ф-код проще. И уж точно проще проектировать параллельную программу с использованием ФП.
Ну, поскольку, на фя абсолютно все "проще", пассаж про проектирование параллельной программы является частным случаем этого утверждения. Опустим его.
Мне интересно, рекламируемая уникальная приспособленность фя для параллельного программирования — просто необоснованная реклама,
или некакя теоретическая возможность, по какой то причине не очень реализуемая на практике.
Если второе, то в чем практический затык? Почему не получается?
Здравствуйте, Chrome, Вы писали:
C>Возьмем среднестатистическую программу на современном императивном языке, которая создавалась без прицела на параллельное исполнение. Мне видится, что и теоретически и практически, для того, что бы заставить ее параллелиться на многоядерной архитектуре, ее следует переписать. C>Возьмем аналогичную программу на функциональном языке. C>Возможно ли, Теоретически или практически, не переписывая ее, добиться реального масштабирования на на многоядерной архитектуре?
Дело не в языке. Дело в стиле. Скажем тот же компилятор Nemerle написан на функциональном языке. Но вот исходно он был написан в стиле Красного Дракода и С. Есть и изменяемые общие данные. И куча статических переменных. Хотя большая часть кода написана в функциональном стиле, не так то просто превратить этот код в многопоточный не устранив те самые статические переменные (хотя бы).
Конечно если бы код был написан в 100%-но функциональном стиле, то задачу было бы решить элементарно. Но так не бывает. Даже если вы возьметесь решать сложную вычислительную задача скажем на Хаскеле, то вы все равно будете вынуждены заниматься оптимизациями, а значит и иметь где-то изменяемое состояние. И этого уже может хватить чтобы нельзя было эффективно распараллелить программу.
А так все просто. Функциональный код = отсутствие разделяемого состояния. Отсутствие разделяемого состояния = легкое распараллеливание.
В том же компиляторе основная работа — это типизация методов/функций (операторов в программах по определению во много раз больше чем скажем методов). Методов/функций в большой программе много и если у нас нет глобального вывода типов, то каждый метод можно типизироваться отдельно. А раз так, можно практически линейно масштабировать компилятор путем добавления новых процессоров.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Chrome, Вы писали:
C>Мне интересно, рекламируемая уникальная приспособленность фя для параллельного программирования — просто необоснованная реклама, C>или некакя теоретическая возможность, по какой то причине не очень реализуемая на практике. C>Если второе, то в чем практический затык? Почему не получается?
Если их не много, то FP их может хорошо загрузить. При ленивых вычислениях — их можно делать на других ядрах "про запас", раз всё равно они простаивают. И когда нужда в них возникнет — они уже вычеслены. И данные в основном immutable, то есть не надо синхронизировать кэши ядер при записи данных, и вообще синхронизация не нужна — а в ней одной будут самые большие потери при небольшом количестве ядер.
Когда я в одном проекте на java пробовал ввести параллелизм, то сразу наткнулся на всякие проблемы с архитектурой самой программы. Начиная с того, что один тред итерировал по списку, а другой в это время изменял этот список. Хорошо, к тому времени уже были java.util.concurent контейнеры, специально приспособленные к такой ситуации. А без них — это жизнь на минном поле. В любой момент может выскочить ошибка, и никакими юнит-тестами её обнаружить невозможно.
Если же ядер очень много, сотни и тысячи — то проблема будет не в том, параллелятся или нет вычисления в программе. А в том, что саму архитектуру программного обеспечения надо будет менять — память не будет общей, процессоры не будут связаны со всеми другими, а только с ближайшими. Это совершенно другой способ программировать, более близкий к нейронным сетям, чем к программированию в нынешнем понимании этого процесса.
В таких условиях будет лучше работать что-то вроде erlang-а, но именно в силу его ориентированности на приём сообщения (данных), простую обработку, посылку сообщения дальше. То есть модель "актёров". Что действительно никакого отношения к FP не имеет.
Здравствуйте, VladD2, Вы писали:
VD>А так все просто. Функциональный код = отсутствие разделяемого состояния. Отсутствие разделяемого состояния = легкое распараллеливание.
Отсутствие разделяемого состояния = легкое распараллеливание = 100% загрузка всех ядер != линейная масштабируемость скорости работы приложения
Отсутствие разделяемого состояния = легкое распараллеливание = 100% загрузка всех ядер возможно= деградация скорости работы приложения
Если как конечную цель ставить 100%-ную загрузку всех ядер (кодом, который как-то связан с кодом приложения), то Да, всё легко. Если как конечную цель ставить близкую к линейной масштабируемость скорости работы приложения — то, увы, Нет, всё не так просто.
Здравствуйте, Chrome, Вы писали:
C>Мне интересно, рекламируемая уникальная приспособленность фя для параллельного программирования — просто необоснованная реклама, или некакя теоретическая возможность, по какой то причине не очень реализуемая на практике. C>Если второе, то в чем практический затык? Почему не получается?
Тут нужно уточнить одну вещь. Написание кода, который легко параллелить и само распараллеливание — это две разные вещи. Так вот с первым в ФЯ проблем нет, а второе это целый комплекс решений, включающих как процесс кодирование, так и архитектуру приложения и пр.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, mkizub, Вы писали:
M>Здравствуйте, Chrome, Вы писали:
M>Насколько многоядерная? M>C 2, 4, 16, 1024 ядрами?
M>Если их не много, то FP их может хорошо загрузить. При ленивых вычислениях — их можно делать на других ядрах "про запас", раз всё равно они простаивают. И когда нужда в них возникнет — они уже вычеслены.
Загрузить ядра-то — не проблема. Проблема — ещё при этом получить близкое к линейному увеличение скорости работы приложения. И если первое и легко, то про второе я бы не был так уверен.
M>И данные в основном immutable, то есть не надо синхронизировать кэши ядер при записи данных, и вообще синхронизация не нужна — а в ней одной будут самые большие потери при небольшом количестве ядер.
Тут совсем не понятно. Если речь идёт о распараллеливании "однопоточного" приложения, то тут в любом случае (ни в каком языке) нет никаких изначальных издержек на синхронизацию. А если говорить про то, как ран-тайм будет достигать автоматического распараллеливания, то тут в любом случае (в любом языке) будут издержки на синхронизацию — как будем делать балансировку нагрузки? как будем распределять работу между потоками? как будем синхронизировать асинхронные ленивые вычисления? и т.д.
Иммутабельность имеет значение, если говорить о *ручном* и *явном* создании многопоточной программы. (зы в чём проблема иметь не изменяемые данные не в ФП языке? тем более если уж говорить о явном и осознанном создании многопоточной программы)
Здравствуйте, IT, Вы писали:
C>>Мне интересно, рекламируемая уникальная приспособленность фя для параллельного программирования — просто необоснованная реклама, или некакя теоретическая возможность, по какой то причине не очень реализуемая на практике. C>>Если второе, то в чем практический затык? Почему не получается?
IT>Тут нужно уточнить одну вещь. Написание кода, который легко параллелить и само распараллеливание — это две разные вещи. Так вот с первым в ФЯ проблем нет, а второе это целый комплекс решений, включающих как процесс кодирование, так и архитектуру приложения и пр.
Тут тоже надо уточнить одну вещь. Если мы уже провели "само распараллеливание", т.е. провели анализ проблемы, проработали архитектуру, выбрали алгоритмы и т.д. То насколько серьёзные проблемы у нас вызовет в НЕ функциональном языке сделать, допустим, неизменяемый объект, или написать функцию сортировки массива без побочных эффектов?
Здравствуйте, mkizub, Вы писали:
M>Хорошо, к тому времени уже были java.util.concurent контейнеры, специально приспособленные к такой ситуации. А без них — это жизнь на минном поле. В любой момент может выскочить ошибка, и никакими юнит-тестами её обнаружить невозможно.
Здравствуйте, VladD2, Вы писали:
C>>Так есть ли в этом плане реальные преимущества у ФЯ?
VD>Ключевая фраза у тебя это "чуть ли".
VD>Реально же Ф-код сам собой не становится параллельным. Но распараллелить Ф-код проще. И уж точно проще проектировать параллельную программу с использованием ФП.
Ты наверное думал, никто не заметит тонкой подмены ФЯ на ФП
Интересные принципы ФП, такие как неизменяемость и отсутствие побочных-эффектов, действительно делают *некоторые* задачи параллельных вычислений проще. Но они имеют лишь косвенное отношение к ФЯ в данном контексте, в том смысле, что ФЯ *ограничены* только этими подходами (некоторые "ФЯ" не ограничены, но тогда уже наверное мало смысла говорить о ФЯ и о ФП), в то время как НЕ ФЯ языки обычно тоже могут в полном объёме использовать упомянутые подходы, но в то же время не ограничены ими (что может положительно сказаться на реализации *других* некоторых параллельных задач).
Здравствуйте, remark, Вы писали:
R>Здравствуйте, VladD2, Вы писали:
C>>>Так есть ли в этом плане реальные преимущества у ФЯ?
VD>>Ключевая фраза у тебя это "чуть ли".
VD>>Реально же Ф-код сам собой не становится параллельным. Но распараллелить Ф-код проще. И уж точно проще проектировать параллельную программу с использованием ФП.
R>Ты наверное думал, никто не заметит тонкой подмены ФЯ на ФП R>Интересные принципы ФП, такие как неизменяемость и отсутствие побочных-эффектов, действительно делают *некоторые* задачи параллельных вычислений проще. Но они имеют лишь косвенное отношение к ФЯ в данном контексте, в том смысле, что ФЯ *ограничены* только этими подходами (некоторые "ФЯ" не ограничены, но тогда уже наверное мало смысла говорить о ФЯ и о ФП), в то время как НЕ ФЯ языки обычно тоже могут в полном объёме использовать упомянутые подходы, но в то же время не ограничены ими (что может положительно сказаться на реализации *других* некоторых параллельных задач).
Дабы не быть голословным. Такие библиотеки поддержки параллелизма как Intel TBB (C++), Cilk (C), Cilk++ (C++), TPL (.NET), PPL (C++), Fork/Join (Java) для НЕ ФЯ языков, все требуют, что бы "функции" для параллельного выполнения были (1) без побочных эффектов, (2) не зависели от порядка выполнения оных и (3) не требовали параллелизма. Чем *не* *не* ФЯ? Чем не ФП? К тому же все эти библиотеки предоставляют удобное хранилище для "локальных" данных — будь то объект задачи или стек. Уж с чем-чем, но с этими требованиями к "функциям" для параллельного выполнения не возникает никаких проблем и сложностей в не ФЯ языках.
Здравствуйте, remark, Вы писали:
R>Тут тоже надо уточнить одну вещь. Если мы уже провели "само распараллеливание", т.е. провели анализ проблемы, проработали архитектуру, выбрали алгоритмы и т.д. То насколько серьёзные проблемы у нас вызовет в НЕ функциональном языке сделать, допустим, неизменяемый объект, или написать функцию сортировки массива без побочных эффектов?
Здесь можно провести параллель с строготипизированные языки vs нетипизированные. В первом случае компилятор тебе помогает, во втором — это твоя личная проблема. Так же и здесь.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Тут нужно уточнить одну вещь. Написание кода, который легко параллелить и само распараллеливание — это две разные вещи. Так вот с первым в ФЯ проблем нет, а второе это целый комплекс решений, включающих как процесс кодирование, так и архитектуру приложения и пр.
Можно добавить? Да? Спасибо.
Вот тут в ветке, на данный момент, мне понравилось как изложил mkizub — что-то более-менее нормальное и по теме, широкий взгляд. Нет, ты безусловно прав конечно тоже.
Просто тут вот, я с появления темы ждал высказывания Влада, о "преимуществах", и таки оно прозвучало... в иммутабельности! Честно говоря и самому оно в голову пришло. А следом... пришло и другое — получается как несколько лет назад, кричим лозунги, а что они значат — мы не понимаем, то память не ресурс, теперь ФП популяризируется, однако доводов нет. Никаких нет. Никаких адекватных не сравнений и тестов. Хотя я знаю почему их нет, правильно, мы выучили, что есть задача — есть адекватный инструмент. А иммутабельность точно так же как мутабельность может привести к деградации.
Меня конечно можно упрекнуть в том или ином искажении реальности, просто каждая гарная фича несёт за собой расплату. И как сборка мусора несёт за собой свои нюансы, так и иммутабельность. Просто мне не нравится что её подают как решение проблем распараллеливания.
Я в своё время делал простенький рэйтресер. И мимолётом мне Mamut подсказал рэйтрэсер на эрланге (я к эрлангу очень хорошо отношусь, из всех ФЯ мне он наиболее симпатичен), так вот, рэйтресинг это не для эрланга. Умении масштабироваться — да, есть. Но тока я на C++ сделал то, шо бы реализация на эрланге потребовала ~20 процов. Просто не его конёк. И открытых косяков там не было.
И у мну с Мамутом возник вопрос — а что происходит-то с реальными параметрами в функции? раз оно иммутабельно их можно не копировать? Дима ответ не знал, кроме того что в процессах там всегда копирование, а что внутри — бог его знает. Всё зависит от компилятора/интерпретатора ФП получается. Как мне это напоминает долгие рассказы в этом форуме про возможности оптимизатора дотнета... а на практике ж ничего нет. (Тока опять жеж, не нужно меня упрекать в... нелояльности, сам по себе "дотнетнчик" и сам юзаю, и досих пор доволен, не зря перелез ).
Если кого-то прямо или косвенно обидел, то не со зла.
PS: Хотелось бы услышать по этому всему делу более авторитетное мнение чем моя думка.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, remark, Вы писали:
R>>Тут тоже надо уточнить одну вещь. Если мы уже провели "само распараллеливание", т.е. провели анализ проблемы, проработали архитектуру, выбрали алгоритмы и т.д. То насколько серьёзные проблемы у нас вызовет в НЕ функциональном языке сделать, допустим, неизменяемый объект, или написать функцию сортировки массива без побочных эффектов?
IT>Здесь можно провести параллель с строготипизированные языки vs нетипизированные. В первом случае компилятор тебе помогает, во втором — это твоя личная проблема. Так же и здесь.
Параллель провести безусловно можно. И я не спорю, что некоторые вещи в ФЯ несколько проще и легче.
Можно так же проводить параллели, например, со скрепкой-помощником из Microsoft Word, которая тоже была призвана помогать.
Но важный момент — насколько сложно без этой помощи? нет, не в абстрактных терминах, а в терминах реального программиста реализующего что-то реальное, сколько времени у него ушло? сколько моральных сил у него ушло? результат какого качества удалось получить? Далее — насколько это помощь именно в том, в чём разработчику хотелось и требуется?
Так же хороший вопрос — а что если компилятор мне не помагает, а мешает?
Здравствуйте, Chrome, Вы писали:
C>Помогите навести ясность. C>Рекламируя функциональные языки, их сторонники утверждают, что программы на этих языках чуть ли не атоматически распараллеливаются.
Здравствуйте, remark, Вы писали:
R>Но важный момент — насколько сложно без этой помощи? нет, не в абстрактных терминах, а в терминах реального программиста реализующего что-то реальное, сколько времени у него ушло? сколько моральных сил у него ушло? результат какого качества удалось получить? Далее — насколько это помощь именно в том, в чём разработчику хотелось и требуется?
Мне как реальному программисту FP вообще и immutable стиль в частности реально помогает. И даже не в распараллеливании. А просто в процессе кодирования.
R>Так же хороший вопрос — а что если компилятор мне не помагает, а мешает?
Ну так тут нужно мозги в правильном направлении выправлять. Мне раньше компилятор тоже только мешал. Сейчас тот же компилятор помогает.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, remark, Вы писали:
R>>Но важный момент — насколько сложно без этой помощи? нет, не в абстрактных терминах, а в терминах реального программиста реализующего что-то реальное, сколько времени у него ушло? сколько моральных сил у него ушло? результат какого качества удалось получить? Далее — насколько это помощь именно в том, в чём разработчику хотелось и требуется?
IT>Мне как реальному программисту FP вообще и immutable стиль в частности реально помогает. И даже не в распараллеливании. А просто в процессе кодирования.
R>>Так же хороший вопрос — а что если компилятор мне не помагает, а мешает?
IT>Ну так тут нужно мозги в правильном направлении выправлять. Мне раньше компилятор тоже только мешал. Сейчас тот же компилятор помогает.
Замечательно. А я не сталкиваюсь с особыми проблемами при работе в императивном стиле. И мне тоже С++ компилятор помогает тем, что ничем не мешает.
Здравствуйте, remark, Вы писали:
IT>>Ну так тут нужно мозги в правильном направлении выправлять. Мне раньше компилятор тоже только мешал. Сейчас тот же компилятор помогает.
R>Замечательно. А я не сталкиваюсь с особыми проблемами при работе в императивном стиле. И мне тоже С++ компилятор помогает тем, что ничем не мешает.
Это следствие ограниченности. Тот компилятор, который мне раньше вроде бы как не мешал сейчас мешает, а тот который раньше мешал реально помогает. Парадокс. Про C++ я вообще молчу. Я почти 15 лет считал плюсы абсолютным совершенством, пока не увидел другой мир. И оказалось, что плюсы — это поле с граблями, а виртуозное владение плюсами — это всего лишь виртуозное хождение по граблям. Короче, не начинай
Неясность изложения обычно происходит от путаницы в мыслях.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, fddima, Вы писали:
F> Просто тут вот, я с появления темы ждал высказывания Влада, о "преимуществах", и таки оно прозвучало... в иммутабельности! Честно говоря и самому оно в голову пришло. А следом... пришло и другое — получается как несколько лет назад, кричим лозунги, а что они значат — мы не понимаем, то память не ресурс, теперь ФП популяризируется, однако доводов нет. Никаких нет.
Доводов мильён. В том числе и в этом форуме. В частности, я приводил код, который легко параллелится и в три раза короче императивного аналога. Но, проблема в том, что чтобы эти доводы увидеть нужно открыть глаза, а не посильнее зажмуриться.
F>Никаких адекватных не сравнений и тестов. Хотя я знаю почему их нет, правильно, мы выучили, что есть задача — есть адекватный инструмент. А иммутабельность точно так же как мутабельность может привести к деградации.
У иммутабельности, как я уже говорил, есть ещё одно преимущество. В этом стиле банально легче писать код, т.к. весь контекст до неприличия постоянен и мне не откуда ждать подвоха. Если я могу дотянуться до одной и той же переменной из двух веток кода, то мне даже думать не надо, в ней будет одно и тоже значение, что нельзя сказать об императиве, где я должен всегда держать в голове весь контекст со всеми его состояниями. Такая же ситуация с модификацией кода. Достаточно затолкать уже существующий рабочий блок кода в существующий контекст, чтобы бы быть уверенным, что этот блок будет работать без сюрпризов.
Но как тебе это продемонстрировать и какие тесты и сравнения показать, я не знаю
F> Меня конечно можно упрекнуть в том или ином искажении реальности, просто каждая гарная фича несёт за собой расплату. И как сборка мусора несёт за собой свои нюансы, так и иммутабельность. Просто мне не нравится что её подают как решение проблем распараллеливания.
Думаю, ты сам себе придумал про решение проблем. Иммутабельность помогает в решении этих проблем и помогает не слабо, но не решает их.
Неясность изложения обычно происходит от путаницы в мыслях.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Тут нужно уточнить одну вещь. Написание кода, который легко параллелить и само распараллеливание — это две разные вещи. Так вот с первым в ФЯ проблем нет, а второе это целый комплекс решений, включающих как процесс кодирование, так и архитектуру приложения и пр.
М-да... Интересно, кто вот это написал ?
>Тот же самый алгоритм расчёта нелюбимых тобой процентов, который я привёл, ускоряется в разы в зависимости от количества ядер путём внесения маленького изменения в код, состоящего из вызова одного метода AsParallel.
Так ускоряется в разы в зависимости от количества ядер путём внесения маленького изменения или все же необходим целый комплекс решений, включающих как процесс кодирование, так и архитектуру приложения и пр ?
Здравствуйте, fddima, Вы писали:
F> Просто тут вот, я с появления темы ждал высказывания Влада, о "преимуществах", и таки оно прозвучало... в иммутабельности! Честно говоря и самому оно в голову пришло. А следом... пришло и другое — получается как несколько лет назад, кричим лозунги, а что они значат — мы не понимаем, то память не ресурс, теперь ФП популяризируется, однако доводов нет. Никаких нет. Никаких адекватных не сравнений и тестов. Хотя я знаю почему их нет, правильно, мы выучили, что есть задача — есть адекватный инструмент. А иммутабельность точно так же как мутабельность может привести к деградации. F> Меня конечно можно упрекнуть в том или ином искажении реальности, просто каждая гарная фича несёт за собой расплату. И как сборка мусора несёт за собой свои нюансы, так и иммутабельность. Просто мне не нравится что её подают как решение проблем распараллеливания.
Просто есть люди, которые с радостью кидаются на каждое новое "изобретение". Оно им нравится по двум причинам. Во-первых, оно новое, а это им импонирует. Во-вторых, оно, как правило, упрощает написание кода, а это для них немаловажно. Что же касается производительности (или расхода памяти и т.д.) — это они просто во внимание принимать не хотят. Ситуация чем-то напиминает ситуацию в экономике — когда цена на нефть $150, можно все себе позволить, а когда она $50 — надо очень аккуратно действовать и понапрасну деньгами не сорить. Мы в последнее десятилетие имели тот же бешеный рост производительности и объема памяти, в результате чего приличная часть этого ресурса была израсходована на всякие вещи, упрощающие жизнь программиста , а не улучшающие качество программ. В итоге сейчас мы имеем ситуацию, когда программное обеспечение потребляет намного больше ресурсов, чем реально необходимое. Проще говоря, нам дали самолет, а мы на нем в магазин ездим, но поскольку в магазин летать незачем, то этот самолет мы используем как автомобиль.
Когда же эпоха тучных коров заканчивается и наступает эпоха тощих коров, тогда начинают вспоминать, что и с тощих коров можно все же и молоко и мясо получить, если их правильно кормить и доить. И тогда начинают заботиться не столько о том, насколько удобно доярке вставать в 5 утра, а о том, какой цикл дойки коров является наилучшим.
Именно это получилось с памятью. Память резко возросла, и появилось желание тратить ее бесконтрольно. "Память больше не ресурс". Появилось такое желание — есть такие средства. Тратим 100 Мб там, где надо 20Мб — чего ее жалеть! Если бы ее действительно 20 было — еще как бы жалели, а когда ее не то 2048, не то 4096 — незачем! Используем ее расточительно до не могу. Сейчас то же самое про ядра начали. Есть ядра — надо их использовать. Как именно — не так важно, получается ли при этом линейная зависимость производительности от их числа или же мы имеем ситуацию, когда они друг с другом ссорятся, а в итоге производительность очень слабо растет — это тоже не так важно. В целом рост все же будет, конечно, по сравнению с однопоточным приложением, а поэтому можно и объявить, что мы, мол, достигли успеха, и посмотрите, какими простыми средствами!
А вот когда приходится решать задачи, в которых нужно от компьютера взять все, что он может (как твой рейтрейсер) — тогда все эти рассуждения летят к чертовой бабушке.
Что будет дальше — зависит от двух факторов. Первый — это как будет расти производительность компьютеров, а второй — какие задачи будут на повестке дня. Если быстродействие будет так же расти, как оно росло — неэффективные решения будут жить и процветать. Если задачи не будут требовать эффективного использования ресурсов — тоже. Если же рост производительности замедлится (это скорее всего), а задачи усложнятся (а вот это большой вопрос) — тогда все эти неэффективные решения полетят к той же бабушке, а на повестку дня выйдут опять-таки эффективные решения. Если все же надо летать, то надо из этого двигателя выжать 800 км/час, даже если пилоту будет намного сложнее работать, чем водителю Жигулей.
F> И у мну с Мамутом возник вопрос — а что происходит-то с реальными параметрами в функции? раз оно иммутабельно их можно не копировать? Дима ответ не знал, кроме того что в процессах там всегда копирование, а что внутри — бог его знает. Всё зависит от компилятора/интерпретатора ФП получается. Как мне это напоминает долгие рассказы в этом форуме про возможности оптимизатора дотнета... а на практике ж ничего нет.
Будет потребность — будет оптимизатор. Пока ее нет — не будет. А потребность будет, когда станет ясно, сколько из-за его отсутствия теряем, и когда нам это потерянное жалко станет, потому что именно его и не хватать будет. Как с твоим рейстрейсером — ты его "оптимизировал", переведя с Эрланга на С++
F> Если кого-то прямо или косвенно обидел, то не со зла.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Просто есть люди, которые с радостью кидаются на каждое новое "изобретение". Оно им нравится по двум причинам. Во-первых, оно новое, а это им импонирует. Во-вторых, оно, как правило, упрощает написание кода, а это для них немаловажно. Что же касается производительности (или расхода памяти и т.д.) — это они просто во внимание принимать не хотят. Ситуация чем-то напиминает ситуацию в экономике — когда цена на нефть $150, можно все себе позволить, а когда она $50 — надо очень аккуратно действовать и понапрасну деньгами не сорить. Мы в последнее десятилетие имели тот же бешеный рост производительности и объема памяти, в результате чего приличная часть этого ресурса была израсходована на всякие вещи, упрощающие жизнь программиста , а не улучшающие качество программ. В итоге сейчас мы имеем ситуацию, когда программное обеспечение потребляет намного больше ресурсов, чем реально необходимое. Проще говоря, нам дали самолет, а мы на нем в магазин ездим, но поскольку в магазин летать незачем, то этот самолет мы используем как автомобиль. PD>Когда же эпоха тучных коров заканчивается и наступает эпоха тощих коров, тогда начинают вспоминать, что и с тощих коров можно все же и молоко и мясо получить, если их правильно кормить и доить. И тогда начинают заботиться не столько о том, насколько удобно доярке вставать в 5 утра, а о том, какой цикл дойки коров является наилучшим.
Не знаю, не знаю.
По моим впечатлениям, люди делятся на два, условно говоря, лагеря.
Первый лагерь — это люди, которым важно, чтобы решение работало вообще хоть как-нибудь.
Им неинтересно улучшать существующее решение до тех пор, пока их не бьют палкой, и неинтересно выбирать более хорошее решение из нескольких альтернатив.
Им вообще мешают альтернативы, потому что они требуют думать и делать выбор.
Такие люди не бросаются ни на какие изобретения, просто потому, что им это неинтересно. Они и под С++ пишут строго на С, потому что учить новое им ленивее, чем писать по-старому.
Другая категория людей — те, которым интересно получать более правильные решения. Такой человек может при выборе решения предпочитать рантайм-эффективность, удобство для пользователя, или простоту в поддержке. Это уже не так важно — важен сам интерес к улучшению.
Вот такие люди как раз бросаются на новые изобретения, потому что им интересно улучшить свои решения.
Вот простой пример — люди смотрят на 4GB памяти и говорят "о, круто. Раньше мы не могли себе позволить выполнять глобальные оптимизации в компиляторе потому, что ему не хватало памяти, и приходилось ограничиваться локальным анализом. Теперь мы можем проводить глобальные оптимизации, и получать код, потребление памяти которым в рантайме гарантированно минимально".
Вон, у Ершова есть пример для детей о том, как задача распределения памяти под переменные программы сводится к раскраске рёбер графа. Ну так и возможность решать эту задачу напрямую зависит от того, насколько большие графы может себе позволить ворочать компилятор.
Или говорят "о, раньше у нас не было средства на лету генерировать код, и приходилось заниматься оптимизацией вслепую, либо применять интерпретатор. Теперь у нас есть среда со встроенным компилятором; это позволит нам генерировать программы, которые гарантированно рвут по производительности оба старых варианта".
Вот подскажи мне, как эксперт по C++, какая там самая быстрая библиотека регулярных выражений? Используется ли там runtime-кодогенерация?
PD>Именно это получилось с памятью. Память резко возросла, и появилось желание тратить ее бесконтрольно.
Не то чтобы прямо так желание. Появилась возможность не думать о памяти вообще; и некоторые люди из первой категории стали этим злоупотреблять.
Ты просто сваливаешь в одну кучу два разных явления. В одном случае люди осознанно используют доступную память, например организуют агрессивное кэширование для достижения высокой производительности. А в другом люди просто забивают память, не думая ни о чем вообще.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Именно это получилось с памятью. Память резко возросла, и появилось желание тратить ее бесконтрольно. "Память больше не ресурс". Появилось такое желание — есть такие средства. Тратим 100 Мб там, где надо 20Мб — чего ее жалеть! Если бы ее действительно 20 было — еще как бы жалели, а когда ее не то 2048, не то 4096 — незачем! Используем ее расточительно до не могу. Сейчас то же самое про ядра начали. Есть ядра — надо их использовать. Как именно — не так важно, получается ли при этом линейная зависимость производительности от их числа или же мы имеем ситуацию, когда они друг с другом ссорятся, а в итоге производительность очень слабо растет — это тоже не так важно. В целом рост все же будет, конечно, по сравнению с однопоточным приложением, а поэтому можно и объявить, что мы, мол, достигли успеха, и посмотрите, какими простыми средствами!
Только разговор не о памяти. Мейчас памят все продолжает увеличиваться примерно с теми же темпами. Ограничением пока служит x86 архитекура.
А вот с быстродейтсвием отдельно взятого процессора уже проблема. Такого роста как раньше уже не наблюдается. Пока что можно ускорить приложение наращиванием коичества процессоров в системе, но программы написанные для одного процессора не смогут эффективно исползовать десяток ядер. Придется писать программы по-другому.
Это "по-другому" как раз и выльется в использование еще большего объема памяти.
PD>Что будет дальше — зависит от двух факторов. Первый — это как будет расти производительность компьютеров, а второй — какие задачи будут на повестке дня. Если быстродействие будет так же расти, как оно росло — неэффективные решения будут жить и процветать. Если задачи не будут требовать эффективного использования ресурсов — тоже. Если же рост производительности замедлится (это скорее всего), а задачи усложнятся (а вот это большой вопрос) — тогда все эти неэффективные решения полетят к той же бабушке, а на повестку дня выйдут опять-таки эффективные решения. Если все же надо летать, то надо из этого двигателя выжать 800 км/час, даже если пилоту будет намного сложнее работать, чем водителю Жигулей.
Что значит "эффективные"?
PD>Будет потребность — будет оптимизатор. Пока ее нет — не будет. А потребность будет, когда станет ясно, сколько из-за его отсутствия теряем, и когда нам это потерянное жалко станет, потому что именно его и не хватать будет. Как с твоим рейстрейсером — ты его "оптимизировал", переведя с Эрланга на С++
Эрланг — один из самых медленных языков сейчас, а C++ — один из самых быстрых. Естественно что банальное переписывание с Эрланга на С++ может дать огромный прирос быстродейсвия. но дело тут не в памяти.
Здравствуйте, gandjustas, Вы писали:
G>Только разговор не о памяти. Мейчас памят все продолжает увеличиваться примерно с теми же темпами. Ограничением пока служит x86 архитекура.
Гм. Никто не мешает перейти на x64 архитектуру, где ограничений нет никаких практически. Но почему-то не переходят. Точнее, 64-битные версии XP и Vista используются уже довольно широко, а вот 64-битные программы все же пока менее популярны, и намного менее.
G>А вот с быстродейтсвием отдельно взятого процессора уже проблема. Такого роста как раньше уже не наблюдается. Пока что можно ускорить приложение наращиванием коичества процессоров в системе, но программы написанные для одного процессора не смогут эффективно исползовать десяток ядер. Придется писать программы по-другому.
+1
G>Это "по-другому" как раз и выльется в использование еще большего объема памяти.
-1. Совсем не обязательно.
PD>>Что будет дальше — зависит от двух факторов. Первый — это как будет расти производительность компьютеров, а второй — какие задачи будут на повестке дня. Если быстродействие будет так же расти, как оно росло — неэффективные решения будут жить и процветать. Если задачи не будут требовать эффективного использования ресурсов — тоже. Если же рост производительности замедлится (это скорее всего), а задачи усложнятся (а вот это большой вопрос) — тогда все эти неэффективные решения полетят к той же бабушке, а на повестку дня выйдут опять-таки эффективные решения. Если все же надо летать, то надо из этого двигателя выжать 800 км/час, даже если пилоту будет намного сложнее работать, чем водителю Жигулей. G>Что значит "эффективные"?
PD>>Будет потребность — будет оптимизатор. Пока ее нет — не будет. А потребность будет, когда станет ясно, сколько из-за его отсутствия теряем, и когда нам это потерянное жалко станет, потому что именно его и не хватать будет. Как с твоим рейстрейсером — ты его "оптимизировал", переведя с Эрланга на С++
G>Эрланг — один из самых медленных языков сейчас, а C++ — один из самых быстрых. Естественно что банальное переписывание с Эрланга на С++ может дать огромный прирос быстродейсвия. но дело тут не в памяти.
А я о памяти и не говорил в этом случае. fddima не дал мне никаких оснований о ней говорить.
Мне кажется, мы здесь просто о разных вещах говорим. Ты — о подходе со стороны разных категорий разработчиков (и в общем ты прав, хот с деталями можно поспорить), я — о ситуации с ресурсами и задачами. Эти области пересекаются, но не совпадают.
Насчет библиотеки по регулярным выражениям — я с ними дел не имею и они мне даром не нужны. У меня совсем другие задачи, текстовой обработкой я не занимаюсь. Спроси тех, кто с ними работает.
Здравствуйте, gandjustas, Вы писали:
G>Только разговор не о памяти. Мейчас памят все продолжает увеличиваться примерно с теми же темпами. Ограничением пока служит x86 архитекура.
Не уверен. G>А вот с быстродейтсвием отдельно взятого процессора уже проблема. Такого роста как раньше уже не наблюдается.
Имхо, это связано с тем, что это быстродействие просто нечем нагрузить. Какой толк от увеличения тактовой частоты вдвое, если память всё равно не успевает "подвозить" данные?
G>Пока что можно ускорить приложение наращиванием коичества процессоров в системе, но программы написанные для одного процессора не смогут эффективно исползовать десяток ядер. Придется писать программы по-другому.
Тут есть небольшая тонкость. Одно дело — несколько процессоров, другое — несколько ядер. G>Это "по-другому" как раз и выльется в использование еще большего объема памяти.
Вот в этом месте мне не до конца понятно. Ну вот увеличишь ты объем памяти до 64Гб. А толку, если ее доставка в CPU займет в 16 раз больше времени, чем для 4Гб? Независимо от того, о скольких CPU мы говорим.
G>Что значит "эффективные"?
Это значит, что решения будут учитывать latency памяти, приколы с шедулингом на соседних ядрах и далёких процессорах, а также разнообразные подходы к перестройке алгоритма в зависимости от окружения.
Ситуация примерно такая же, как с многомерными индексами в СУБД. Для размерности =1 известны превосходные решения с логарифмическими характеристиками; для двух есть приемлемые решения; для размерностей выше десяти прямой перебор оказывается быстрее, чем любой индекс.
G>Эрланг — один из самых медленных языков сейчас, а C++ — один из самых быстрых. Естественно что банальное переписывание с Эрланга на С++ может дать огромный прирос быстродейсвия. но дело тут не в памяти.
Не очень понятно, что такое "быстрый/медленный". Если мы будем заниматься математическими микробенчмарками — эрланг проиграем. А если задачами массового обслуживания, то на плюсах придется сильно попотеть для догоняния Эрланга.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Pavel Dvorkin, Вы писали:
IT>>Мне раньше компилятор тоже только мешал. Сейчас тот же компилятор помогает.
PD>Из этой ситуации есть два выхода.
PD>1. Поменять компилятор. PD>2. Поменять того, кто с этим компилятором работает.
Ответ неверный, садись, два. Правильный ответ — время от времени нужно апгрейтить мозги, а не пользоваться всю жизнь устаревшей моделью сороколетней давности.
Неясность изложения обычно происходит от путаницы в мыслях.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Так ускоряется в разы в зависимости от количества ядер путём внесения маленького изменения или все же необходим целый комплекс решений, включающих как процесс кодирование, так и архитектуру приложения и пр ?
Что именно тебе не понятно в первом или во втором высказывании?
Неясность изложения обычно происходит от путаницы в мыслях.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, gandjustas, Вы писали:
G>>Только разговор не о памяти. Мейчас памят все продолжает увеличиваться примерно с теми же темпами. Ограничением пока служит x86 архитекура. S>Не уверен.
Возможно.
G>>А вот с быстродейтсвием отдельно взятого процессора уже проблема. Такого роста как раньше уже не наблюдается. S>Имхо, это связано с тем, что это быстродействие просто нечем нагрузить. Какой толк от увеличения тактовой частоты вдвое, если память всё равно не успевает "подвозить" данные?
Ни разу не видел чтобы программа серьезно тормозила из-за низкого быстродейсвтия самой памяти (синтетические тесты с кеш-промахами не в счет).
G>>Пока что можно ускорить приложение наращиванием коичества процессоров в системе, но программы написанные для одного процессора не смогут эффективно исползовать десяток ядер. Придется писать программы по-другому. S>Тут есть небольшая тонкость. Одно дело — несколько процессоров, другое — несколько ядер.
Нутут еще одна тонкость. Одно дело фичиеские ядра в процессоре, а другое дело логические. Но эти тонкости покачто мало интересуют.
G>>Это "по-другому" как раз и выльется в использование еще большего объема памяти. S>Вот в этом месте мне не до конца понятно. Ну вот увеличишь ты объем памяти до 64Гб. А толку, если ее доставка в CPU займет в 16 раз больше времени, чем для 4Гб? Независимо от того, о скольких CPU мы говорим.
Обычно средние затраты на считывание-запись в памяти очень малы по сравнению выполнением какого-либо алгоритма.
G>>Что значит "эффективные"? S>Это значит, что решения будут учитывать latency памяти, приколы с шедулингом на соседних ядрах и далёких процессорах, а также разнообразные подходы к перестройке алгоритма в зависимости от окружения. S>Ситуация примерно такая же, как с многомерными индексами в СУБД. Для размерности =1 известны превосходные решения с логарифмическими характеристиками; для двух есть приемлемые решения; для размерностей выше десяти прямой перебор оказывается быстрее, чем любой индекс.
Ну и как в СУБД нам совершенно необязательно чтобы алгоритм учитывал все, досаточно чтобы он работал не намного хуже теоретического предела.
G>>Эрланг — один из самых медленных языков сейчас, а C++ — один из самых быстрых. Естественно что банальное переписывание с Эрланга на С++ может дать огромный прирос быстродейсвия. но дело тут не в памяти. S>Не очень понятно, что такое "быстрый/медленный". Если мы будем заниматься математическими микробенчмарками — эрланг проиграем. А если задачами массового обслуживания, то на плюсах придется сильно попотеть для догоняния Эрланга.
Рассматривался рэйтресер — программа, которая много считала.
Здравствуйте, Pavel Dvorkin, Вы писали: PD>Во-вторых, оно, как правило, упрощает написание кода, а это для них немаловажно.
Вы так говорите, как будто это что-то плохое. Сокращать затраты на написание кода, удобство поддержки, тестирования и отладки — это очень важно.
PD>Что же касается производительности (или расхода памяти и т.д.) — это они просто во внимание принимать не хотят.
Это Вы так зря. Преждевременная оптимизация — это дело неблагодарное. А выбор якобы более быстрого и экономного по памяти средства разработки без рассмотрения специфики задачи — это и есть преждевременная оптимизация. Оптимизировать надо то, что является узким местом. Зачем оптимизировать свой код, если большую часть процессорного времени и памяти съедает СУБД, веб-сервер или что-нить подобное?
PD>приличная часть этого ресурса была израсходована на всякие вещи, упрощающие жизнь программиста , а не улучшающие качество программ.
Качество программы — это не только ее требования к ресурсам, но и юзабилити, отсутствие багов, функциональность, стоимость и т.п. А последние четыре пункта часто напрямую зависят от того, насколько хорошо живется программисту.
PD>Тратим 100 Мб там, где надо 20Мб — чего ее жалеть!
Смотря на что тратится память.
PD>А вот когда приходится решать задачи, в которых нужно от компьютера взять все, что он может (как твой рейтрейсер) — тогда все эти рассуждения летят к чертовой бабушке.
Интересно, а как бы в этой задаче выглядел OCaml?
PD>какие задачи будут на повестке дня.
С чего бы разнообразию задач сократиться?
Здравствуйте, IT, Вы писали:
IT>>>Ну так тут нужно мозги в правильном направлении выправлять. Мне раньше компилятор тоже только мешал. Сейчас тот же компилятор помогает.
R>>Замечательно. А я не сталкиваюсь с особыми проблемами при работе в императивном стиле. И мне тоже С++ компилятор помогает тем, что ничем не мешает.
IT>Это следствие ограниченности. Тот компилятор, который мне раньше вроде бы как не мешал сейчас мешает, а тот который раньше мешал реально помогает. Парадокс. Про C++ я вообще молчу. Я почти 15 лет считал плюсы абсолютным совершенством, пока не увидел другой мир. И оказалось, что плюсы — это поле с граблями, а виртуозное владение плюсами — это всего лишь виртуозное хождение по граблям. Короче, не начинай
Я и не начинаю, это ты спустился на частности и ушёл в сторону. Для меня язык не сильно принципиален, и будет 3 строчек кода или 7 тоже не особо интересует. Мне кажется, более важны более высокие и общие вещи — например, построение архитектуры на передачи неизменяемых объектов. И в чём тут проблемы у НЕ ФЯ я так и не понял.
Здравствуйте, remark, Вы писали: R>И в чём тут проблемы у НЕ ФЯ я так и не понял.
Может, имеется в виду, что в ФЯ "инфраструктура" для комфортной работы с иммутабельными объектами как правило уже построена, а в императивных ЯП ее надо как-то строить самому.
Яркий пример — списки. В ФЯ обычно уже реализовано подобие copy on write для списков, т.е. там, где это возможно, оставшийся неизменным хвост операнда станет частью результирующего списка. Если для используемого Вами императивного ЯП нет библиотек, организующих такую работу со списками — придется все делать самому.
Здравствуйте, Mr.Cat, Вы писали:
MC>Здравствуйте, remark, Вы писали:
R>>И в чём тут проблемы у НЕ ФЯ я так и не понял.
MC>Может, имеется в виду, что в ФЯ "инфраструктура" для комфортной работы с иммутабельными объектами как правило уже построена, а в императивных ЯП ее надо как-то строить самому.
MC>Яркий пример — списки. В ФЯ обычно уже реализовано подобие copy on write для списков, т.е. там, где это возможно, оставшийся неизменным хвост операнда станет частью результирующего списка. Если для используемого Вами императивного ЯП нет библиотек, организующих такую работу со списками — придется все делать самому.
Определенно, что-то придётся делать самому. С этим, я думаю, никто не будет спорить.
Иногда это может помочь, иногда помешать. Это палка о двух концах. Например, в SQL есть много чего для экстремально комфортной работы с данными, однако только на SQL пишут мало реальных систем.
Здравствуйте, remark, Вы писали: R>Например, в SQL есть много чего для экстремально комфортной работы с данными, однако только на SQL пишут мало реальных систем.
Писали когда-то (ну и сейчас еще по инерции), на PL/SQL, например, с использованием всяческих вещей, типа Oracle Forms, Oracle APEX и т.п. И продолжали бы, если бы Oracle не забросил эти технологии и не переключился на Java.
Здравствуйте, Mr.Cat, Вы писали:
MC>Здравствуйте, remark, Вы писали: R>>Например, в SQL есть много чего для экстремально комфортной работы с данными, однако только на SQL пишут мало реальных систем.
MC>Писали когда-то (ну и сейчас еще по инерции), на PL/SQL, например, с использованием всяческих вещей, типа Oracle Forms, Oracle APEX и т.п. И продолжали бы, если бы Oracle не забросил эти технологии и не переключился на Java.
Какое это имеет отношение к SQL? на Erlang тоже можно С-либу подгрузить и работать с разделяемой памятью.
Здравствуйте, remark, Вы писали: MC>>Писали когда-то (ну и сейчас еще по инерции), на PL/SQL, например, с использованием всяческих вещей, типа Oracle Forms, Oracle APEX и т.п. И продолжали бы, если бы Oracle не забросил эти технологии и не переключился на Java. R>Какое это имеет отношение к SQL? на Erlang тоже можно С-либу подгрузить и работать с разделяемой памятью.
Прямое. Вы когда-нибудь работали с Oracle Forms, например? Полагаю, что нет, т.к. аналогия с erlang+C совершенно неуместна.
Oracle Forms — это рантайм PL/SQL (чтобы запускать код на клиентской машине или сервере приложений — т.е. вне СУБД) плюс GUI (оконный или web), позволяющий работать с ним из PL/SQL (в частности, отображать результаты выборки из БД).
Здравствуйте, Mr.Cat, Вы писали:
MC>Здравствуйте, remark, Вы писали: MC>>>Писали когда-то (ну и сейчас еще по инерции), на PL/SQL, например, с использованием всяческих вещей, типа Oracle Forms, Oracle APEX и т.п. И продолжали бы, если бы Oracle не забросил эти технологии и не переключился на Java. R>>Какое это имеет отношение к SQL? на Erlang тоже можно С-либу подгрузить и работать с разделяемой памятью.
MC>Прямое. Вы когда-нибудь работали с Oracle Forms, например? Полагаю, что нет, т.к. аналогия с erlang+C совершенно неуместна.
MC>Oracle Forms — это рантайм PL/SQL (чтобы запускать код на клиентской машине или сервере приложений — т.е. вне СУБД) плюс GUI (оконный или web), позволяющий работать с ним из PL/SQL (в частности, отображать результаты выборки из БД).
С самими приложениями работал много. Код немного видел. Но я не о том. Я про чистый SQL говорил. Смысл в том, что поддержка некоторых фич, ещё ничего не значит в общем. Если SQL и есть некоторое подобие серебряной пули для некоторой обработки некоторых данных, то это не значит, что это — серебряная руля для всего; даже для другой обработки или других данных.
Этим я хотел сказать, что если в ФЯ есть поддержка иммутабельных структур данных, то это не значит, что ФЯ — серебряная пуля для разработки ПО (в т.ч. параллельного) вообще. Хотя определенно, некоторый класс задач становится решать легче (в других языках нам придётся что-то вначале сделать самим, а дальше, если хочется, можно опять же работать с иммутабельными структурами).
А ещё есть не только функциональная, но и логическая парадигма. Prolog и его идейные наследники.
Которые ещё легче параллелятся — вместо поиска ответа в глубину и отката, можно запустить сразу несколько поисков, и каждый новый перебор вариантов передавать отдельному процессору.
А ещё OOP сам по себе, безотносительно к его реализации в процедурных языках — это посылка сообщений методам. Каковые сообщения вполне можно посылать в разных тредах выполняемых на разных процессорах/ядрах.
Те-же преимущества которые даёт FP (вроде lazy вычислений и immutable данных) — идейно проистекают из того факта, что FP предполагает не задание последовательности вычислений, а задание соотношений (функций) между параметрами и результатом, каковые неизменны (если нет изменения состояния данных и зависимости от глобальных значений), и именно поэтому FP программы легче параллелятся.
Похоже, что чем выше мы уходим по уровням абстракции, чем больше уходим от процедурности к декларативности — тем легче автоматическое распараллеливание и потенциальный выигрыш от многоядерности. Но с другой стороны — чем больше уровней абстракции, тем больше накладные расходы и требуемые ресурсы, которые легко могут съесть потенциальный выигрыш от параллелизма.
Здравствуйте, remark, Вы писали:
R>Я и не начинаю, это ты спустился на частности и ушёл в сторону. Для меня язык не сильно принципиален, и будет 3 строчек кода или 7 тоже не особо интересует. Мне кажется, более важны более высокие и общие вещи — например, построение архитектуры на передачи неизменяемых объектов.
Вот в этом у нас с тобой принципиальное разногласие. По мне так никакая архитектура не заменит качества элементов из которых она строится. Дом, построенный из дерьма всегда будет оставаться куском дерьма. Париж не гордился бы своей башней уже более сотни лет, если бы Эйфель не строил её из самых качественных материалов и применения самых прогрессивных для того времени методов монтажа строительных конструкций.
R>И в чём тут проблемы у НЕ ФЯ я так и не понял.
В том, что от качества инструмента напрямую зависит качество реализации.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Pavel Dvorkin, Вы писали:
IT>>Что именно тебе не понятно в первом или во втором высказывании?
PD>А разве я сказал, что мне что-то непонятно ?
Т.е. тебе просто не с кем поговорить?
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
M>>Но с другой стороны — чем больше уровней абстракции, тем больше накладные расходы и требуемые ресурсы...
IT>Откуда такой однозначный вывод?
Из практики.
Теоретически ты можешь под свою конкретную задачу написать свой язык программирования, со своим рантаймом, написать свою VM, написать свою операционку, и сбацать свой CPU. Которые будут идеально подходить под решение твоей задачи, что сведёт к минимуму потери на этих дополнительных уровнях абстракции.
А на практике создание своего языка, своей VM, своей операционки, своего CPU — никто не делает. Потому как с одной стороны, это сделает стоимость подобной программы слишком большой, а с другой стороны твоя среда не будет адаптивной, то есть будет подходить только для решения твоей задачи, а не большого класса задач.
И на практике выходит, что ресурсы потребляемые твоим компьютером на несколько порядков больше, чем реально нужно твоей задаче.
Сравни ресурсы потребляемые JVM с ресурсами необходимыми для запуска аналогичной программы на С. Один только JIT компилятор отъедает 20 мег, плюс загруженные в память системные jar-ы, из которых тебе нужно, как правило, не более 10% кода. А какова загрузка процессора? А каковы потери на верифицируемость кода?
Я работал в фирме, которая делала J2ME (яву для телефонов) с AOT компилятором. Сам код JVM был написан на яве. Но поскольку компилировали мы это своим компилятором, и могли туда вставить свои расширения явы (включая и unsafe код) — то этот явовский код работал быстрее С-шного. Без всех этих потерь на JIT и многих других явовских приколов (вроде поздней инициализации классов).
А если бы ARM (Thumb) не был таким неприспособленным под явовскую компиляцию, то код бы работал ещё раза в полтора быстрее и занимал раза в 2 меньше места — как раз новую версию ARM-а готовят, в которой эти дополнения войдут, и я читал у них про соответствующие измерения.
Это только один пример по поводу JVM. Примеры про Висту, комфортно живущую только на памяти от 2 гиг и прочее — сам можешь вспомнить.
Здравствуйте, remark, Вы писали:
R>Тут совсем не понятно. Если речь идёт о распараллеливании "однопоточного" приложения, то тут в любом случае (ни в каком языке) нет никаких изначальных издержек на синхронизацию. А если говорить про то, как ран-тайм будет достигать автоматического распараллеливания, то тут в любом случае (в любом языке) будут издержки на синхронизацию — как будем делать балансировку нагрузки? как будем распределять работу между потоками? как будем синхронизировать асинхронные ленивые вычисления? и т.д.
Здравствуйте, mkizub, Вы писали:
M>Здравствуйте, remark, Вы писали:
R>>Тут совсем не понятно. Если речь идёт о распараллеливании "однопоточного" приложения, то тут в любом случае (ни в каком языке) нет никаких изначальных издержек на синхронизацию. А если говорить про то, как ран-тайм будет достигать автоматического распараллеливания, то тут в любом случае (в любом языке) будут издержки на синхронизацию — как будем делать балансировку нагрузки? как будем распределять работу между потоками? как будем синхронизировать асинхронные ленивые вычисления? и т.д.
M>Это не синхронизация, а шедулинг.
Ну значит поменяли шило на было. Были издержки на синхронизацию, стали издержки на шедулинг.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, remark, Вы писали:
R>>Я и не начинаю, это ты спустился на частности и ушёл в сторону. Для меня язык не сильно принципиален, и будет 3 строчек кода или 7 тоже не особо интересует. Мне кажется, более важны более высокие и общие вещи — например, построение архитектуры на передачи неизменяемых объектов.
IT>Вот в этом у нас с тобой принципиальное разногласие. По мне так никакая архитектура не заменит качества элементов из которых она строится. Дом, построенный из дерьма всегда будет оставаться куском дерьма. Париж не гордился бы своей башней уже более сотни лет, если бы Эйфель не строил её из самых качественных материалов и применения самых прогрессивных для того времени методов монтажа строительных конструкций.
R>>И в чём тут проблемы у НЕ ФЯ я так и не понял.
IT>В том, что от качества инструмента напрямую зависит качество реализации.
И что ты хочешь этим сказать?... А кажется понял. Ты хочешь указать на тот факт, что С/С++ позволяет мне создавать экстремально эффективные и масштабируемые примитивы под мои задачи. Да, ты прав. Я могу создавать экстремально качественные строительные блоки, используя такие вещи как примитивы синхронизации низлежащего аппаратного обеспечения, специфические возможности ОС, привязка программных потоков к аппаратным, детектирование структуры аппаратной платформы, экстремально проработанная запаковка структур данных и т.д. И в принципе, насколько я знаю, все разработчики, которые занимаются многоядерными архитектурами будь то на Java, C#, Haskell и т.д. все любят качество и используют С/С++.
Аааа... Подожди... Или ты под качеством имеешь в виду синтаксис и время разработки?
Хммм... Я не думаю, что Эйфель выбирал наиболее простые технологии и наиболее дешёвые материалы...
Здравствуйте, gandjustas, Вы писали:
G>>>А вот с быстродейтсвием отдельно взятого процессора уже проблема. Такого роста как раньше уже не наблюдается. S>>Имхо, это связано с тем, что это быстродействие просто нечем нагрузить. Какой толк от увеличения тактовой частоты вдвое, если память всё равно не успевает "подвозить" данные?
G>Ни разу не видел чтобы программа серьезно тормозила из-за низкого быстродейсвтия самой памяти (синтетические тесты с кеш-промахами не в счет).
Здравствуйте, remark, Вы писали:
R>И что ты хочешь этим сказать?... А кажется понял. Ты хочешь указать на тот факт, что С/С++ позволяет мне создавать экстремально эффективные и масштабируемые примитивы под мои задачи.
Скорее экстремально кривые. Ты всю память освободил в своих компонентах? Ничего больше не ликает? Ну так пойди и ещё раз проверь.
R>Хммм... Я не думаю, что Эйфель выбирал наиболее простые технологии и наиболее дешёвые материалы...
Именно. А также и наиболее надёждные, а не заведомо кривые.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, remark, Вы писали:
R>>И что ты хочешь этим сказать?... А кажется понял. Ты хочешь указать на тот факт, что С/С++ позволяет мне создавать экстремально эффективные и масштабируемые примитивы под мои задачи.
IT>Скорее экстремально кривые. Ты всю память освободил в своих компонентах? Ничего больше не ликает? Ну так пойди и ещё раз проверь.
Да нет, ничего не ликает. Там всё очень просто — либо вообще память не выделяется, либо в конструкторе выделяем/в деструкторе освобождаем. Ну иногда бывает посложнее, но управление памятью всё равно получается одним из самых простых звеньев, просто надо аккуратно сделать и всё. Это действительно не проблема при строительстве Эйфелевой башни.
В ран-таймах функциональных/высокоуровневых языках же память не течёт, хотя они обычно пишутся на С... Или может проверить их ещё раз...
R>>Хммм... Я не думаю, что Эйфель выбирал наиболее простые технологии и наиболее дешёвые материалы...
IT>Именно. А также и наиболее надёждные, а не заведомо кривые.
Что ты называешь заведомо кривым? Я уже перестаю улавливать параллель между аналогией и предметом нашего разговора.
Здравствуйте, mkizub, Вы писали:
M>А на практике создание своего языка, своей VM, своей операционки, своего CPU — никто не делает. Потому как с одной стороны, это сделает стоимость подобной программы слишком большой, а с другой стороны твоя среда не будет адаптивной, то есть будет подходить только для решения твоей задачи, а не большого класса задач.
Это потому, что для этого нет адекватных средств. Точнее уже есть. Вот прямо сейчас я делаю язык для своих задач и работать он будет быстрее и надёжднее кода, написанного ручками, просто потому, что в ручном коде я должен беспокоиться ещё и о поддержке этого кода, в в сгенерированном мне это до лампочки.
M>И на практике выходит, что ресурсы потребляемые твоим компьютером на несколько порядков больше, чем реально нужно твоей задаче.
У вас какая-то неправильная практика В моей практике основной потребитель ресурсов — это сервер базы данных, написанный между прочим на C/C++. А сервера приложений, написанных на C#, у меня в штатном режиме потребляют не более 5%-10% процессорного времени и (сейчас гляну) чуть меньше половины физической памяти.
M>Сравни ресурсы потребляемые JVM с ресурсами необходимыми для запуска аналогичной программы на С.
Это ты про "Hellow, World!"? А ты не пробовал сравнивать бизнес приложения, написанные на Java и на C? Как-нибудь попробуй.
M>Примеры про Висту, комфортно живущую только на памяти от 2 гиг и прочее — сам можешь вспомнить.
Ты хочешь сказать, что Aero в Висте написано на джаве?
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
R>>Что ты называешь заведомо кривым? Я уже перестаю улавливать параллель между аналогией и предметом нашего разговора.
IT>Что тут непонятного? Инструмент, которым ты пользуещься, кривой по определению.
Расскажи это людям, которые делают для тебя ОС, ран-таймы не кривых языков, и реализации продвинутых фич в не кривых языках, которые обеспечили наше общение на RSDN и т.д.
Кажется кто-то тут недавно говорил о том, что кривыми по определению инструментами можно сделать только кусок дерьма... возможно я что-то упускаю, но из твоих слов получается что большинство функциональных языков, языков основанных на сборке мусора и т.д. — кусок дерьма в квадрате.
Здравствуйте, IT, Вы писали:
IT>Это потому, что для этого нет адекватных средств. Точнее уже есть. Вот прямо сейчас я делаю язык для своих задач и работать он будет быстрее и надёжднее кода, написанного ручками, просто потому, что в ручном коде я должен беспокоиться ещё и о поддержке этого кода, в в сгенерированном мне это до лампочки.
Вот именно. Это то, о чём я тебе и говорю. Ты создаёшь средство, которое позволит писать программы на языке с высоким уровнем абстракции,
не используя промежуточных уровней, а используя кодогенерацию написанную специально для конкретного класса задач.
А теперь представь себе, что он генерирует код не для конкретно .NET или конкретно JVM, а для конкретной аппаратной платформы,
и даже для конкретного компьютера (с его конкретным числом ядер, размером памяти, кэша и прочее).
А теперь представь себе, что изготовители CPU тоже просекли фишку с адаптируемостью, и стали делать адаптируемые (конфигурирумые под
конкретные задачи) процессоры. И ты можешь писать макросы, которые будут при компиляции учитывать эти возможности.
Ты можешь оценить степень оптимизации подобного приложения по сравнению с существующими?
Вот код который я пишу, если бы я из него генерировал нэйтивный код, работал бы в разы быстрее. Потому как я на уровне компилятора (точнее, даже на уровне своих абстракций) могу доказать, что куча рантайм проверок не нужна, и организовать размещение данных в памяти намного эффективнее (дело даже не в её экономии, а и в скорости последовательного доступа, а не размазанности данных по хипу, и многих других возможностях). И занимал бы раза в 2-3 меньше памяти, следовательно и в кэш бы влазил лучше.
То есть просто за счёт отказа от ограничений JVM я бы уменьшил требования к ресурсам в несколько раз.
А если ещё сделать аппаратную поддержку часто используемых у меня примитивов — это ещё в несколько раз.
Грубо говоря — на порядок — легко.
А если поменять архитектуру процессора, который сейчас оптимизирован под максимально быстрое выполнение одного треда, то на том-же количестве транзисторов можно сделать раз в 10 больше ядер. Что ускорило бы выполнение моего кода раза в 3-4 как минимум.
IT>У вас какая-то неправильная практика
Понятно. Раз мои задачи не такие как твои, то и я какой-то неправильный.
IT>Это ты про "Hellow, World!"? А ты не пробовал сравнивать бизнес приложения, написанные на Java и на C? Как-нибудь попробуй.
См. выше.
IT>Ты хочешь сказать, что Aero в Висте написано на джаве?
Я хочу сказать, что он нафиг не нужен для выполнения 99% задач. А таскать его приходится всем.
Здравствуйте, remark, Вы писали:
IT>>Что тут непонятного? Инструмент, которым ты пользуещься, кривой по определению.
R>Расскажи это людям, которые делают для тебя ОС, ран-таймы не кривых языков, и реализации продвинутых фич в не кривых языках, которые обеспечили наше общение на RSDN и т.д.
Зачем мне это кому-то ещё рассказывать? Я рассказываю тебе. Ты сам много ОС, ран-таймов и продвинутых фич в языках написал, особенно, которые обеспечили наше общение на RSDN? Мне почему-то кажется ровно ни одной. Так откуда тебе знать какие ресурсы на это положены и сколько девелоперских жизней загублено?
R>Кажется кто-то тут недавно говорил о том, что кривыми по определению инструментами можно сделать только кусок дерьма... возможно я что-то упускаю, но из твоих слов получается что большинство функциональных языков, языков основанных на сборке мусора и т.д. — кусок дерьма в квадрате.
Совершенно верно. Кривым инструментов можно сделать только кривое решение. Но потом можно его бесконечно выпрямлять, тратя на это тысячи человеко-лет.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, mkizub, Вы писали:
M>А если поменять архитектуру процессора, который сейчас оптимизирован под максимально быстрое выполнение одного треда, то на том-же количестве транзисторов можно сделать раз в 10 больше ядер. Что ускорило бы выполнение моего кода раза в 3-4 как минимум.
Ну и какой из этого вывод?
IT>>У вас какая-то неправильная практика
M>Понятно. Раз мои задачи не такие как твои, то и я какой-то неправильный.
Я не говорил про задачи, я говорил про практику
IT>>Ты хочешь сказать, что Aero в Висте написано на джаве?
M>Я хочу сказать, что он нафиг не нужен для выполнения 99% задач. А таскать его приходится всем.
А при чём тут тогда разговоры о JVM?
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, remark, Вы писали:
IT>>>Что тут непонятного? Инструмент, которым ты пользуещься, кривой по определению.
R>>Расскажи это людям, которые делают для тебя ОС, ран-таймы не кривых языков, и реализации продвинутых фич в не кривых языках, которые обеспечили наше общение на RSDN и т.д.
IT>Зачем мне это кому-то ещё рассказывать? Я рассказываю тебе.
Ясно, придётся говорить прямо: я имел в виду, что большая часть базовых уровней в программном стеке (драйвера, ОС, ран-таймы языков, сетевые сервера, сервера баз данных и т.д.) написаны на С/С++. Все эти вещи составляют основу в т.ч. и твоего ПО. Я правильно понимаю, что ты хочешь сказать, что это всё дерьмовое, кривое и работает ненадёжно?
IT>Ты сам много ОС, ран-таймов и продвинутых фич в языках написал, особенно, которые обеспечили наше общение на RSDN? Мне почему-то кажется ровно ни одной. Так откуда тебе знать какие ресурсы на это положены и сколько девелоперских жизней загублено?
Что бы понять, что на С/С++ можно создавать хорошее ПО не обязательно писать именно это. Я пишу другое, никаких жизней при этом не губится, и ПО получается вполне качественное, никаких особых проблем не встречается, память не течёт и т.д.
R>>Кажется кто-то тут недавно говорил о том, что кривыми по определению инструментами можно сделать только кусок дерьма... возможно я что-то упускаю, но из твоих слов получается что большинство функциональных языков, языков основанных на сборке мусора и т.д. — кусок дерьма в квадрате.
IT>Совершенно верно. Кривым инструментов можно сделать только кривое решение. Но потом можно его бесконечно выпрямлять, тратя на это тысячи человеко-лет.
Ну а ты что делаешь со своим ФЯ? Ты его бесконечно выпрямляешь? Тратишь на это тысячи человеко-лет?
Здравствуйте, mkizub, Вы писали:
M>Здравствуйте, IT, Вы писали:
IT>>У вас какая-то неправильная практика
M>Понятно. Раз мои задачи не такие как твои, то и я какой-то неправильный.
Не переживай, я по мнению IT тоже, видимо, неправильный — делаю только куски дерьма и пользуюсь кривыми по-определению инструментами...
Здравствуйте, remark, Вы писали:
R>Ясно, придётся говорить прямо: я имел в виду, что большая часть базовых уровней в программном стеке (драйвера, ОС, ран-таймы языков, сетевые сервера, сервера баз данных и т.д.) написаны на С/С++. Все эти вещи составляют основу в т.ч. и твоего ПО. Я правильно понимаю, что ты хочешь сказать, что это всё дерьмовое, кривое и работает ненадёжно?
Я хочу сказать, что если это и работает более менее надёжно, то только потому, что на это положены ресурсы неадекватные современным средствам разработки. К тому же это всё наследие, с которым приходится мириться, т.к. всё сразу переписать невозможно. Но былая популярность и легами не делает эти приложения супер надёжными и некривыми. К тому же большинство из них внутри могут оказаться редкосным дерьмом и кривизной. Да и надёжность вымученная, и не надёжная такая надёжность. На переполнении буферов выросла вся вирусная индустрия. Надёжность в операционках он нашёл, блин.
R>Что бы понять, что на С/С++ можно создавать хорошее ПО не обязательно писать именно это. Я пишу другое, никаких жизней при этом не губится, и ПО получается вполне качественное, никаких особых проблем не встречается, память не течёт и т.д.
Я тебя поздравляю. Ты довёл до совершенства своё умение ходить по граблям. Только грабли от этого никуда не делись.
IT>>Совершенно верно. Кривым инструментов можно сделать только кривое решение. Но потом можно его бесконечно выпрямлять, тратя на это тысячи человеко-лет.
R>Ну а ты что делаешь со своим ФЯ? Ты его бесконечно выпрямляешь? Тратишь на это тысячи человеко-лет?
Ты можешь продемонстрировать кривизну ФЯ? Давай, а мы послушаем.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, remark, Вы писали:
R>Не переживай, я по мнению IT тоже, видимо, неправильный — делаю только куски дерьма и пользуюсь кривыми по-определению инструментами...
Присоединяюсь к компании неправильных . Впрочем, по мнению IT, судя по всему, есть для любой задачи 2 подхода — один его, другой неправильный
Здравствуйте, remark, Вы писали:
R>Иногда это может помочь, иногда помешать. Это палка о двух концах. Например, в SQL есть много чего для экстремально комфортной работы с данными, однако только на SQL пишут мало реальных систем.
А попробую я некоторые соображения изложить. Благо SQL тут хороший пример , да и LinQ от него недалеко ушел.
В некотором смысле SQL — это понижение размерности задачи на 1. Иными словами, там, где в классических языках мы должны писать цикл, здесь обходимся без цикла
SELECT * FROM table WHERE cond // Где тут цикл, куда он пропал ?
for(int i = 0; i < table.size; i++)
if(table[i].cond)
result.Add(table[i];
Конечно, SQL сервер отнюдь не обязательно устроит линейный просмотр , но идея от этого не изменится. Как ни пиши — в императивном языке без цикла не обойдешься. А почему не обойдешься-то ? Потому что он тут по самой сути задачи присутствует. Ну нельзя выборку из таблицы сделать, не устроив хоть какого-то цикла.
Но SQL от нас все это скрывает. Программист на SQL (не очень хороший может , по крайней мере в теории, вообще не знать, что тут есть цикл. Но он все равно есть! SQL сервер сделал его за нас.
Налицо явное упрощение и SQL рулит! И LinQ как его наследник тоже.
Ну а если еще ORDER или GROUP добавить, то SQL с LinQ вообще рулят. Потому что на императивном языке тут и цикл будет посложнее, а может, и не один цикл понадобится.
Пока все замечательно.
Проблемы начинаются как только потребуется делать что-то, что не укладывается в условие "понизить размерность на единицу". Например, при необходимости работать с этой таблицей не как с массивом из фиксированного числа столбцов и произвольного числа строк, а наоборот. Или вообще с неопределенным числом и того, и другого. Или в ситуации, когда речь идет о каком-то произвольном движении — например, некие окна в этой матрице, плавно меняющие свои координаты и размеры. И т.д. И т.п. В этом случае парадигма понижения размерности на единицу начинает работать против программиста. Потому что с этими окнами хорошо бы ее понизить на 2 (и, кстати, такой язык сделать можно). А для более сложных алгоритмов ее вообще понижать не надо, поскольку это только проблемы создаст, а надо остаться на исходном уровне, и, простите, все ручками да ручками, потому что тут такая игра с индексами в этом массиве, что IEnumerable здесь имеет не больше смысла, чем топор для краснодеревщика.
Но! Для многих и очень многих (в особенности бизнес-)задач, понижение размерности на 1 оказывается очень удобным приемом. Отсюда и процветание SQL — для этих задач. Отсюда и (возможное) процветание LinQ. Те действия, которые адекватно укладываются в схему "понизить размерность на 1", могут быть очень хорошо внутри хоть SQL, хоть LinQ сделаны (иными словами, императивную часть сделали за нас), так что быстродействие будет вполне приличным. Как только мы уйдем от "понизить размерность на 1" — начнется борьба с языком во имя борьбы, с подобающим эффектом.
Так что не надо доводить все до абсурда. Есть некий инструмент — применяйте его там, где его применение оправданно и не лезьте с ним туда, где он совсем неуместен.
IT>>Скорее экстремально кривые. Ты всю память освободил в своих компонентах? Ничего больше не ликает? Ну так пойди и ещё раз проверь.
R>Да нет, ничего не ликает.
Ну как ты не понимаешь! Самое главное при строительстве Эйфелевой башни — это ответ на вопрос, не ушло ли некоторое количество материалов налево!
Подумал и решил на одно твое замечание ответить.
S>Другая категория людей — те, которым интересно получать более правильные решения. Такой человек может при выборе решения предпочитать рантайм-эффективность, удобство для пользователя, или простоту в поддержке. Это уже не так важно — важен сам интерес к улучшению. S>Вот такие люди как раз бросаются на новые изобретения, потому что им интересно улучшить свои решения.
Видишь ли, изобретение изобретению рознь. Если задача — улучшить свои решения, то первый вопрос к этому изобретению — а может ли оно дать такое улучшение ? Например, если речь идет (как в моей работе) о некотором достаточно сложном алгоритме обработки больших матриц, на что я должен бросаться и на что нет ?
На многопоточность — да. Если бы я о ней не знал, и мне бы кто-то сказал, что можно так распараллелить — я должен немедленно этим заняться.
На SSE2 — да. По той же причине.
На матричные процессоры — да. И когда мне заказчик предложил использовать CUDA, я немедленно согласился. Даст это что-то или нет — вопрос сложный, пока не попробуешь — не поймешь (сейчас уже могу сказать — даст).
А вот на Java, C#, LinQ, Хаскель и т.д — нет. Потому что априорно ясно, что в этой задаче от них никакой пользы не будет.
А могут быть ситуации в точности наоборот. Вот представь себе программиста, которого "заморозили" с 80-х годов. Он тогда на С++ CGI-сайты писал, и до сих пор их пишет . И тут ему говорят, что есть , мол, гораздо более эффективные средства это делать. Он должен немедленно за эти средства сесть и их изучать. А вот если ему предложать эти CGI программы улучшать, перейдя с C++ на asm, то он должен советчика послать туда же, куда я должен послать того, кто мне порекомендует делать сложную обработку матрицы с требованиями наивысшего быстродействия на Java или C#.
Здравствуйте, Pavel Dvorkin, Вы писали: PD>В некотором смысле SQL — это понижение размерности задачи на 1.
Не могу согласиться. Ты же дальше сам приводишь примеры про join и group — где там на 1? Там и на 10 может понизиться.
Или я неправильно понимаю понятие "размерности задачи"?
Далее. Про "невозможность выбрать данные из таблицы без цикла" мне совершенно непонятно. Эдак рассуждая, и умножить два числа без цикла нельзя — там же сложения и сдвиги. Впрочем, сложение без цикла тоже не организуешь, потому что он там присутствует "по самой сути задачи". Помните, как в первом классе учили сложению в столбик? Ведь самый был натуральнейший цикл.
Тем не менее, никто при программировании не задумывется о природе циклов для сложения и умножения. Тем более, что "линейный просмотр" процессору организовывать не обязательно.
Поэтому не мог ли бы ты поподробнее осветить насчет "понижения размерности на два" и прочих высокофилософских терминов?
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Pavel Dvorkin, Вы писали: PD>Видишь ли, изобретение изобретению рознь. Если задача — улучшить свои решения, то первый вопрос к этому изобретению — а может ли оно дать такое улучшение ? Например, если речь идет (как в моей работе) о некотором достаточно сложном алгоритме обработки больших матриц, на что я должен бросаться и на что нет ?
Это зависит от очень большого количества факторов, которые ты тщательно скрываешь. PD>На многопоточность — да. Если бы я о ней не знал, и мне бы кто-то сказал, что можно так распараллелить — я должен немедленно этим заняться. PD>На SSE2 — да. По той же причине. PD>На матричные процессоры — да. И когда мне заказчик предложил использовать CUDA, я немедленно согласился. Даст это что-то или нет — вопрос сложный, пока не попробуешь — не поймешь (сейчас уже могу сказать — даст). PD>А вот на Java, C#, LinQ, Хаскель и т.д — нет. Потому что априорно ясно, что в этой задаче от них никакой пользы не будет.
Вот простой вымышленный пример: пусть у нас основная задача — перемножать матрицы. Большого размера и в больших количествах.
Но при анализе мы выясняем, что заметная доля этих матриц — единичные или нулевые.
Тогда у нас возникает искушение подправить наши алгоритмы так, чтобы они учитывали этот факт. И цепочка A*B*C*D*E вычислялась бы значительно быстрее, если B и D равны I. А если любая из матриц — нулевая, то вся цепочка бы вычислялась мгновенно.
На языках с развитой системой типов (например, Хаскеле) мы могли бы обеспечить это даже статически.
На С++ — только в рантайме, и только тщательным выверением всех алгоритмов.
PD>А могут быть ситуации в точности наоборот. Вот представь себе программиста, которого "заморозили" с 80-х годов. Он тогда на С++ CGI-сайты писал, и до сих пор их пишет . И тут ему говорят, что есть , мол, гораздо более эффективные средства это делать. Он должен немедленно за эти средства сесть и их изучать. А вот если ему предложать эти CGI программы улучшать, перейдя с C++ на asm, то он должен советчика послать туда же, куда я должен послать того, кто мне порекомендует делать сложную обработку матрицы с требованиями наивысшего быстродействия на Java или C#.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>А вот на Java, C#, LinQ, Хаскель и т.д — нет. Потому что априорно ясно, что в этой задаче от них никакой пользы не будет.
Хаскель может и помочь. Например, ты можешь сделать набор высокопроизводительных базовых операций с матрицами, а комбинировать их в сложные алгоритмы уже на Хаскеле. Никто не отменял возможности использовать сишные библиотеки, там где надо работать с железом или на максимум загрузить процессор и т.п. Подключить эту либу можно конечно и к жаве с додиезом, но таких возможностей как Хаскелл они не дадут.
Поможет это или нет в твоём конкретном случае — . Всё зависит от задачи.
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Здравствуйте, mkizub, Вы писали:
M>Здравствуйте, IT, Вы писали:
IT>>Это потому, что для этого нет адекватных средств. Точнее уже есть. Вот прямо сейчас я делаю язык для своих задач и работать он будет быстрее и надёжднее кода, написанного ручками, просто потому, что в ручном коде я должен беспокоиться ещё и о поддержке этого кода, в в сгенерированном мне это до лампочки.
M>Вот именно. Это то, о чём я тебе и говорю. Ты создаёшь средство, которое позволит писать программы на языке с высоким уровнем абстракции, M>не используя промежуточных уровней, а используя кодогенерацию написанную специально для конкретного класса задач. M>А теперь представь себе, что он генерирует код не для конкретно .NET или конкретно JVM, а для конкретной аппаратной платформы, M>и даже для конкретного компьютера (с его конкретным числом ядер, размером памяти, кэша и прочее). M>А теперь представь себе, что изготовители CPU тоже просекли фишку с адаптируемостью, и стали делать адаптируемые (конфигурирумые под M>конкретные задачи) процессоры. И ты можешь писать макросы, которые будут при компиляции учитывать эти возможности. M>Ты можешь оценить степень оптимизации подобного приложения по сравнению с существующими?
Ну так ты же только что доказал опровержение своего собственного утверждения. Ты рассказал про язык с высоким уровнем абстракции, который генерирует высокооптимизированный код. Если уровень абстракции языка недостаточно высок, он будет генерировать неоптимальный код.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Pavel Dvorkin, Вы писали: S>Это зависит от очень большого количества факторов, которые ты тщательно скрываешь.
Безусловно
S>Вот простой вымышленный пример: пусть у нас основная задача — перемножать матрицы. Большого размера и в больших количествах. S>Но при анализе мы выясняем, что заметная доля этих матриц — единичные или нулевые. S>Тогда у нас возникает искушение подправить наши алгоритмы так, чтобы они учитывали этот факт. И цепочка A*B*C*D*E вычислялась бы значительно быстрее, если B и D равны I. А если любая из матриц — нулевая, то вся цепочка бы вычислялась мгновенно.
S>На языках с развитой системой типов (например, Хаскеле) мы могли бы обеспечить это даже статически. S>На С++ — только в рантайме, и только тщательным выверением всех алгоритмов.
Да какая такая выверка нужна ? Банальная проверка и все. Да, в рантайме.
Здравствуйте, Sinclair, Вы писали:
S>Ну так ты же только что доказал опровержение своего собственного утверждения. Ты рассказал про язык с высоким уровнем абстракции, который генерирует высокооптимизированный код. Если уровень абстракции языка недостаточно высок, он будет генерировать неоптимальный код.
Мальчик: Дяденька, хотите я анекдот расскажу?
Дядя: Я не дяденька, я милиционер!
Мальчик: Хорошо, тогда я медленно и два раза
(с) anekdot.ru
Повторяю ещё раз.
Мешают промежуточные уровни абстракции. Через которые ты не можешь перепрыгнуть.
Любая программа в конечном итоге исполняется как изменение состояния транзисторов.
Вот только я не могу напрямую из программы изменять состояния транзисторов.
Мне надо выразить мои высокоуровневые абстракции через низкоуровневые абстракции языка программирования.
А они потом будут выражены через байткод VM.
А он будет выражен через инструкции CPU и OS API.
А те будут выражены через комманды блоками CPU и всякого рода аппаратным интерфейсам (шины и пр.).
И только потом уже будут транзисторы.
И через эти промежуточные уровни абстракции я никак не могу перепрыгнуть. А их недостаточно, чтоб оптимально исполнить мою программу.
Например, я не могу использовать goto если его нет в языке программирования (в Java например). Несмотря на то, что в JVM есть goto.
Хорошо, я сделал кучу работы и написал свой язык программирования, в котором есть goto.
И даже с ним я не могу использовать указатели, потому как их нет в JVM, хотя в инструкциях CPU они есть.
Чтоб их использовать мне нужно написать свою VM.
Но даже со своей VM я не могу аппаратно пометить ячейку памяти как (word32 || ()->word32), чтоб CPU при комманде "взять значение"
проверил, это word32, или это ссылка на функцию, которая должна вернуть word32 (и если ссылка — выполнить эту функцию, и внести результат в эту же ячейку памяти, и после этого отдать мне это значение). Потому как в инструкциях CPU и его модели памяти нет таких абстракций. Хотя если бы я смог сделать свой CPU — моя программа с lazy вычислениями кушала бы ну намного меньше памяти и код был-бы намного меньше и исполнялся быстрее.
VD>... Даже если вы возьметесь решать сложную вычислительную задача скажем на Хаскеле, то вы все равно будете вынуждены заниматься оптимизациями, а значит и иметь где-то изменяемое состояние.
Сразу видно, что человек много писал на Хаскеле и много занимался оптимизациями Хаскельных программ.
Вот так взял, да и сказал своё веское слово.
VD>А так все просто. Функциональный код = отсутствие разделяемого состояния. Отсутствие разделяемого состояния = легкое распараллеливание.
Ха-ха.
Чем отличаются ассоциативные операции от ассоциативных, похоже, ты не знаешь.
Так вот, ассоциативные операции параллелятся: a+(b+(c+d))==(a+b)+(c+d). Если мы не можем переставить скобочки, то мы не можем распараллелить.
Ассоциативных операций не так уж и много: сложение, умножение, минимум, максимум и некоторые (не все!) их комбинации.
VD>В том же компиляторе основная работа — это типизация методов/функций (операторов в программах по определению во много раз больше чем скажем методов). Методов/функций в большой программе много и если у нас нет глобального вывода типов, то каждый метод можно типизироваться отдельно.
Это справедливо только для независимых друг от друга функций. Если они зависят друг от друга, то все, процесс становится последовательным.
Статистики, опровергающей твои слова, у меня нет, но и у тебя нет статистики, подтверждающей твои.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
M>...Это совершенно другой способ программировать, более близкий к нейронным сетям, чем к программированию в нынешнем понимании этого процесса.
"Кто о чем, а вшивый о бане." русская пословица
Не "кибернетика Винера", так "нейронные сети".
Есть такое понятие — динамический поток данных. Так вот, оный dynamic dataflow очень хорошо распараллеливается как раз на много мелких (совсем мелких) процессоров.
Все работает умеренно хорошо. У меня, просто, нет ресурсов добить её до высокого уровня.
M>В таких условиях будет лучше работать что-то вроде erlang-а, но именно в силу его ориентированности на приём сообщения (данных), простую обработку, посылку сообщения дальше. То есть модель "актёров". Что действительно никакого отношения к FP не имеет.
Актёр обязательно содержит состояние внутри. А это плохо. Лучше всего параллелятся вычисления без состояния, когда состояние разбивается на много маленьких кусочков и протаскивается только в нужные места.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Pavel Dvorkin, Вы писали: PD>>В некотором смысле SQL — это понижение размерности задачи на 1. S>Не могу согласиться. Ты же дальше сам приводишь примеры про join и group — где там на 1? Там и на 10 может понизиться. S>Или я неправильно понимаю понятие "размерности задачи"?
Я имею в виду, что мы оперируем с массивами как со скалярами. Точнее, с линейными массивами как со скалярами. join даст нам в конечном счете тоже линейный массив (не двумерный), group — тоже.
S>Далее. Про "невозможность выбрать данные из таблицы без цикла" мне совершенно непонятно. Эдак рассуждая, и умножить два числа без цикла нельзя — там же сложения и сдвиги. Впрочем, сложение без цикла тоже не организуешь, потому что он там присутствует "по самой сути задачи". Помните, как в первом классе учили сложению в столбик? Ведь самый был натуральнейший цикл.
Не надо передергивать. Мы обсуждаем то, что делает софт, а не процессор. Вот когда я буду сверхдлинные числа складывать программно — тогда и будет этот самый цикл.
S>Тем не менее, никто при программировании не задумывется о природе циклов для сложения и умножения. Тем более, что "линейный просмотр" процессору организовывать не обязательно.
S>Поэтому не мог ли бы ты поподробнее осветить насчет "понижения размерности на два" и прочих высокофилософских терминов?
Если бы мы могли работать с двумерными массивами как со скалярами — это оно и было бы.
Некий несуществующий язык
М = SELECT * FROM TABLE WHERE ROW > 0 && ROW < 10 && COLUMN > 0 && COLUMN < 10
берет из двумерного массива (элементы которого могут быть структурой любого вида) окно размером 10*10 и представляет эту матрицу как скаляр
UPDATE M WHERE ROW > 4 && ROW <= 8 && COLUMN > 4 && COLUMN <= 8 SET ANYFIELD = 10
изменяет подокно 4*4
Качество и смысл такого языка я обсуждать не буду. Тебе нужно было объяснение того, что такое понижение на 2 — я его привел.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>А вот на Java, C#, LinQ, Хаскель и т.д — нет. Потому что априорно ясно, что в этой задаче от них никакой пользы не будет.
PD>А могут быть ситуации в точности наоборот. Вот представь себе программиста, которого "заморозили" с 80-х годов. Он тогда на С++ CGI-сайты писал, и до сих пор их пишет . И тут ему говорят, что есть , мол, гораздо более эффективные средства это делать. Он должен немедленно за эти средства сесть и их изучать.
Ой. А я-то думал он должен ответить, что априорно ясно, что на С++ писать сайты — наиболее эффективно, ибо ближе к железу и, значит, возможностей для оптимизации больше...
Что мне нравится в твоем подходе — это отличное чувство предвидения. То есть слышишь слово "SSL2" — сразу очевидно — очень поможет перемножать матрицы. Слышишь слово — "Хаскель" — сразу очевидно, что для перемножения матриц — бесполезен. И неважно, что у него наибольная популярность — именно в академических кругах для мат.вычислений. Априорно же ясно — не может тут быть от него пользы.
Или может ты SSL2 изучал, а про Хаскель только быстро полистал на форуме?
Ну про примеры на C# и linq для перемножения матриц, в т.ч. с простым распараллеливанием, которые тебе писали тут — это я уж и не говорю, тут все априорно (tm) ясно.
Здравствуйте, IT, Вы писали:
PD>>Присоединяюсь к компании неправильных .
IT>И это правильно.
PD>>Впрочем, по мнению IT, судя по всему, есть для любой задачи 2 подхода — один его, другой неправильный
IT>Не угадал. Есть два подхода, один правильный, другой на C++
Приятно, что ты хотя бы признаешь ограниченность своих взглядов... В принципе, от человека с таким взглядом мне даже как-то и не особо обидно слышать, что я неправильный — слаба богу, что объектива тут мало...
Здравствуйте, Sinclair, Вы писали:
S>На языках с развитой системой типов (например, Хаскеле) мы могли бы обеспечить это даже статически. S>На С++ — только в рантайме, и только тщательным выверением всех алгоритмов.
С++ обладает одной из самых развитых статических систем типов среди всех языков, и сделать это во время компиляции на С++ — не проблема. Собственно это — одна из сильных сторон С++ — генерация типов во время компиляции, генерация кода во время компиляции (различные проверки, диспатч реализации, циклы и т.д.).
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Я имею в виду, что мы оперируем с массивами как со скалярами. Точнее, с линейными массивами как со скалярами. join даст нам в конечном счете тоже линейный массив (не двумерный), group — тоже.
Вообще-то нет.
Если вспомнить реляционную алгебру, то отношение с N+M колонками можно трактовать как N-мерный разреженный массив с М-компонентными значениями.
Здесь N — размерность ключа, M — количество неключевых колонок.
Группировка выполняет операцию, аналогичную свертке тензора — она понижает размерность на произвольную величину.
PD>Не надо передергивать. Мы обсуждаем то, что делает софт, а не процессор. Вот когда я буду сверхдлинные числа складывать программно — тогда и будет этот самый цикл.
Я не передергиваю. Я говорю про уровни абстракции. Процессор предлагает удобный уровень абстракции по работе с числами.
Библиотека по работе с длинными числами — тоже. Тебе, как клиенту библиотеки, всё равно, как она там внутри работает — софтно или аппаратно.
PD>Если бы мы могли работать с двумерными массивами как со скалярами — это оно и было бы.
PD>Некий несуществующий язык
PD>М = SELECT * FROM TABLE WHERE ROW > 0 && ROW < 10 && COLUMN > 0 && COLUMN < 10
Почему же несуществующий? Вполне себе существующий язык SQL — если только исправить синтаксические ошибки. Именно так всё и работает.
PD>Качество и смысл такого языка я обсуждать не буду. Тебе нужно было объяснение того, что такое понижение на 2 — я его привел.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, mkizub, Вы писали: M>Повторяю ещё раз. M>Мешают промежуточные уровни абстракции. Через которые ты не можешь перепрыгнуть.
Значит плохо выбраны промежуточные абстракции. Слишком они низкоуровневые.
M>Любая программа в конечном итоге исполняется как изменение состояния транзисторов. M>Вот только я не могу напрямую из программы изменять состояния транзисторов.
M>Мне надо выразить мои высокоуровневые абстракции через низкоуровневые абстракции языка программирования. M>А они потом будут выражены через байткод VM. M>А он будет выражен через инструкции CPU и OS API. M>А те будут выражены через комманды блоками CPU и всякого рода аппаратным интерфейсам (шины и пр.). M>И только потом уже будут транзисторы. M>И через эти промежуточные уровни абстракции я никак не могу перепрыгнуть. А их недостаточно, чтоб оптимально исполнить мою программу.
Вот это утверждение было бы неплохо как-то доказать. M>Например, я не могу использовать goto если его нет в языке программирования (в Java например). Несмотря на то, что в JVM есть goto. M>Хорошо, я сделал кучу работы и написал свой язык программирования, в котором есть goto. M>И даже с ним я не могу использовать указатели, потому как их нет в JVM, хотя в инструкциях CPU они есть. M>Чтоб их использовать мне нужно написать свою VM.
А зачем тебе указатели? Чтобы закрыть компилятору/среде возможности оптимизации?
M>Но даже со своей VM я не могу аппаратно пометить ячейку памяти как (word32 || ()->word32), чтоб CPU при комманде "взять значение" M>проверил, это word32, или это ссылка на функцию, которая должна вернуть word32 (и если ссылка — выполнить эту функцию, и внести результат в эту же ячейку памяти, и после этого отдать мне это значение).
Можешь. Как по-твоему работает виртуальная память?
На самом деле лучше такие вещи не делать вообще. Это мешает процессору эффективно выполнять твой код, потому что он не сможет предсказывать переходы и использовать конвеер. Это плохой уровень абстракции. M>Потому как в инструкциях CPU и его модели памяти нет таких абстракций. Хотя если бы я смог сделать свой CPU — моя программа с lazy вычислениями кушала бы ну намного меньше памяти и код был-бы намного меньше и исполнялся быстрее.
Видишь ли, в чем дело. В последний раз, когда я общался на аналогичные темы по поводу ограничений языка C++ насчет контроля над регистрами и прочей ерундой, я попросил адвоката low level показать мне, какой именно ассемблерный код он не может получить от компилятора плюсов.
Он показал. rep scansd, всё такое. Увы, его код исполнялся медленнее. Поэтому у меня есть обоснованные сомнения в том, что "твоя программа с lazy вычислениями" выполнялась бы быстрее, если бы ты мог перешить процессор.
M>Понятно, или ещё раз повторить?
Непонятно. Повторять не надо.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, remark, Вы писали:
S>>На языках с развитой системой типов (например, Хаскеле) мы могли бы обеспечить это даже статически. S>>На С++ — только в рантайме, и только тщательным выверением всех алгоритмов.
R>С++ обладает одной из самых развитых статических систем типов среди всех языков, и сделать это во время компиляции на С++ — не проблема. Собственно это — одна из сильных сторон С++ — генерация типов во время компиляции, генерация кода во время компиляции (различные проверки, диспатч реализации, циклы и т.д.).
Хаскелевская кстати тоже статическая и на ней тоже вполне проходят все фокусы C++ типа вычисления факториала в compile time.
Теоретически они конечно вполне равномощны, но на практике у C++'сной слишком резок порог сложности, на ней просто и легко делать только тривиальные вещи, хотя тот же D показывает что очень похожую, можно сильно улучшить.
Здравствуйте, Sinclair, Вы писали:
M>>Мешают промежуточные уровни абстракции. Через которые ты не можешь перепрыгнуть. S>Значит плохо выбраны промежуточные абстракции. Слишком они низкоуровневые.
Без разницы. Если я возьму какой-нибудь JSP, то он всё равно будет через Java работать.
Если наш дополнительный промежуточный уровень абстракции не позволяет делать все операции поддерживаемые более низким уровнем абстракции — то он неоптимален для решения всех задач, а только для небольшой части задач которым не нужны дополнительные низкоуровневые операции. Если позволяет — то он будет сложнее в реализации, чем более низкий уровень абстракции, если вообще возможен. Возьми ту-же JVM — она может быть реализована так, чтоб позволить выполнять все операции CPU на котром она работает и все операции OS на которой она работает?
А реализация хорошего промежуточного уровня абстракции — стоит очень дорого. Сколько стоит реализовать JVM? Не как простой интерпретатор, а хорошо её реализовать, с JIT компиляцией и прочей оптимизацией?
M>>И через эти промежуточные уровни абстракции я никак не могу перепрыгнуть. А их недостаточно, чтоб оптимально исполнить мою программу. S>Вот это утверждение было бы неплохо как-то доказать.
Это очевидно.
S>А зачем тебе указатели? Чтобы закрыть компилятору/среде возможности оптимизации?
Мой компилятор, ориентированный на нужды моего проекта — сделает оптимизацию лучше.
M>>Но даже со своей VM я не могу аппаратно пометить ячейку памяти как (word32 || ()->word32), чтоб CPU при комманде "взять значение" M>>проверил, это word32, или это ссылка на функцию, которая должна вернуть word32 (и если ссылка — выполнить эту функцию, и внести результат в эту же ячейку памяти, и после этого отдать мне это значение). S>Можешь. Как по-твоему работает виртуальная память?
Не могу. Затраты будут больше, чем выигрыш.
Я и из Java могу вызвать native метод. Вот только их вызов стоит очень дорого.
Теоретическая возможность исполнить любую программу на машине Тьюринга не означает, что эта возможность практически полезна.
S>На самом деле лучше такие вещи не делать вообще. Это мешает процессору эффективно выполнять твой код, потому что он не сможет предсказывать переходы и использовать конвеер. Это плохой уровень абстракции.
А какая альтернатива? Делать проверку каждый раз вручную и если нужно — вызывать этот метод. При этом все переходы и конвеер всё так же ломается.
На аппаратном уровне эта проверка бы делалась практически бесплатно.
И кто сказал, что количество транзисторов потраченное на все эти конвееры и предсказания я не мог бы лучше использовать? Вместо одного ядра я бы сделал 16 специализированных под решение моего типа задач, из того же числа транзисторов. И оно бы летало намного быстрее. Если я могу распараллелить свою задачу. И наоборот, если не могу — то лучше сделать один сверх-умный проц, а не 16 тупых.
M>>Потому как в инструкциях CPU и его модели памяти нет таких абстракций. Хотя если бы я смог сделать свой CPU — моя программа с lazy вычислениями кушала бы ну намного меньше памяти и код был-бы намного меньше и исполнялся быстрее. S>Видишь ли, в чем дело. В последний раз, когда я общался на аналогичные темы по поводу ограничений языка C++ насчет контроля над регистрами и прочей ерундой, я попросил адвоката low level показать мне, какой именно ассемблерный код он не может получить от компилятора плюсов. S>Он показал. rep scansd, всё такое. Увы, его код исполнялся медленнее. Поэтому у меня есть обоснованные сомнения в том, что "твоя программа с lazy вычислениями" выполнялась бы быстрее, если бы ты мог перешить процессор.
Исчёбы. На процессоре с внутренней архитектурой ориентированной на иные модели вычисления — чего-ж ты хотел?
Я же не о микрокоде говорю.
S>Непонятно. Повторять не надо.
Здравствуйте, remark, Вы писали:
R>Приятно, что ты хотя бы признаешь ограниченность своих взглядов...
Странно слышать про ограниченность от человека никчего кроме про C++ слышать не желающего. Не правда ли? Я уже предлагал здесь одному перестать рассматривать мир через замочную скважину и просто открыть дверь. Могу посоветовать тоже самое и тебе. Может оказаться, что мир гораздо интереснее и разнообразнее, и не ограничен одними плюсами.
Неясность изложения обычно происходит от путаницы в мыслях.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, mkizub, Вы писали:
M>Без разницы. Если я возьму какой-нибудь JSP, то он всё равно будет через Java работать.
Ну и что. M>Если наш дополнительный промежуточный уровень абстракции не позволяет делать все операции поддерживаемые более низким уровнем абстракции — то он неоптимален для решения всех задач, а только для небольшой части задач которым не нужны дополнительные низкоуровневые операции.
Это неплохо бы доказать. Потому что задача промежуточного уровня — не в том, чтобы дать тебе доступ к низкоуровневым операциям. А в том, чтобы представить тебе некий другой базис, в котором ты выполняешь свои решения. M>Если позволяет — то он будет сложнее в реализации, чем более низкий уровень абстракции, если вообще возможен. Возьми ту-же JVM — она может быть реализована так, чтоб позволить выполнять все операции CPU на котром она работает и все операции OS на которой она работает?
Конечно может. А в чём проблема? M>А реализация хорошего промежуточного уровня абстракции — стоит очень дорого. Сколько стоит реализовать JVM? Не как простой интерпретатор, а хорошо её реализовать, с JIT компиляцией и прочей оптимизацией?
Это неважно. Достаточно реализовать эту JVM один раз для целевой архитектуры. S>>Вот это утверждение было бы неплохо как-то доказать. M>Это очевидно.
Это неочевидно. S>>А зачем тебе указатели? Чтобы закрыть компилятору/среде возможности оптимизации? M>Мой компилятор, ориентированный на нужды моего проекта — сделает оптимизацию лучше.
На слово — не верю.
M>Я и из Java могу вызвать native метод. Вот только их вызов стоит очень дорого.
M>А какая альтернатива? Делать проверку каждый раз вручную и если нужно — вызывать этот метод. При этом все переходы и конвеер всё так же ломается.
Альтернатива — думать головой.
Например, понять, что можно инлайнить обращение к ячейке прямо в том месте, где раньше был вызов метода. При этом переходы и конвеер сломаются только в первый раз. Дальше всё будет шарашить со страшной скоростью. Если мест вызова много — сделать банальный косвенный вызов, как в таблице импорта DLL. Процессор предсказывает такие переходы лучше, чем твоя гипотетическая "проверка на аппаратном уровне". M>На аппаратном уровне эта проверка бы делалась практически бесплатно. M>И кто сказал, что количество транзисторов потраченное на все эти конвееры и предсказания я не мог бы лучше использовать? Вместо одного ядра я бы сделал 16 специализированных под решение моего типа задач, из того же числа транзисторов. И оно бы летало намного быстрее. Если я могу распараллелить свою задачу. И наоборот, если не могу — то лучше сделать один сверх-умный проц, а не 16 тупых.
Предлагаю про транзисторы не рассуждать, поскольку динамически перекраивать кремний мы пока не умеем. А статически готовить микросхемы под твой тип задач, надо полагать, слишком дорого.
Предлагаю рассуждать всё же на уровне софта.
S>>Видишь ли, в чем дело. В последний раз, когда я общался на аналогичные темы по поводу ограничений языка C++ насчет контроля над регистрами и прочей ерундой, я попросил адвоката low level показать мне, какой именно ассемблерный код он не может получить от компилятора плюсов. S>>Он показал. rep scansd, всё такое. Увы, его код исполнялся медленнее. Поэтому у меня есть обоснованные сомнения в том, что "твоя программа с lazy вычислениями" выполнялась бы быстрее, если бы ты мог перешить процессор. M>Исчёбы. На процессоре с внутренней архитектурой ориентированной на иные модели вычисления — чего-ж ты хотел?
На какие "иные"? Я говорю о том, что гонор типа "да я лучше всех знаю, как быстрее мои программы исполнять" обычно необоснован. M>Тогда думай. Если хочешь понять.
Взаимно.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
M>>Это очевидно. S>Это неочевидно.
Помнится, у нас в универе бродил шуточный листик с "расшифровкой" некорректных терминов, испольуземых при доказательствах.
В частности, "Очевидно" там расшифровывалось как-то вроде "Вот нутром чую, что это так, а доказать не могу".
Здравствуйте, remark, Вы писали:
R>Я и не начинаю, это ты спустился на частности и ушёл в сторону. Для меня язык не сильно принципиален, и будет 3 строчек кода или 7 тоже не особо интересует.
Язык не принципиален, пока от экпериментов и небольших приложений мы не перейдем к большим объемам production quality кода.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>
Здравствуйте, FR, Вы писали:
FR>Хаскелевская кстати тоже статическая и на ней тоже вполне проходят все фокусы C++ типа вычисления факториала в compile time.
Только оно при этом не выглядит как чес левой ногой за правым ухом.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>
Вот только, как человек, который с ними лет 10 назад возился всерьез, могу заверить, что использовать сие без сложнейшего компилятора в хардвару (который сам по себе челендж на порядок покруче оптимизирующих компиляторов для VLIW, с чем, как показала практика, так особо и не справились пока) невозможно. Рассчитывать на то, что прикладной программист или даже разработчик компилятора ЯВУ будет этим заниматься сам — безумие.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>
Здравствуйте, IT, Вы писали:
R>>Кажется кто-то тут недавно говорил о том, что кривыми по определению инструментами можно сделать только кусок дерьма... возможно я что-то упускаю, но из твоих слов получается что большинство функциональных языков, языков основанных на сборке мусора и т.д. — кусок дерьма в квадрате.
IT>Совершенно верно. Кривым инструментов можно сделать только кривое решение. Но потом можно его бесконечно выпрямлять, тратя на это тысячи человеко-лет.
Ничего не понял. Так можно из дерьма конфетку слепить, получается? Или таки только дерьмо получится? Вы уж как-нибудь определитесь.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, remark, Вы писали:
R>>Приятно, что ты хотя бы признаешь ограниченность своих взглядов...
IT>Странно слышать про ограниченность от человека никчего кроме про C++ слышать не желающего. Не правда ли? Я уже предлагал здесь одному перестать рассматривать мир через замочную скважину и просто открыть дверь. Могу посоветовать тоже самое и тебе. Может оказаться, что мир гораздо интереснее и разнообразнее, и не ограничен одними плюсами.
Там если до края мира дойти, будет ещё одна дверь. Это не мир, а просто другая комната.
Здравствуйте, VoidEx, Вы писали:
IT>>Совершенно верно. Кривым инструментов можно сделать только кривое решение. Но потом можно его бесконечно выпрямлять, тратя на это тысячи человеко-лет.
VE>Ничего не понял. Так можно из дерьма конфетку слепить, получается? Или таки только дерьмо получится? Вы уж как-нибудь определитесь.
Конфетку сделать не получится. Но внешне отполированный до блеска кусок дерьма внутри может и получится сделать. Только внуть лучше не заглядывать, пахнуть конфетами там не будет.
Неясность изложения обычно происходит от путаницы в мыслях.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Mr.Cat, Вы писали:
PD>>А вот когда приходится решать задачи, в которых нужно от компьютера взять все, что он может (как твой рейтрейсер) — тогда все эти рассуждения летят к чертовой бабушке. MC>Интересно, а как бы в этой задаче выглядел OCaml? http://www.ffconsultancy.com/languages/ray_tracer/comparison.html
now playing: Boris Brejcha — Die Maschinen Marschieren
Здравствуйте, Sinclair, Вы писали:
S>Видишь ли, в чем дело. В последний раз, когда я общался на аналогичные темы по поводу ограничений языка C++ насчет контроля над регистрами и прочей ерундой, я попросил адвоката low level показать мне, какой именно ассемблерный код он не может получить от компилятора плюсов. S>Он показал. rep scansd, всё такое. Увы, его код исполнялся медленнее. Поэтому у меня есть обоснованные сомнения в том, что "твоя программа с lazy вычислениями" выполнялась бы быстрее, если бы ты мог перешить процессор.
А не мог бы ты ответить на такой вопрос. Есть в процессоре набор инструкций SSE (разные версии). C# компилятор их, насколько я знаю, не генерирует, C++ — тоже, но они доступны как intrinsic (==ассемблер, только без asm). Вопрос же такой — может ли и должен ли компилятор принять решение об их использовании и когда ?
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>А не мог бы ты ответить на такой вопрос. Есть в процессоре набор инструкций SSE (разные версии). C# компилятор их, насколько я знаю, не генерирует, C++ — тоже,
С++ запросто генерирует.
PD>но они доступны как intrinsic (==ассемблер, только без asm). Вопрос же такой — может ли и должен ли компилятор принять решение об их использовании и когда ?
Здравствуйте, AndrewVK, Вы писали:
AVK>http://en.wikipedia.org/wiki/FPGA
Я в курсе. Насколько мне известно, перформанс у FPGA всё же не тот, что у мейнстрима.
Поэтому использование их "для оптимизации" мне показалось несколько бесполезным. AVK>Вот только, как человек, который с ними лет 10 назад возился всерьез, могу заверить, что использовать сие без сложнейшего компилятора в хардвару (который сам по себе челендж на порядок покруче оптимизирующих компиляторов для VLIW, с чем, как показала практика, так особо и не справились пока) невозможно. Рассчитывать на то, что прикладной программист или даже разработчик компилятора ЯВУ будет этим заниматься сам — безумие.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>А не мог бы ты ответить на такой вопрос. Есть в процессоре набор инструкций SSE (разные версии). C# компилятор их, насколько я знаю, не генерирует, C++ — тоже, но они доступны как intrinsic (==ассемблер, только без asm). Вопрос же такой — может ли и должен ли компилятор принять решение об их использовании и когда ?
Смотря что мы понимаем под компилятором. Ну то есть если это компилятор в x86 код, то да, именно он должен принять это решение. Когда — в момент компиоляции, естественно. Поэтому нужно позаботиться о том, чтобы в этот момент компилятору было известно, какая версия SSE ему доступна.
Если мы говорим про компилятор C#->MSIL, то он естественно не может и не должен принимать такого решения. Потому, что в целевом языке никаких SSE нету.
Такое решение должен принимать компилятор MSIL->x86, в момент JIT-компиляции.
Mkizub считает, что это очень плохо — MSIL, как промежуточный уровень, не даёт C# компилятору доступа к SSE. Я считаю, что это бред — потому, что у JIT компилятора есть вся та же информация, что у C#, плюс еще и информация о целевой архитектуре. Поэтому он примет более правильное решение. Как раз благодаря тому, что MSIL такой весь бедный и невыразительный.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Если вспомнить реляционную алгебру, то отношение с N+M колонками можно трактовать как N-мерный разреженный массив с М-компонентными значениями. S>Здесь N — размерность ключа, M — количество неключевых колонок. S>Группировка выполняет операцию, аналогичную свертке тензора — она понижает размерность на произвольную величину.
Трактуй как хочешь. Результатом является линейный массив, а как он получается — не суть важно.
S>Я не передергиваю. Я говорю про уровни абстракции. Процессор предлагает удобный уровень абстракции по работе с числами. S>Библиотека по работе с длинными числами — тоже. Тебе, как клиенту библиотеки, всё равно, как она там внутри работает — софтно или аппаратно.
Обсуждать не буду, как не имеющее к делу отношения.
PD>>Если бы мы могли работать с двумерными массивами как со скалярами — это оно и было бы.
PD>>Некий несуществующий язык
PD>>М = SELECT * FROM TABLE WHERE ROW > 0 && ROW < 10 && COLUMN > 0 && COLUMN < 10 S>Почему же несуществующий? Вполне себе существующий язык SQL — если только исправить синтаксические ошибки. Именно так всё и работает.
Тогда исправь и верни мне это окно. Только учти, что ROW и COLUMN — это не поля таблицы, а таблица БД должна содержать произвольно варьируемое сисло этих COLUMN.
Здравствуйте, fmiracle, Вы писали:
F>Что мне нравится в твоем подходе — это отличное чувство предвидения. То есть слышишь слово "SSL2" — сразу очевидно — очень поможет перемножать матрицы. Слышишь слово — "Хаскель" — сразу очевидно, что для перемножения матриц — бесполезен.
Маленькое передергивание. Уточняю.
Слышу слово SSE2 , выясняю, что это такое (для этого много временине требуется, досточно введение почитать) и предполагаю, что это поможет быстрее перемножить матрицы. Слышу слово Хаскель , выясняю, что это такое и предполагаю, что это не поможет быстрее перемножить матрицы.
Разницу чувствуешь ?
>И неважно, что у него наибольная популярность — именно в академических кругах для мат.вычислений.
Вот именно. Кстати, программа, с которой я работаю — исходный алгоритм написан на С++, но очень уж академически (и сделана в одном из университетов Германии). Именно поэтому мне удалось повысить ее быстродействие в 20 раз , а объем памяти уменьшить в 2 раза. Если бы ее профессионалы писали — ничего бы я не сделал.
Спасибо. Не знал. Но толку от этого немного — реально надо код менять, чтобы по 4 пары одновременно обрабатывать. Автоматически он не хочет, по крайней мере у меня не сгенерировал.
Кстати, у Intel C++ есть
parallel, Qparallel
Tells the auto-parallelizer to generate multithreaded code for loops that can be safely executed in parallel.
IDE Equivalent
Windows: Optimization > Parallelization
Здравствуйте, Sinclair, Вы писали:
S>Mkizub считает, что это очень плохо — MSIL, как промежуточный уровень, не даёт C# компилятору доступа к SSE. Я считаю, что это бред — потому, что у JIT компилятора есть вся та же информация, что у C#, плюс еще и информация о целевой архитектуре. Поэтому он примет более правильное решение. Как раз благодаря тому, что MSIL такой весь бедный и невыразительный.
А ты уверен, что для корректного использования SSE будет достаточно поручить компилятору сделать такой выбор ? Информация у него есть, да, но все же MSIL как он есть сейчас не то чтобы очень SIMD ориентирован (или я не прав ?). Для успешного использования SSE , возможно, придется не полагаться на компилятор, а построить саму программу так, чтобы она делала за раз по 4 сложения, к примеру
for(i = 0; i < N; i++)
сложить a[i] и b[i]
for (i = 0, i < N; i+=4) // да еще и N должен быть кратен 4, иначе дел натворим
{
загрузить a[i].. a[i+3] в А
загрузить b[i].. b[i+3] в Б
сложить А и Б // А и Б — XMM регистры
}
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Кстати, у Intel C++ есть
PD>parallel, Qparallel PD>Tells the auto-parallelizer to generate multithreaded code for loops that can be safely executed in parallel.
PD>IDE Equivalent PD>Windows: Optimization > Parallelization
PD>но я все же предпочту эти вещи делать сам
Он часто делает лучше чем вручную, но также может и протупить, в общем под него нужно подстраиватся, но и отдача очень хорошая.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Трактуй как хочешь. Результатом является линейный массив, а как он получается — не суть важно.
Это заблуждение. Массивов в SQL вообще нет — потому что в нём нет операции взятия элемента по индексу. Да и вообще порядок элементов не определён, пока его не задашь при помощи order by.
По-видимому, некорректное восприятие и приводит к никорректным выводам про "понижение размерности".
S>>Я не передергиваю. Я говорю про уровни абстракции. Процессор предлагает удобный уровень абстракции по работе с числами. S>>Библиотека по работе с длинными числами — тоже. Тебе, как клиенту библиотеки, всё равно, как она там внутри работает — софтно или аппаратно.
PD>Обсуждать не буду, как не имеющее к делу отношения.
PD>Тогда исправь и верни мне это окно. Только учти, что ROW и COLUMN — это не поля таблицы, а таблица БД должна содержать произвольно варьируемое сисло этих COLUMN.
Павел, ты опять подменяешь задачу неким решением. Зачем "таблица БД должна их содержать"?
Никому она ничего не должна. Более того, как мы уже выяснили, даже та часть запроса, которая про "строки с 0 по 10" — некорректна. Потому что в SQL у строк нет номеров. Как только ты превратишь ROW и СOLUMN в части составного ключа, как и подразумевает реляционная алгебра, задача сразу получит решение на SQL.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Трактуй как хочешь. Результатом является линейный массив, а как он получается — не суть важно. S>Это заблуждение. Массивов в SQL вообще нет — потому что в нём нет операции взятия элемента по индексу. Да и вообще порядок элементов не определён, пока его не задашь при помощи order by.
Это все не имеет никакого отношения к тому , о чем я начал говорить. Не нравится слово массив — замени на что-то иное (коллекция,набор к примеру). Важно лишь одно — мы получаем в результате некий линейный набор из однородных элементов и с ним работаем как со скаляром, не перечисляя его элементы в цикле явно. Остальное несущественно.
PD>>Тогда исправь и верни мне это окно. Только учти, что ROW и COLUMN — это не поля таблицы, а таблица БД должна содержать произвольно варьируемое сисло этих COLUMN. S>Павел, ты опять подменяешь задачу неким решением. Зачем "таблица БД должна их содержать"? S>Никому она ничего не должна. Более того, как мы уже выяснили, даже та часть запроса, которая про "строки с 0 по 10" — некорректна. Потому что в SQL у строк нет номеров. Как только ты превратишь ROW и СOLUMN в части составного ключа, как и подразумевает реляционная алгебра, задача сразу получит решение на SQL.
Все, закроем эту часть. Ты просил показать понижение на 2 — я тебе показал, что я имею в виду под этим. Обсуждения того, где row и кто ключ — не будет.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>А ты уверен, что для корректного использования SSE будет достаточно поручить компилятору сделать такой выбор ?
Конечно уверен. PD>Информация у него есть, да, но все же MSIL как он есть сейчас не то чтобы очень SIMD ориентирован (или я не прав ?).
По крайней мере, он не менее SIMD-ориентирован, чем С#. Это мы уже выясняли в топике про оптимизации "на уровне исходного кода". PD>Для успешного использования SSE , возможно, придется не полагаться на компилятор, а построить саму программу так, чтобы она делала за раз по 4 сложения, к примеру
PD>for(i = 0; i < N; i++) PD> сложить a[i] и b[i]
PD>for (i = 0, i < N; i+=4) // да еще и N должен быть кратен 4, иначе дел натворим PD>{ PD> загрузить a[i].. a[i+3] в А PD> загрузить b[i].. b[i+3] в Б PD> сложить А и Б // А и Б — XMM регистры PD>}
То есть ты думаешь, что вот это всё должен делать человек?
Я вот думаю, что это должен делать компилятор, при помощи двух эвристик:
1. Развертка цикла.
2. Объединение нескольких сложений, идущих подряд, в одну SSE-инструкцию.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
remark,
R>Для меня язык не сильно принципиален, и будет 3 строчек кода или 7 тоже не особо интересует. Мне кажется, более важны более высокие и общие вещи — например, построение архитектуры на передачи неизменяемых объектов. И в чём тут проблемы у НЕ ФЯ я так и не понял.
Уж сколько раз твердили миру, что "Surely the most powerful stroke for software productivity, reliability, and simplicity has been the progressive use of high-level languages for programming" (один грамотный дядька).
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>for(i = 0; i < N; i++) PD> сложить a[i] и b[i]
Да вообще-то компиляторы и так умеют такие циклы векторизовать. Делается очень просто, сначала N/4 итераций по 4 сложения, потом остаток складываем как обычно.
Здравствуйте, Mr.Cat, Вы писали:
MC>Здравствуйте, remark, Вы писали: MC>>>Писали когда-то (ну и сейчас еще по инерции), на PL/SQL, например, с использованием всяческих вещей, типа Oracle Forms, Oracle APEX и т.п. И продолжали бы, если бы Oracle не забросил эти технологии и не переключился на Java. R>>Какое это имеет отношение к SQL? на Erlang тоже можно С-либу подгрузить и работать с разделяемой памятью.
MC>Прямое. Вы когда-нибудь работали с Oracle Forms, например? Полагаю, что нет, т.к. аналогия с erlang+C совершенно неуместна.
MC>Oracle Forms — это рантайм PL/SQL (чтобы запускать код на клиентской машине или сервере приложений — т.е. вне СУБД) плюс GUI (оконный или web), позволяющий работать с ним из PL/SQL (в частности, отображать результаты выборки из БД).
Как человек работающий с Oracle (и Forms в частности) со всей отвественностью заявляю:
PL/SQL никакого отношения к SQL не имеет
Но к слову надо заметить, что с введением MODEL SQL стал очень даже императивным
Надеюсь все-же что Mr.Cat на придет в голову писать на SQL что нибудь вроде биллинга
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>SELECT * FROM table WHERE cond // Где тут цикл, куда он пропал ? PD>for(int i = 0; i < table.size; i++) PD> if(table[i].cond) PD> result.Add(table[i];
PD>Конечно, SQL сервер отнюдь не обязательно устроит линейный просмотр , но идея от этого не изменится.
Изменится. Например для Join оптимизатор может выбрать по обстоятельствам Hash Join или Nested Loop
а программисту цикл придется очень нетривиально переписывать
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, D. Mon, Вы писали: DM>>Исправил компилятор? IT>Мозги.
Любопытно все таки взглянуть на то чем вы там мозги исправляли . А то похоже предмет дискуссии не понятен всем остальным.
Бросьте хоть что нибудь links, keywords, references.
зы1
Вводные в multi-staged, и тп я видел, но живых примеров маловато.
зы2
си он жеж не от хорошей жизни берется. вот пример задачки имеем 12GB с прямоугольниками и надо посчитать чтобы в кучках по n расстояния между ними были одни а иначе другие. Ну еще существующие программисты имеют определенный опыт и он к сожалению на си.
Здравствуйте, VoidEx, Вы писали:
VE>Здравствуйте, IT, Вы писали:
R>>>Кажется кто-то тут недавно говорил о том, что кривыми по определению инструментами можно сделать только кусок дерьма... возможно я что-то упускаю, но из твоих слов получается что большинство функциональных языков, языков основанных на сборке мусора и т.д. — кусок дерьма в квадрате.
IT>>Совершенно верно. Кривым инструментов можно сделать только кривое решение. Но потом можно его бесконечно выпрямлять, тратя на это тысячи человеко-лет.
VE>Ничего не понял. Так можно из дерьма конфетку слепить, получается? Или таки только дерьмо получится? Вы уж как-нибудь определитесь.
Ну а как же хваленый бутстрапинг ?
1. Быстрненько написали простенький Pascal на стареньком железе
2. Написали на простеньком Pascal-е компилятор Pascal по умнее (так несколько итераций)
...
N. Написали на умненьком Pascal-е кросс-компилятор и переползли на другое железо
Здравствуйте, thesz, Вы писали:
T>Актёр обязательно содержит состояние внутри. А это плохо. Лучше всего параллелятся вычисления без состояния, когда состояние разбивается на много маленьких кусочков и протаскивается только в нужные места.
Только есть один любопытный казус. Бесконечно рекурсивная функция в дизайне на стримах (ленивых потоках), который ты любишь применять в своих программах, также содержит состояние внутри, как актер . Что характерно — и то и другое одинаково хорошо параллелится, не смотря на то, что формально твой дизайн на стримах функционально чист, а актеры нет. Это плохо?
Здравствуйте, thesz, Вы писали:
M>>В таких условиях будет лучше работать что-то вроде erlang-а, но именно в силу его ориентированности на приём сообщения (данных), простую обработку, посылку сообщения дальше. То есть модель "актёров". Что действительно никакого отношения к FP не имеет.
T>Актёр обязательно содержит состояние внутри. А это плохо. Лучше всего параллелятся вычисления без состояния, когда состояние разбивается на много маленьких кусочков и протаскивается только в нужные места.
Модель акрётов не подразумевает распараллеливания кода на уровне отдельных актёров, она распараллеливает код за счёт параллельного выполнения различных актёров, поэтому наличие состояния тут не релевантно. Если требуется распараллеливание кода отдельного актёра, то можно применить, например, OpenMP для распараллеливания — это будет совершенно перпендикулярно агентной модели. Либо использовать иммутабельное состояние актёров как в Эрланге.
Здравствуйте, AndrewVK, Вы писали:
AVK>http://en.wikipedia.org/wiki/FPGA
AVK>Вот только, как человек, который с ними лет 10 назад возился всерьез, могу заверить, что использовать сие без сложнейшего компилятора в хардвару (который сам по себе челендж на порядок покруче оптимизирующих компиляторов для VLIW, с чем, как показала практика, так особо и не справились пока) невозможно. Рассчитывать на то, что прикладной программист или даже разработчик компилятора ЯВУ будет этим заниматься сам — безумие.
Видишь в чём дело, я говорил о некоей абстрактной адаптируемости, а ты её перевёл в привычный тебе термин FPGA, и на этом построил свои дальнейшие рассуждения.
Я не имел в виду конкретно FPGA. Вообще-то я имел в виду другие вещи, скажем, человеческий мозг.
Ты, когда учишься играть в баскетбол и бросать мяч в корзину — много задумываешься о том, что в процессе тренировок твой мозг выстраивает некий аналоговый компьютер, который получает и передаёт сигналы от мышц, глаз, учитывает текущую биохимию организма и прочее, для достижения единственной цели — максимально увеличить процент попадания мяча в корзину.
Я не знаю, как будет работать подобная технология для кремния (и для кремния-ли), но это в принципе достижимо. Я не знаю, будет новая конфигурация процессора загружаться в него в течении микросекунд, или она будет в нём возникать годами. Не в этом суть. А суть в том, что адаптивность процессоров возможна. И пример из биологической жизни (адаптируемость нервной системы животных, а не жестко зашитая программа, как у насекомых) показывает, что возможны и успешны оба варианта (и они не так уж взаимо-противоречивы, можно иметь частично жесткую программу/CPU, и частично адаптивную, или иметь вначале жёсткую, которая может постепенно заменятся адаптивной и т.п.), но адаптивный вариант в далёкой перспективе более выгоден (хотя и стоит дороже на начальном этапе).
FPGA — это самое начало адаптивности, что-то вроде ламповых компьютеров. Представление о том, что так же и будет в дальнейшем — безумие. Это как рассуждать о невозможности настольных компьютеров, на основании больших размеров ламповых транзисторов.
Здравствуйте, Sinclair, Вы писали:
S>Mkizub считает, что это очень плохо — MSIL, как промежуточный уровень, не даёт C# компилятору доступа к SSE. Я считаю, что это бред — потому, что у JIT компилятора есть вся та же информация, что у C#, плюс еще и информация о целевой архитектуре. Поэтому он примет более правильное решение. Как раз благодаря тому, что MSIL такой весь бедный и невыразительный.
Нет уж, считать что у JIT компилятора есть вся та-же информация, что и C# — вот это и есть бред. И ещё больший бред, считать что у C# компилятора есть вся та-же информация, что и у программиста, который писал код.
Ты хочешь доказательств, но как их тебе дать, если ты не имеешь соответствующей информации, соответствующего опыта? То, что я написал строкой выше — это очевидно специалисту. Это вытекает из всей его практики, у него есть масса примеров. А у тебя их нет, как же тебе можно что-то доказать?
Вот я тебе простой пример привожу. Раньше в javac (явовском компиляторе) был ключик -O (оптимизация), который оптимизировал байткод. С точки зрения его размера, уменьшения количества операций, убирал ненужные локальные переменные и пр. А теперь этот ключик убрали (то есть оставили, но только для обратной совместимости, он ничего не делает). По той простой причине, что JIT компилятор не может настолько же хорошо оптимизировать "оптимизированный" байткод, насколько он может оптимизировать "прямую" трансляцию из Java исходников в байткод. Хотя алгоритмически, функционально — они одинаковы. А всё равно не может, а если и сможет — это сделает его анализ кода намного более сложным и медленным.
Вот тебе ещё один пример. В яве сделали ковариантные методы (по возвращаемому результату) — String foo() overrides Object foo(). Но это сделали в языке, а JVM не меняли. Просто генерится код class Base {
Object foo() {}
}
class Ext extends Base {
String foo() {}
bridge Object foo() { return foo(); } // return foo()->String
}
И в байткоде сделали специальный модификатор bridge для таких методов. Что позволяет JVM понять, что это не настоящий метод, а специальный мостик к настоящему, и убрать вызов этого мостика при компиляции, а вызвать реальный метод напрямую. А без этого модификатора у JVM и JIT нет никаких гарантий, что этот мостик можно выкинуть, эта информация была-бы потеряна при переходе от java source code к java bytecode.
Это самые простые примеры. В реальной жизни их уйма, и они не так просты. И с ними компиляторо-писатель сталкивается постоянно. Для него это очевидно, а то, что ты написал — очевидный бред.
Здравствуйте, Sinclair, Вы писали:
S>Я в курсе. Насколько мне известно, перформанс у FPGA всё же не тот, что у мейнстрима.
Перформанс там не главная пролема. Главная — офигенный оверхед по транзисторам.
S>Поэтому использование их "для оптимизации" мне показалось несколько бесполезным.
Вот это ты зря.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>
Здравствуйте, mkizub, Вы писали:
M>Видишь в чём дело, я говорил о некоей абстрактной адаптируемости, а ты её перевёл в привычный тебе термин FPGA, и на этом построил свои дальнейшие рассуждения.
Ну что ж поделаешь, ты же уже сказал, что я не в состоянии твои идеи понять.
M>Я не имел в виду конкретно FPGA. Вообще-то я имел в виду другие вещи, скажем, человеческий мозг.
И кто сказал, что количество транзисторов потраченное на все эти конвееры и предсказания я не мог бы лучше использовать? Вместо одного ядра я бы сделал 16 специализированных под решение моего типа задач, из того же числа транзисторов. И оно бы летало намного быстрее. Если я могу распараллелить свою задачу. И наоборот, если не могу — то лучше сделать один сверх-умный проц, а не 16 тупых.
Это, оказывается, было про человеческий мозг? Занятно.
M>Я не знаю, как будет работать подобная технология для кремния (и для кремния-ли), но это в принципе достижимо.
И чем тебе FPGA не нравится?
M> Я не знаю, будет новая конфигурация процессора загружаться в него в течении микросекунд
FPGA на основе SRAM обеспечивают очень быструю загрузку.
M> А суть в том, что адаптивность процессоров возможна.
Возможна. Только не на уровне прикладного программирования и даже не на уровне разработчиков компиляторов.
M> И пример из биологической жизни (адаптируемость нервной системы животных, а не жестко зашитая программа, как у насекомых) показывает, что возможны и успешны оба варианта
Не, этот пример показывает, что доказательство по аналогии является формой демагогии.
M>FPGA — это самое начало адаптивности, что-то вроде ламповых компьютеров.
Вопрос тот же — чем конкретно оно тебя не устраивает?
... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>
Здравствуйте, WFrag, Вы писали:
PD>>for(i = 0; i < N; i++) PD>> сложить a[i] и b[i]
WF>Да вообще-то компиляторы и так умеют такие циклы векторизовать. Делается очень просто, сначала N/4 итераций по 4 сложения, потом остаток складываем как обычно.
WF>Специально проверил на GCC — векторизует.
А откуда он знает, что надо по 4 разворачивать?
Наверное, потому, что практически все нынешние x86 CPU имеют SIMD, и народ не поленился и для x86 написал специальную оптимизацию, в которой учёл всю специфику (например, что это сложение/умножение, и что можно по 4 операнда, а не по 16 и так далее).
Для массового процессора такую оптимизацию тебе сделали. А что будет, когда начнётся эра узкоспециализованных и адаптируемых процессоров? Помнишь как это было, когда SSE только появился? Никаких оптимизаций GCC тогда ещё не делал. Прошли годы, прежде чем он научился их делать, и то, толко потому, что это действительно массовый проц. Так же, как сейчас проходят годы, пока в язык программирования не введут новые понятия (вроде как в яву enum вводили), и те вводят только для массово используемых понятий.
А для конкретного проекта это можно сделать не за годы, а за считанные дни. Ввести в язык понятие "векторное сложение" и использовать его. Модицикации компилятора минимальны — если процессор поддерживает такое сложение — использовать SIMD инструкцию, не поддерживает — использовать вызов библиотечного метода. И твоё приложение будет летать в 4 раза быстрее, если векторные операции для него — критичная по скорости операция.
Здравствуйте, AndrewVK, Вы писали:
M>>Видишь в чём дело, я говорил о некоей абстрактной адаптируемости, а ты её перевёл в привычный тебе термин FPGA, и на этом построил свои дальнейшие рассуждения.
AVK>Ну что ж поделаешь, ты же уже сказал, что я не в состоянии твои идеи понять.
Вот именно поэтому и не можешь.
AVK>Это, оказывается, было про человеческий мозг? Занятно.
Попробуй перейти на другой уровень абстракции. Попробуй прочитать мои слова как расказ о принципах, а не конкретно FPGA, конкретно мозге и пр.
AVK>И чем тебе FPGA не нравится?
Почему не нравится? Я о нём кроме общих слов ничего не знаю. Как он может мне нравится или не нравится?
Здравствуйте, mkizub, Вы писали:
M>Вот я тебе простой пример привожу. Раньше в javac (явовском компиляторе) был ключик -O (оптимизация), который оптимизировал байткод. С точки зрения его размера, уменьшения количества операций, убирал ненужные локальные переменные и пр. А теперь этот ключик убрали (то есть оставили, но только для обратной совместимости, он ничего не делает). По той простой причине, что JIT компилятор не может настолько же хорошо оптимизировать "оптимизированный" байткод, насколько он может оптимизировать "прямую" трансляцию из Java исходников в байткод. Хотя алгоритмически, функционально — они одинаковы. А всё равно не может, а если и сможет — это сделает его анализ кода намного более сложным и медленным.
Непонятно, почему уменьшенный код оптимизировать сложнее чем тот же самый код с мусором (ненужные локальные переменные и т.д.).
Ты абсолютно точно уверен, что этот ключик убрали не потому, что он оказался ненужным, ибо JIT все равно соптимизирует гораздо лучше и нет смысла проводить двойную работу (двойная работа имеется в виду разработчикам Жавы — оптимизация в JIT->native и в java->JIT)?
Здравствуйте, AndrewVK, Вы писали:
S>>Я в курсе. Насколько мне известно, перформанс у FPGA всё же не тот, что у мейнстрима.
AVK>Перформанс там не главная пролема. Главная — офигенный оверхед по транзисторам.
Какой, кстати?
Вот если сравнить с нынешними x86 процессорами? Я так понимаю, что x86 процессоры имеют приблизительно 10-кратный запас, на случай "а вдруг удастся параллельно сделать последовательные вычисления", включая логику для "а вдруг", разруливание ситуаций "не повезло", несколько одинаковых блоков для скалярных вычислений, отдельные блоки для SIMD операций и пр.
PD>>Конечно, SQL сервер отнюдь не обязательно устроит линейный просмотр , но идея от этого не изменится.
G_K>Изменится. Например для Join оптимизатор может выбрать по обстоятельствам Hash Join или Nested Loop G_K>а программисту цикл придется очень нетривиально переписывать
Еще раз — понижение размерности есть оперирование с массивами (списками, коллекциями, наборами — как хочешь назови) — как со скалярами. А циклы при этом могут быть хоть одинарные, хоть двойные, хоть больше. Возведение элементов массива в квадрат — линейный цикл, пузырек — двойной, а массив все равно линейный.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Pavel Dvorkin, Вы писали:
S>По крайней мере, он не менее SIMD-ориентирован, чем С#. Это мы уже выясняли в топике про оптимизации "на уровне исходного кода".
0 >= 0 ? Не менее, верно.
Я IL плохо знаю, но что-то не помню, чтобы там были инструкции в стиле SIMD. ИМХО все же просто компилятор должен бы некие IL-SIMD инструкции генерировать (т.е в IL должны быть команды SIMD типа). А сейчас JIT их создавать будет на базе тех инструкций, которые там есть ? Что-то мне идея "наоборот" кажется совсем странной.
S>То есть ты думаешь, что вот это всё должен делать человек? S>Я вот думаю, что это должен делать компилятор, при помощи двух эвристик: S>1. Развертка цикла. S>2. Объединение нескольких сложений, идущих подряд, в одну SSE-инструкцию.
Хм. Дело в том, что тут не всегда четыре сложения, идущие подряд, есть. Это лишь простейший случай. Их просто может и не быть явно. Чтобы они появились, надо код переписать, сделать так, чтобы они появились. Алгоритм несколько поменять. А вот когда они будут, тогда либо вручную, либо компилятор, может,и сумеет.
Здравствуйте, mkizub, Вы писали:
AVK>>Это, оказывается, было про человеческий мозг? Занятно. M>Попробуй перейти на другой уровень абстракции. Попробуй прочитать мои слова как расказ о принципах, а не конкретно FPGA, конкретно мозге и пр.
А если перейти на другой уровень абстракции, то получится, что твои рассуждения об адаптации мозга полностью соответствуют работе Hotspota для джавовского оптимизатора в рантайме — программа, забрасывающая байты в сокет с каждой оптимизацией забрасывает их все быстрее и точнее.
При этом она не перестраивает процессор, так же как мозг не перестраивает свою ДНК.
А уж идет перестроение весов соединений нейронов в мозге или последовательности байт в оптимизированном коде программы — детали, несущественные на данном уровне абстракции
P.S. Доказательство по аналогии вообще не канает, а иллюстрация по аналогии требует очень аккуратного подбора этой аналогии, и то не факт, что поймут правильно.
Я, кстати, так и не смог толком понять, чего же тебе хочется получить. Чтобы при написании программы сразу создавался и идеальный процессор для нее? Пожалуй, это даже возможно реализовать, только очень (очень-очень-очень!) сомнительно, что это будет экономически выгодно.
Здравствуйте, fmiracle, Вы писали:
F>Непонятно, почему уменьшенный код оптимизировать сложнее чем тот же самый код с мусором (ненужные локальные переменные и т.д.). F>Ты абсолютно точно уверен, что этот ключик убрали не потому, что он оказался ненужным, ибо JIT все равно соптимизирует гораздо лучше и нет смысла проводить двойную работу (двойная работа имеется в виду разработчикам Жавы — оптимизация в JIT->native и в java->JIT)?
Не, не уверен. Напутал. Поиск по интернету мне освежил память: -O инлайнил private/final методы, и не все, а те, у которых небыло локальных переменных. Убрали, видимо, потому, что JIT всё равно инлайнит лучше.
По видимому, это у меня проассоциировалось с другими историеями. Sun в HotSpot сделал "маленькую оптимизацию" — они анализировали байткод, и когда встречалась определённая последовательность комманд — заменяли её на руками оптимизированный нэйтивный код. Эти последовательности были из известного явовского бенчмарка, на котором новая версия HotSpot (за счёт этих хаков) порвала в клочья конкуретнов (IBM, Semantic). Стали копать, и переписали этот бенчмарк, чтоб он делал то-же самое, но чуть-чуть другой последовательностью комманд. И Sun-овский HotSpot слил. Скандал был дюже громкий.
Вторая — это потеря производительности после "хорошей обфукации". В силу того, что основная техника у JITа — по последовательности байт определить какой именно был java source code и для стандартных паттернов генерить стандартный нэйтивный код — это используется во всю. Прежде всего, потому, что так компилировать можно очень быстро, и с приемлимым качеством. Если же компилировать как это делает AOT компилятор — то это очень долго, и делается уж для совсем часто вызываемых методов. А обфукация которая меняла эти паттерны — сбивала работу JITа для большинства методов.
Зависит от конкретного типа. Но не меньше чем на порядок. С этим борятся путем обвязки обычными микросхемами — памятью, контроллерами шин и т.п., хотя все это есть и в виде библиотек.
M>Вот если сравнить с нынешними x86 процессорами? Я так понимаю, что x86 процессоры имеют приблизительно 10-кратный запас
Это не тот оверхед. В FPGA все начинается на уровень ниже — там нет даже совсем простой логики — сумматоров, регистров. Все это формируется из стандартных вентилей.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>
Здравствуйте, mkizub, Вы писали:
AVK>>Ну что ж поделаешь, ты же уже сказал, что я не в состоянии твои идеи понять.
M>Вот именно поэтому и не можешь.
У меня свое мнение на этот счет. Ну да ты продолжай.
AVK>>Это, оказывается, было про человеческий мозг? Занятно.
M>Попробуй перейти на другой уровень абстракции.
Не, мужик, ты там говорил вполне конкретно о конкретных вещах.
AVK>>И чем тебе FPGA не нравится?
M>Почему не нравится?
Ты утверждаешь, что это не то. Вот и продемонстрируй, чего там не хватает.
M> Я о нём кроме общих слов ничего не знаю.
Откуда тогда такие далеко идущие выводы. На всякий случай, чтобы не было разговоров о высших абстракциях, я процитирую:
FPGA — это самое начало адаптивности, что-то вроде ламповых компьютеров.
Вот и поясни, какими будут транзисторные компьютеры.
M> Как он может мне нравится или не нравится?
Это ты себе вопрос задай.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>
Здравствуйте, Pavel Dvorkin, Вы писали: PD>0 >= 0 ? Не менее, верно.
Совершенно точно
PD>Я IL плохо знаю, но что-то не помню, чтобы там были инструкции в стиле SIMD. ИМХО все же просто компилятор должен бы некие IL-SIMD инструкции генерировать (т.е в IL должны быть команды SIMD типа).
Нет, это плохая идея. PD>А сейчас JIT их создавать будет на базе тех инструкций, которые там есть ? Что-то мне идея "наоборот" кажется совсем странной.
Конечно. Вон народ говорит по соседству, что плюсовый компайлер это и делает.
PD>Хм. Дело в том, что тут не всегда четыре сложения, идущие подряд, есть. Это лишь простейший случай. Их просто может и не быть явно. Чтобы они появились, надо код переписать, сделать так, чтобы они появились.
Нет.
Начнем сначала: ты привел пример кода, где сложения выполняются в цикле.
Да, такой код компилятору трудно векторизовать, но всё еще возможно.
Вот если ты постараешься испортить этот код, затуманить задачу — например, вручную распараллелив цикл и навтыкав туда volatile — тут да, точно, "алгоритм придется несколько поменять". Именно об этом я и говорю — отсутствие удачной абстракции ограничивает возможности компилятора PD> Алгоритм несколько поменять. А вот когда они будут, тогда либо вручную, либо компилятор, может,и сумеет.
Легче всего компилятору действовать тогда, когда он компилирует с языка, на котором твои действия записаны в максимально осмысленном виде. Вместо конкретного цикла, с конкретным битоперемешиванием мелконарезанных фрагментов, компилятор, к примеру, наблюдает операцию типа a = b + c, где все компоненты — это, скажем, вектора. Семантика операции + компилятору полностью известна, в том числе коммутативность, а также отсутствие побочных эффектов. Благодаря этому он волен сам выбирать, при помощи чего складывать компоненты, паралелить это или нет, и пользоваться ли MMX/SSE или штатным скалярным execution unit.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, fmiracle, Вы писали:
F>А если перейти на другой уровень абстракции, то получится, что твои рассуждения об адаптации мозга полностью соответствуют работе Hotspota для джавовского оптимизатора в рантайме — программа, забрасывающая байты в сокет с каждой оптимизацией забрасывает их все быстрее и точнее.
Совершенно верно.
F>При этом она не перестраивает процессор, так же как мозг не перестраивает свою ДНК.
А потому, что не имеет такой возможности. В этом вся суть — JIT работает только на своём уровне абстракции — конвертирует фиксированный байткод в фиксированный нэйтивный код. Он не имеет доступа к дизайну (архитектуре) приложения, и не может менять набор нэйтивных инструкций.
Скажем, если бы он мог добавить нэйтивную инструкцию для проверки выхода индекса за границы массива, то эта проверка была-бы "бесплатной" (на неё бы потратили энное количество тразисторов, но при выполнении явовского кода эта проверка была-бы бесплатной). Как ты думаешь, если бы JIT мог влиять на другие уровни абстракции (менять процессор) — эту комманду бы он добавил?
Вот пример работы JIT-а и архитектуры приложения. У меня обращение ко всем полям определённых классов обёрнуты в
Этот код генерируется автоматом. Для него гарантируется (самим генератором кода), что все касты в этом коде не нужны. И ещё я испольую текущий тред (группу тредов) как "контекст".
Сколько стоит "Thread.currentThread().getThreadGroup() == CompilerThreadGroup.$instance" ? С учётом того, что какой-то идиот влепил volatile для указателя на ThreadGroup в классе Thread. Плюс, я-бы просто сделал boolean переменную в классе Thread, и её проверял — так нельзя, секъюрити, мать её.
И эти касты. Ну да, они делаются быстро — за 3-4 операции процессора.
Только мне эти проверки контекста и касты надо делать при каждом обращении к полю этих классов.
JIT может доказать, что эти касты не нужны? Не может.
JIT может доказать, что "Thread.currentThread().getThreadGroup()" вернёт всегда одно и то-же значение для треда? Не может — там придурки volatile влепили (ура, в 7-й яве там уже final будет).
Если бы я мог "сообщить" JIT-у и JVM-у всю эту информацию имеющуюся в дизайне программы — она бы заработала раза в 2 быстрее, как минимум.
F>Я, кстати, так и не смог толком понять, чего же тебе хочется получить. Чтобы при написании программы сразу создавался и идеальный процессор для нее? Пожалуй, это даже возможно реализовать, только очень (очень-очень-очень!) сомнительно, что это будет экономически выгодно.
Не, идеальный процессор — это зачастую расточительство, поскольку предполагается, что этот процессор будут пользовать и для других задач. Для некоторых задач так и делают — скажем, сделали GPU для 3D графики. Но это только для массового продукта.
Вот адаптируемый процессор — это уже ближе. Если продолжить аналогию с GPU, то их уже сделали достаточно адаптируемыми, чтоб можно было на них и математику считать. Или пример с CELL, где есть generic CPU, и куча мелких, простых, но очень быстрых процессоров — на которых можно считать и физику, и графику. И те-же FPGA, которые конфигурируются достаточно гибко. Или процессор от Transmeta, который генерил свой нэйтивный код софтом.
Процессоры в своём развитии двигаются в сторону баланса между специализированностью и адаптируемостью. И чем дальше — тем больше в них будет адаптивности.
А как получить к ней доступ из программы, если между архитектурой программы и железом уже лежат неадаптируемые (неизменные) язык программирования и байткод?
Вот ещё один слой абстракции образуется сейчас — программы уже пишутся с учётом конкретного фреймворка, а не просто на каком-то языке программирования. Ещё и фреймворки положать между архитекторой и железом.
Проблема не в том, что они там лежат, а в том, что они неизменные, неадаптируемые под конкретную задачу.
Здравствуйте, AndrewVK, Вы писали:
M>>Попробуй перейти на другой уровень абстракции.
AVK>Не, мужик, ты там говорил вполне конкретно о конкретных вещах.
Не, я пиши об адаптируемости, и привёл мозг как пример возможности "автоматической" адаптации.
А ты пропускаешь слова обозначающие уровень абстракции на котором я разговариваю, и считаешь, что я пишу о конкретно мозге, конкретно FPGA и так далее.
AVK>Откуда тогда такие далеко идущие выводы. На всякий случай, чтобы не было разговоров о высших абстракциях, я процитирую: AVK>
FPGA — это самое начало адаптивности, что-то вроде ламповых компьютеров.
AVK>Вот и поясни, какими будут транзисторные компьютеры.
Понятия не имею.
Я исхожу из того, что на нынешних FPGA развитие адаптивности процессоров не остановится.
Больше того, оно ещё практически не начиналось. Поэтому такое сравнение и употребил.
Почему я считаю, что оно ещё практически не начиналось?
Исходя из общих закономерностей развития сложных систем, и технологий в частности. Эти общие закономерности я на форуме уже излагал. В частности, микропроцессоры находятся сейчас на стадии "экспансии", взрывного роста количества. Что в частности ведёт к упрощению технологии (потому как надо делать больше и дешевле — чем больше количественно, тем успешнее). Но это один из самых начальных этапов, и к тому-же достаточно короткий (в масштабе жизненного цикла данной технологии). Потом, когда количественный рост останавливается (потому как больше некуда расти), начинается рост качества (единственный оставшийся аргумент в конкурентной борьбе). Что вначале приводит к взрывному росту сложности (и это быстро заканчивается), потом к появлению большого разнообразия узкоспециализированных решений, и в конечном итоге (очень неспешно) приводит к развитию и потом к доминированию адаптивности в технологии. То есть к увеличению эффективности за счёт умения приспосабливаться к конкретной ситуации.
Здравствуйте, Sinclair, Вы писали:
S>Легче всего компилятору действовать тогда, когда он компилирует с языка, на котором твои действия записаны в максимально осмысленном виде. Вместо конкретного цикла, с конкретным битоперемешиванием мелконарезанных фрагментов, компилятор, к примеру, наблюдает операцию типа a = b + c, где все компоненты — это, скажем, вектора. Семантика операции + компилятору полностью известна, в том числе коммутативность, а также отсутствие побочных эффектов.
Гы. Это она известна компилятору, если + используется для известных ему типов данных. То есть эти семантические понятия в компиляторе есть.
А если как в нынешних языках, просто перегружать + каким-то методом — то ничего компилятору не становится известным, никакой коммутативности и отсутствия побочных эффектов.
В этом и проблема промежуточного (неизменного, нерасширяемого, неадаптируемого) уровня абстракции. Информация о том, что я складываю вектора, и тем самым удовлетворяю неким дополнительным условиям (которые можно оптимизировать используя SIMD или ещё что-нибудь) — теряется. Её можно, в лучшем случае, попытаться восстановить. А это дополнительная (и часто нетривиальная) логика, усложение компилятора (и без того чрезвычайно сложного), баги или невозможность оптимизировать если доказать не удалось (а доказать чаще всего не получится если не использовать глобальный анализ, а глобальный анализ возможен только для статически компилируемого кода, без всяких плагинов и динамической подгрузки кода и т.п.).
И весь этот бардак решается простым способом — я добавляю в язык новые семантические понятия (вроде арифметики векторов). Если компилятор не понимает этих понятий — компилирует (например) в библиотечные вызовы. Если понимает — прямо компилирует в SIMD инструкции. Быстро, просто, и с гарантированным результатом.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, Gluk_Kazan, Вы писали:
PD>>>Конечно, SQL сервер отнюдь не обязательно устроит линейный просмотр , но идея от этого не изменится.
G_K>>Изменится. Например для Join оптимизатор может выбрать по обстоятельствам Hash Join или Nested Loop G_K>>а программисту цикл придется очень нетривиально переписывать
PD>Еще раз — понижение размерности есть оперирование с массивами (списками, коллекциями, наборами — как хочешь назови) — как со скалярами. А циклы при этом могут быть хоть одинарные, хоть двойные, хоть больше. Возведение элементов массива в квадрат — линейный цикл, пузырек — двойной, а массив все равно линейный.
Он сразу становится менее линейный если рассмотреть чуть более сложные задачи, НЕ МАССИВ это, а набор кортежей (не упорядоченный, не индексированный)
SQL предоставляет абстракции реализация которых может различаться в зависимости от фаз луны.
Здравствуйте, remark, Вы писали:
R>Отсутствие разделяемого состояния = легкое распараллеливание = 100% загрузка всех ядер != линейная масштабируемость скорости работы приложения R>Отсутствие разделяемого состояния = легкое распараллеливание = 100% загрузка всех ядер возможно= деградация скорости работы приложения
R>Если как конечную цель ставить 100%-ную загрузку всех ядер (кодом, который как-то связан с кодом приложения), то Да, всё легко. Если как конечную цель ставить близкую к линейной масштабируемость скорости работы приложения — то, увы, Нет, всё не так просто.
Это все равно что сказать, что имея транспортное средство (скажем автомобиль) не имеешь гарантии того, что сможешь добраться в некий удаленный пунк. Вот только не имея его вероятность того, что ты доберешься начинает стремиться к нулю.
Да, это так. Только это замечание не имеет прикладного смысла.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, thesz, Вы писали:
VD>>... Даже если вы возьметесь решать сложную вычислительную задача скажем на Хаскеле, то вы все равно будете вынуждены заниматься оптимизациями, а значит и иметь где-то изменяемое состояние.
T>Сразу видно, что человек много писал на Хаскеле и много занимался оптимизациями Хаскельных программ. T>Вот так взял, да и сказал своё веское слово.
Сам дурак.
VD>>А так все просто. Функциональный код = отсутствие разделяемого состояния. Отсутствие разделяемого состояния = легкое распараллеливание. T>Ха-ха. T>Чем отличаются ассоциативные операции от ассоциативных, похоже, ты не знаешь. T>Так вот, ассоциативные операции параллелятся: a+(b+(c+d))==(a+b)+(c+d). Если мы не можем переставить скобочки, то мы не можем распараллелить. T>Ассоциативных операций не так уж и много: сложение, умножение, минимум, максимум и некоторые (не все!) их комбинации.
Уважаемый. Если у ты собираешся обсуждать бредятину вроде распараллеливания подвыражений, то пожалуйста, не надо это делать в ответ на мое сообщение.
Я говорил о реалиях сегодняшнего времени. О распараллеливании относительно больших частей программы. Например, о распараллеливании типизации отдельных функций при компиляции программы.
VD>>В том же компиляторе основная работа — это типизация методов/функций (операторов в программах по определению во много раз больше чем скажем методов). Методов/функций в большой программе много и если у нас нет глобального вывода типов, то каждый метод можно типизироваться отдельно.
T>Это справедливо только для независимых друг от друга функций. Если они зависят друг от друга, то все, процесс становится последовательным.
Поведай мне неучу о зависимостях функций в условиях когда нет глобального вывода типов (см. выделенное жирным). Или ты просто прежде чем начал писать не удосужился прочесть и осознать фразу которую решил обсудить?
T>Статистики, опровергающей твои слова, у меня нет, но и у тебя нет статистики, подтверждающей твои.
Статистики у тебя нет. Доводов тоже. Так что ты сказать то хотел? Что твоя интуиция подсказывает тебе что я в чем-то не прав? Ну, так так и скажи, а не разливай воду по полу. За одно скажи с чем конкретно не согласен. А то твое выступление похоже на желание любой ценой втиснуть свои пять копеек.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, remark, Вы писали:
R>Замечательно. А я не сталкиваюсь с особыми проблемами при работе в императивном стиле. И мне тоже С++ компилятор помогает тем, что ничем не мешает.
R>
Просто ты крут, дружище!
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
G>Только есть один любопытный казус. Бесконечно рекурсивная функция в дизайне на стримах (ленивых потоках), который ты любишь применять в своих программах, также содержит состояние внутри, как актер . Что характерно — и то и другое одинаково хорошо параллелится, не смотря на то, что формально твой дизайн на стримах функционально чист, а актеры нет. Это плохо?
Ты будешь удивлён, узнав, насколько плохо оно параллелится.
Я проводил эксперимент в сентябре месяце. Быстро и эффективно распараллелить симуляцию не удалось. Ускорение на двух ядрах (не HyperThreading) было всего порядка 15-20%.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
T>>Актёр обязательно содержит состояние внутри. А это плохо. Лучше всего параллелятся вычисления без состояния, когда состояние разбивается на много маленьких кусочков и протаскивается только в нужные места.
R>Модель акрётов не подразумевает распараллеливания кода на уровне отдельных актёров, она распараллеливает код за счёт параллельного выполнения различных актёров, поэтому наличие состояния тут не релевантно.
Значит, не масштабируется. Либо класс задач с такими свойствами (много независимых актёров с изменяемым независимо состоянием) очень узкий.
R> Если требуется распараллеливание кода отдельного актёра, то можно применить, например, OpenMP для распараллеливания — это будет совершенно перпендикулярно агентной модели. Либо использовать иммутабельное состояние актёров как в Эрланге.
В Эрланге, значит, "иммутабельное состояние актёров". Пожалуй, я это запомню и буду цитировать к месту и не очень.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
G>>Только есть один любопытный казус. Бесконечно рекурсивная функция в дизайне на стримах (ленивых потоках), который ты любишь применять в своих программах, также содержит состояние внутри, как актер . Что характерно — и то и другое одинаково хорошо параллелится, не смотря на то, что формально твой дизайн на стримах функционально чист, а актеры нет. Это плохо?
T>Ты будешь удивлён, узнав, насколько плохо оно параллелится.
T>Я проводил эксперимент в сентябре месяце. Быстро и эффективно распараллелить симуляцию не удалось. Ускорение на двух ядрах (не HyperThreading) было всего порядка 15-20%.
Для некоторых типов симуляции достаточно сложно сделать хороший ран-тайм для агентно-оринтированного подхода. Основные челенджи — это увеличить гранулярность (если она мала), и сделать хорошую локальность.
Вот тут есть небольшая статейка по поводу реализации системы симуляции на основе близкого к агентно-ориентированному подходе. Результаты масштабируемости схожи — совсем крошечное ускорение, причём тестировали на 2-ух процессорной по 4-ядра машине, и с добавлением новых потоков — скорость увеличения производительности (производная по скорости) только уменьшается: http://www.yetisim.org/images/2/2a/YetiSimPaper-SCS2008.pdf
Здравствуйте, remark, Вы писали:
R>Здравствуйте, thesz, Вы писали:
G>>>Только есть один любопытный казус. Бесконечно рекурсивная функция в дизайне на стримах (ленивых потоках), который ты любишь применять в своих программах, также содержит состояние внутри, как актер . Что характерно — и то и другое одинаково хорошо параллелится, не смотря на то, что формально твой дизайн на стримах функционально чист, а актеры нет. Это плохо?
T>>Ты будешь удивлён, узнав, насколько плохо оно параллелится.
T>>Я проводил эксперимент в сентябре месяце. Быстро и эффективно распараллелить симуляцию не удалось. Ускорение на двух ядрах (не HyperThreading) было всего порядка 15-20%.
R>Для некоторых типов симуляции достаточно сложно сделать хороший ран-тайм для агентно-оринтированного подхода. Основные челенджи — это увеличить гранулярность (если она мала), и сделать хорошую локальность.
Забыл сказать — это скорее всего будет не быстро и не легко, но я думаю, что обе проблемы можно решить, и получить линейную масштабируесть, если пользовательская модель это позволяет.
Здравствуйте, mkizub, Вы писали:
AVK>>Не, мужик, ты там говорил вполне конкретно о конкретных вещах.
M>Не, я пиши об адаптируемости
Ясно, не верь глазам своим.
M>, и привёл мозг как пример возможности "автоматической" адаптации.
В приведенном мной абзаце (довольно обширном, замечу, с законченной мыслью) вообще нет слова мозг. Зато есть слова "транзистор", "конвеер", "процессор", "ядро".
M>А ты пропускаешь слова обозначающие уровень абстракции на котором я разговариваю, и считаешь, что я пишу о конкретно мозге
M>Понятия не имею.
Ясно. То есть выводы из пальца. Вопросов больше нет.
M>Я исхожу из того, что на нынешних FPGA развитие адаптивности процессоров не остановится.
И? Опять пустые слова? Ну наверное, если не случится ядерной войны, развитие не остановится. Довольно тривиальная мысль.
M>Больше того, оно ещё практически не начиналось.
Как ты можешь это утверждать, если не знаком с предметом? В свое время очень много народу занималось исследованиями реконфигурируемой логики, вплоть до конкретных решений даже в продакшн. Только это весьма специфичная область, и, если специально ей не интересоваться, то со стороны ничего не видно.
M>Исходя из общих закономерностей развития сложных систем, и технологий в частности.
По русски это называется "поплевав в потолок". Фактов нет, зато есть Истинная Теория.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>
Я умный. Только быстрый.
VD>>>А так все просто. Функциональный код = отсутствие разделяемого состояния. Отсутствие разделяемого состояния = легкое распараллеливание. T>>Ха-ха. T>>Чем отличаются ассоциативные операции от ассоциативных, похоже, ты не знаешь. T>>Так вот, ассоциативные операции параллелятся: a+(b+(c+d))==(a+b)+(c+d). Если мы не можем переставить скобочки, то мы не можем распараллелить. T>>Ассоциативных операций не так уж и много: сложение, умножение, минимум, максимум и некоторые (не все!) их комбинации. VD>Уважаемый. Если у ты собираешся обсуждать бредятину вроде распараллеливания подвыражений, то пожалуйста, не надо это делать в ответ на мое сообщение. VD>Я говорил о реалиях сегодняшнего времени. О распараллеливании относительно больших частей программы. Например, о распараллеливании типизации отдельных функций при компиляции программы.
(пардон, про коммутативность я забыл. точнее, я про неё помнил, но подумал, что она не важна. а она важна)
Ты не перескакивай между темами.
В параграфе выше у тебя нет ничего про "реалии сегодняшнего времени".
Поэтому давай, расскажи про "распараллеливание подвыражений" вроде последовательной обработки состояния.
Как ты будешь доказывать коммутативность (возможность изменения порядка) операций над состоянием, что необходимо для выявления параллелизма.
Насчёт вывода типов погорячился, согласен.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
T>>>Актёр обязательно содержит состояние внутри. А это плохо. Лучше всего параллелятся вычисления без состояния, когда состояние разбивается на много маленьких кусочков и протаскивается только в нужные места.
R>>Модель акрётов не подразумевает распараллеливания кода на уровне отдельных актёров, она распараллеливает код за счёт параллельного выполнения различных актёров, поэтому наличие состояния тут не релевантно.
T>Значит, не масштабируется. Либо класс задач с такими свойствами (много независимых актёров с изменяемым независимо состоянием) очень узкий.
Я не думаю, что он особо узкий. Большинство серверного ПО можно побить на множество актёров, воспользовавшись преимуществом отдельных соединений или запросов. Моделирование различных систем, описываемых графами. Даже в толстых клиентах можно 10-20 независимых актёров/подсистем выделить. Масштабироваться это будет замечательно. Особо много и не надо, достаточно сотен.
В любом случае непонятно смешивание модели актёров и факта, что они имеют состояние и внутренне не распараллеливаются. Это 2 абсолютно независимых вещи — можно параллелить на уровне актёров (отвлечёмся пока от факта, сколько актёров мы можем выделить в системе — параллелить на таком уровне мы всё равно можем), можно параллелить на уровне отдельных функций (пользуясь преимуществом неизменяемых данных), можно применить сразу оба метода.
R>> Если требуется распараллеливание кода отдельного актёра, то можно применить, например, OpenMP для распараллеливания — это будет совершенно перпендикулярно агентной модели. Либо использовать иммутабельное состояние актёров как в Эрланге.
T>В Эрланге, значит, "иммутабельное состояние актёров". Пожалуй, я это запомню и буду цитировать к месту и не очень.
Здравствуйте, Gluk_Kazan, Вы писали: G_K>PL/SQL никакого отношения к SQL не имеет
Напомню, что все началось с того, как remark провел параллель между sql и функциональными языками. Я посчитал, что (т.к. sql довольно узкоспецтализированный dsl) он имеет в виду какое-либо из императивных расширений (t-sql, pl/sql). Короче, думаю, далее спорить по этому поводу нет смысла.
Здравствуйте, remark, Вы писали:
R>Если требуется распараллеливание кода отдельного актёра, то можно ..., например ... использовать иммутабельное состояние актёров, как в Эрланге.
R>Это не я придумал: R>
MC>Эээ, а как иммутабельное состояние в данном случае помогает параллелить код актера?
Можно попробовать распараллелить Module:handle_call()/Module:handle_cast() — возможно они без побочных эффектов, одно состояние приняли, другое вернули.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, remark, Вы писали:
R>>Отсутствие разделяемого состояния = легкое распараллеливание = 100% загрузка всех ядер != линейная масштабируемость скорости работы приложения R>>Отсутствие разделяемого состояния = легкое распараллеливание = 100% загрузка всех ядер возможно= деградация скорости работы приложения
R>>Если как конечную цель ставить 100%-ную загрузку всех ядер (кодом, который как-то связан с кодом приложения), то Да, всё легко. Если как конечную цель ставить близкую к линейной масштабируемость скорости работы приложения — то, увы, Нет, всё не так просто.
VD>Это все равно что сказать, что имея транспортное средство (скажем автомобиль) не имеешь гарантии того, что сможешь добраться в некий удаленный пунк. Вот только не имея его вероятность того, что ты доберешься начинает стремиться к нулю.
Ты хочешь сказать, что присутствие разделяемого состояния устремляет вероятность распараллеливания к нулю? Я правильно понял аналогию?
VD>Да, это так. Только это замечание не имеет прикладного смысла.
Ты когда-нибудь занимался распараллеливанием на многоядерных/многопроцессорых/NUMA системах?
Не имеет прикладного смысла? Очень смешно. Честно. Формальное, даже ручное, распараллеливание программы (т.е. формальное достижение того, что система вроде как может иметь линейное масштабирование с высоты птичьего полёта) зачастую выливается как и в суб-линейную масштабируемость (что-то типа log(N)), так и в деградацию. НО. При этом все процессоры загружены на 100%. А уж как обходить это при автоматическом распараллеливании я совсем не представляю. Отсюда и:
Отсутствие разделяемого состояния = легкое распараллеливание = 100% загрузка всех ядер != линейная масштабируемость скорости работы приложения
Отсутствие разделяемого состояния = легкое распараллеливание = 100% загрузка всех ядер возможно= деградация скорости работы приложения
И это имеет решающее практическое значение. Иначе где вся эта магия?
Здравствуйте, remark, Вы писали: R>Можно попробовать распараллелить Module:handle_call()/Module:handle_cast() — возможно они без побочных эффектов, одно состояние приняли, другое вернули.
Так в данном конкретном коде они же не могут быть одновременно вызваны внутри одной "итерации" актера. Вот если б могли (видимо, вы этот случай имеете в виду?), тогда вопросов нет.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Pavel Dvorkin, Вы писали: PD>>В некотором смысле SQL — это понижение размерности задачи на 1. S>Не могу согласиться. Ты же дальше сам приводишь примеры про join и group — где там на 1? Там и на 10 может понизиться.
Причем тут 1 или 10? Это же банальная инкапсуляция. Товарищь Дворкин в очередной раз не разобравшись пытается агитировать за отказ от инкапсуляции и радостно замечает, что инкапсуляция бывает на разных уровнях. Только заметив это он не может это выразить связанно. Вот и получается у него "на 1".
Нет там ни на 1, ни на 10, ни на 0.5, ни на 1000. Там есть инкапсуляция конкетных действий. Инкапсуляция: фильтрации, соединения, сортировки, выборки, группировки списков. Что в сумме является инкапсуляцией работы со списками. Ежу понятно, что так как эта инкапсуляция работает со списком (в виде IEnumerable[] для реализации linq2object), то и эффективность получается соответствующая. Понятно что если все захардкодить для конкретных типов, то можно добиться лучшей производительности.
Вот что Дворкину не понятно, так это то, что "повышение на 2 или 5" — это просто инкапсуляция внутри прикладной задачи. В публичную библиотеку такой код не положишь, так как он относится к решаемой задаче. Но тем не менее инкапсулировать прикладную логику надо. Причем если она сама будет создана с использованием абстракции вроде LINQ-а (или просто ФП), то реализация будет проще. Ну, а опримизировать тоже иногда надо кое что. Только не все подряд и уж точно не на основании того, что "алгоритм более сложный" (с) Дворкин, а на основании того, что мы столкнулись с узким местом и есть пути написать это место алгоритмически более качественно (возможно в ущерб краткости).
Так что называйте вещи своими именами. Не размерность задачи, а ее инкапсуляция. Тогда и ошибок в логике не будет.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Mr.Cat, Вы писали:
MC>Здравствуйте, remark, Вы писали: R>>Можно попробовать распараллелить Module:handle_call()/Module:handle_cast() — возможно они без побочных эффектов, одно состояние приняли, другое вернули.
MC>Так в данном конкретном коде они же не могут быть одновременно вызваны внутри одной "итерации" актера. Вот если б могли (видимо, вы этот случай имеете в виду?), тогда вопросов нет.
Вызовется только одна — вот её и распараллелить. Внутри ж неё тоже вызовы функций есть, и не один. Внутри handle_call() будет handle_call_1() и handle_call_2(), внутри handle_call_1() будет handle_call_1_1() и handle_call_1_2().
Здравствуйте, Mr.Cat, Вы писали:
MC>Ааа, или Вы просто привели код, который Вы имели в виду под "иммутабельным состоянием актера"?... А я тут, блин, прикапываюсь...
Ну да. Я имею в виду, что вместе с агентной моделью (если она не даёт необходимого распараллеливания) можно применить любую другую технологию, и она будет совершенно перпендикулярна. Можно OpenMP; или может там чего автоматически распараллеливающий компилятор накопает (если код функциональный) (<--- вот этот случай я имел в виду под "иммутабельным состоянием актера", извиняюсь за такую формулировку), в конце концов можно внутри метода агента вручную запустить потоков и с песней в бой.
Здравствуйте, remark, Вы писали: R>Вызовется только одна — вот её и распараллелить. Внутри ж неё тоже вызовы функций есть, и не один. Внутри handle_call() будет handle_call_1() и handle_call_2(), внутри handle_call_1() будет handle_call_1_1() и handle_call_1_2().
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Еще раз — понижение размерности есть оперирование с массивами (списками, коллекциями, наборами — как хочешь назови) — как со скалярами. А циклы при этом могут быть хоть одинарные, хоть двойные, хоть больше. Возведение элементов массива в квадрат — линейный цикл, пузырек — двойной, а массив все равно линейный.
А тебе не приходила в голову мысль, что можно создать библиотеку аналогичную LINQ-у которая будет точно так же инкапсулировать работу с матрицами. Да еще и позволит задавать их абстрактно?
Кто тебе мешает создать свой вариант Where, Select и возможно еще неких других методов которые позволят тебе без циклов записывать суть твоих алгоритмов?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, SleepyDrago, Вы писали:
SD>си он жеж не от хорошей жизни берется. вот пример задачки имеем 12GB с прямоугольниками и надо посчитать чтобы в кучках по n расстояния между ними были одни а иначе другие. Ну еще существующие программисты имеют определенный опыт и он к сожалению на си.
Задачка то на С в лоб решается только наиболее медленным способом.
По жизни для такой задачки лучше подойдет, например, SQL-сервер в котором реализован пространый тип данных и индексирование по нему. Далее задача сводится к весьма простому запросу. Причем никакого С акромя, конечно, того что в драйверах, железе и возможно в СУБД лежит.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Из этой ситуации есть два выхода.
PD>1. Поменять компилятор. PD>2. Поменять того, кто с этим компилятором работает.
Есть третья — изучить что-то новое. Но для этого мозг должен быть гибким. Так что это не всем дается.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, fddima, Вы писали:
F> Я в своё время делал простенький рэйтресер. И мимолётом мне Mamut подсказал рэйтрэсер на эрланге (я к эрлангу очень хорошо отношусь, из всех ФЯ мне он наиболее симпатичен), так вот, рэйтресинг это не для эрланга. Умении масштабироваться — да, есть. Но тока я на C++ сделал то, шо бы реализация на эрланге потребовала ~20 процов. Просто не его конёк. И открытых косяков там не было.
Извини, но это берд, да и только. Строить выводы об ФП по одному вычислительному тесту реализованному на интерпретируемом языке.
Ну, для полноты картины тогда уж реализуй императивный тест на Руби или Питоне.
Ты свой рейтресер сравнивал с реализациями на ОКамле или компилируемом ЦЛиспе?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Что будет дальше — зависит от двух факторов. Первый — это как будет расти производительность компьютеров, а второй — какие задачи будут на повестке дня. Если быстродействие будет так же расти, как оно росло — неэффективные решения будут жить и процветать. Если задачи не будут требовать эффективного использования ресурсов — тоже. Если же рост производительности замедлится (это скорее всего), а задачи усложнятся (а вот это большой вопрос) — тогда все эти неэффективные решения полетят к той же бабушке, а на повестку дня выйдут опять-таки эффективные решения. Если все же надо летать, то надо из этого двигателя выжать 800 км/час, даже если пилоту будет намного сложнее работать, чем водителю Жигулей.
Дальше будет вот что. Рост производительности продолжится теми же темпами, но не за счет частоты процессоров (тут темп уже снизился), а за чет их количества.
На повестку дня при этом выйдет не написание самых оптимальных, но линейных (не параллельных), программ, а создание программ которые будут масимально эффективно использовать большое количество ядер. Учитывая, что рост вычислительных ресурсов подталкивает так же и к росту сложности задач (иначе зачем новый софт), разработка софта будет становиться все более сложным процессом. Эффективно распараллелить задачу средней сложности (по сегодняшним меркам) весьма не простое дело. Если задача уже написана без учета параоллелизма, то почти не подъемное. Более сложные же задачи которые будут ставятся в будущем вообще сделает ручное рпспараллеливание сродни ручкой оптимизации программ путем кодирования их на ассемблере, т.е. дорого и парктически не подъемно.
Отсюда в современных исследованиях прослеживается тенденция выработки технологических решений автоматизации распараллеливания выполнения. Фактически впервые вопрос стоит о рождении новой парадигмы методом "сверху".
Ну, и на этом фоне орлы вроде Дворкина громко и красиво поют старые песни о главном. Мол трава раньше была зеленее, а софт эффективнее.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Sinclair, Вы писали:
S>Вот подскажи мне, как эксперт по C++, какая там самая быстрая библиотека регулярных выражений? Используется ли там runtime-кодогенерация?
Хреновый надо сказать пример, если ты про дотнетгные регекспы. Это как раз пример того, что никакая рантайм-кодогенерация не может заменить качество алгоритмов.
Помнится у нас подсветка синтаксиса асма дико тормозила как раз в следствии того, что использовались регекспы.
Хотя по сути ты конечно прав.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Дальше будет вот что. Рост производительности продолжится теми же темпами, но не за счет частоты процессоров (тут темп уже снизился), а за чет их количества.
VD>На повестку дня при этом выйдет не написание самых оптимальных, но линейных (не параллельных), программ, а создание программ которые будут масимально эффективно использовать большое количество ядер. Учитывая, что рост вычислительных ресурсов подталкивает так же и к росту сложности задач (иначе зачем новый софт), разработка софта будет становиться все более сложным процессом. Эффективно распараллелить задачу средней сложности (по сегодняшним меркам) весьма не простое дело. Если задача уже написана без учета параоллелизма, то почти не подъемное. Более сложные же задачи которые будут ставятся в будущем вообще сделает ручное рпспараллеливание сродни ручкой оптимизации программ путем кодирования их на ассемблере, т.е. дорого и парктически не подъемно.
VD>Отсюда в современных исследованиях прослеживается тенденция выработки технологических решений автоматизации распараллеливания выполнения. Фактически впервые вопрос стоит о рождении новой парадигмы методом "сверху".
Да, всё правильно. Самые интеллектуальные из работающих сейчас и постоянно развивающихся средств поддержки таких парадигм, которые я знаю (средства), — есть библиотеки для С++ и Fortran.
А совсем ручным распараллеливанием уже давно никто без особого желания не занимается. Cilk — прародитель всех современных средств для параллельных вычислений — .NET TPL, Java Fork/Join, PPL (C++), TBB (C++), OpenMP (C/C++/Fortran) — доступен в С с 1994 года. И он уже тогда прекрасно работал с линейной маштабируемостью на 32-процессорных системах, и брал на себя всю рутинную работу.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Из этой ситуации есть два выхода.
PD>>1. Поменять компилятор. PD>>2. Поменять того, кто с этим компилятором работает.
VD>Есть третья — изучить что-то новое. Но для этого мозг должен быть гибким. Так что это не всем дается.
Гибким, но не жидким!
Здравствуйте, VladD2, Вы писали:
DC>>Подключить эту либу можно конечно и к жаве с додиезом, но таких возможностей как Хаскелл они не дадут.
VD>Э... не в Хаскеле едином есть поддержка ФП. Современный Шарп уже очень близок.
Да дело то не в ФП, а в возможности построения алгоритмов путём комбинирования набора примитивных операции, а тут у Хаскелла, ИМХО, абсолютное преимущество и система типов, и TemplateHaskell и ещё море фич и библиотек, которые могут в этом помочь.
Я бы ещё понял если б ты вспомнил о Немерле с его макросами, но от додиеза выигрыш только в ФП будет.
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Здравствуйте, thesz, Вы писали:
T>Ты не перескакивай между темами.
Это я то перескакиваю?
T>В параграфе выше у тебя нет ничего про "реалии сегодняшнего времени".
T>Поэтому давай, расскажи про "распараллеливание подвыражений" вроде последовательной обработки состояния.
Это как раз и будет перескакиванием да еще и хождением на поводу у оппонента который пытается заставить меня говорить о чем-то, что интересно ему.
Еще раз повторюсь, что я говорил о тех задачах которые знаю не по наслышке и распараллеливание которых уже сейчас нужно и может дать очень хорошие результаты.
И тут все очень просто. Если скажем типизация метода (возвращаясь к моему примеру) написана в императивном стиле без мысли о распараллеливание, то сделать это вычисление параллельным будет очень трудно. Скорее всего придется полностью переписывать код с учетом параллелизма. Если же алгоритм написан в функциональном стиле (то есть, является функцией последовательного преобразования нетипизированного AST в типизированное), то все что нужно сделать для его распараллеливания — это разделить список методов на подсписки количество которых кратно количеству ядер в системе и произвести типизацию методов из каждого подсписка в отдельном потоке.
В общем-то, и императивный алгоритм можно легко выделить в отдельный поток если можно гарантировать, что он не опережается на общее состояние. Но такой императивный алгоритм как раз и выглядит для разработчика как чистая функция не имеющая побочных эффектов. То есть мы опять выходим на ФП.
T>Как ты будешь доказывать коммутативность (возможность изменения порядка) операций над состоянием, что необходимо для выявления параллелизма.
Что ты ком мне то пристал? Я ведь не предлагал распараллеливать отдельные подвыражения. Это твоя идея. Так что ты от меня ее решение требуешь.
T>Насчёт вывода типов погорячился, согласен.
Ну, тык. Я же не говорю, что ФП само по себе позволяет автоматически распараллелить вычисления. Это просто стиль который позволяет решить проблемы распараллеливания проще. В общем, никаких чудес. Просто нет общего состояния, значит любую функцию можно выполнить параллельно. Стало быть нам остается только найти ресурсоемкую функцию которая выполняется в цикле и довольно просто распараллелить ее вызовы.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
И кто сказал, что количество транзисторов потраченное на все эти конвееры и предсказания я не мог бы лучше использовать? Вместо одного ядра я бы сделал 16 специализированных под решение моего типа задач, из того же числа транзисторов. И оно бы летало намного быстрее. Если я могу распараллелить свою задачу. И наоборот, если не могу — то лучше сделать один сверх-умный проц, а не 16 тупых.
Ну о чём у вас спор-то? Ты не веришь, что аппаратно адаптированный под узкий круг задач чип может быть радикально эффективнее компа общего назначения (например однокристаллки)?
Ну в сторону CUDA посмотри, например, или на синоптические чипы...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, VladD2, Вы писали:
VD>Кто тебе мешает создать свой вариант Where, Select и возможно еще неких других методов которые позволят тебе без циклов записывать суть твоих алгоритмов?
Дык он же приводил даже пример гипотетического языка, предназначенного для этих целей?
Павел конечно путанно излагает, но вполне понятно...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, remark, Вы писали:
R>>>Отсутствие разделяемого состояния = легкое распараллеливание = 100% загрузка всех ядер != линейная масштабируемость скорости работы приложения R>>>Отсутствие разделяемого состояния = легкое распараллеливание = 100% загрузка всех ядер возможно= деградация скорости работы приложения
R>Ты хочешь сказать, что присутствие разделяемого состояния устремляет вероятность распараллеливания к нулю? Я правильно понял аналогию?
Я хочу сказать, что твои размышления приведенные выше столь же верны как и бессмысленны. Понятно, что линейное масштабирование на практике почти невозможно. Но это не значит, что масштабирование не нужно если оно не линейное. Бесспорно, что в некоторых случаях возможна даже деградация производительности. Но это не значит, что в большинстве случаев будет так.
В общем, твои слова верны для редких частных случаев и не верны в общем.
Если нет общего состояния, то вычисления будут производиться в общем случае параллельно и не трудно добиться высокого коэффициента масштабирования.
Чем, интересно, загружены ядра если не нужными нами вычислениями? Откуда возьмется деградация? У нас же есть независимые функции вычисляемые разными процессорами. Общего состояния у них нет. И значит, что их можно рассматривать как выполняющиеся на разных компьютерах.
VD>>Да, это так. Только это замечание не имеет прикладного смысла.
R>Ты когда-нибудь занимался распараллеливанием на многоядерных/многопроцессорых/NUMA системах? R>Не имеет прикладного смысла? Очень смешно. Честно. Формальное, даже ручное, распараллеливание программы (т.е. формальное достижение того, что система вроде как может иметь линейное масштабирование с высоты птичьего полёта) зачастую выливается как и в суб-линейную масштабируемость (что-то типа log(N)), так и в деградацию. НО. При этом все процессоры загружены на 100%. А уж как обходить это при автоматическом распараллеливании я совсем не представляю.
Это ты описываешь свой опыт и свои проблемы. Все они проистекают как раз из того, что твои алгоритмы в доску императивный и опираются на общее состояние.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, remark, Вы писали:
R>Замечательно. А я не сталкиваюсь с особыми проблемами при работе в императивном стиле. И мне тоже С++ компилятор помогает тем, что ничем не мешает.
А как ты с ними столкнешся если ты даже стоя по колено в граблях думаешь, что так оно и должно быть и что с этим ничего не поделаешь.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Erop, Вы писали:
VD>>Кто тебе мешает создать свой вариант Where, Select и возможно еще неких других методов которые позволят тебе без циклов записывать суть твоих алгоритмов?
E>Дык он же приводил даже пример гипотетического языка, предназначенного для этих целей? E>Павел конечно путанно излагает, но вполне понятно...
Бред он, в прочем как всегда, излагает. Если попытаться выципить крупицы смысла из его рассуждений, то получится вот что. LINQ — это библиотека предназначенная для обработки последовательностей (ака списки). Библиотека эта инкапсулирует алгоритмы обработки списков. Эти алгоритмы могут быть уточнены функциями передающимися в качестве параметров.
Исходя из этого просто не корректно обсуждать "почему LINQ не позволяет обрабатывать матрицы". А уж рассуждать о каких-то понижениях или повышения на 1, 2, 10 и т.п. Просто бессмысленно.
Создай библиотеку инкапсулирующую алгоритмы обработки матриц и получишь то что воображении Дворкина называется "понижением на один", а у всех остальных называется банальной инкапсуляцией.
Вот ты явно пишешь на С++. Тебе знакомы Boost.Function, Boost: Function, Bind, Lambda?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>В общем, твои слова верны для редких частных случаев и не верны в общем.
Как раз-таки наоборот. Его слова верны в общем случае, а ты говоришь о наиболее вероятных случаях, которые уже являются частными.
Если уж на то пошло, то спор должен идти о распределении задач по шкале "будет деградация" — "будет улучшение" — "будет линейное масштабирование". Мне кажется, ваш спор сводится к тому, что ты ставишь слишком большую часть задач в область "будет улучшение" и далее, а он — "будет улучшение" и меньше.
VD>А как ты с ними столкнешся если ты даже стоя по колено в граблях думаешь, что так оно и должно быть и что с этим ничего не поделаешь.
Ну и самый весомый аргумент в споре — это всё предположить об оппоненте и на этом основании его грязью полить.
Здравствуйте, dr.Chaos, Вы писали:
DC>Да дело то не в ФП, а в возможности построения алгоритмов путём комбинирования набора примитивных операции, а тут у Хаскелла, ИМХО, абсолютное преимущество и система типов, и TemplateHaskell и ещё море фич и библиотек, которые могут в этом помочь.
Ох, ох, ох. Просто фанатизм какой-то. Прямо за пределми Хаскеля мир кончается и только на нем можно комбинаторы делать.
Для "построения алгоритмов путём комбинирования набора примитивных операции" нужно всего лишь, чтобы в языке имелась возможность создавать функции (или лямбды) в рантайме путем комбинирования других функций. Это есть начиная с C# 2.0, а в C# 3.0 это можно делать относительно удобно.
А уж в языках поддерживающих ФП на 100% это делается точно не сложнее чем в Хаскеле.
DC>Я бы ещё понял если б ты вспомнил о Немерле с его макросами, но от додиеза выигрыш только в ФП будет.
Я привел минимально достаточный пример. Вот, к примеру, тебе ссылка
где Elifant говорит о том, что он воспроизвел Parsec на Nemerle. Погляди на реализацию. Макросами там и не пахнет. Только функциональные комбинаторы которые могут быть реализованы и на Шарпе. Менее красиво, более громоздко, но могут.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, remark, Вы писали:
R>Да, всё правильно. Самые интеллектуальные из работающих сейчас и постоянно развивающихся средств поддержки таких парадигм, которые я знаю (средства), — есть библиотеки для С++ и Fortran.
В С++ (Open MP) как раз я вижу самые убогие и экстенсивные средства. Массовый параллелизм на них делать очень сложно.
Из того что есть можно выделить PLINQ и Эрланг (а так же похожие решения: акторы в Скале и Рандеву в Ада).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Erop, Вы писали:
E>Ну о чём у вас спор-то? Ты не веришь, что аппаратно адаптированный под узкий круг задач чип может быть радикально эффективнее компа общего назначения (например однокристаллки)?
Верю. Я не верю в то, что это можно использовать без дополнительных промежуточных абстракций.
E>Ну в сторону CUDA посмотри, например, или на синоптические чипы...
Неистребима страсть местного народа поучать
... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, dr.Chaos, Вы писали:
DC>>Да дело то не в ФП, а в возможности построения алгоритмов путём комбинирования набора примитивных операции, а тут у Хаскелла, ИМХО, абсолютное преимущество и система типов, и TemplateHaskell и ещё море фич и библиотек, которые могут в этом помочь.
VD>Ох, ох, ох. Просто фанатизм какой-то. Прямо за пределми Хаскеля мир кончается и только на нем можно комбинаторы делать.
Дык кто спорит то? Хаскелл вообще в чистый Си преобразовать можно. Толку?
DC>>Я бы ещё понял если б ты вспомнил о Немерле с его макросами, но от додиеза выигрыш только в ФП будет.
VD>Я привел минимально достаточный пример. Вот, к примеру, тебе ссылка
где Elifant говорит о том, что он воспроизвел Parsec на Nemerle. Погляди на реализацию. Макросами там и не пахнет. Только функциональные комбинаторы которые могут быть реализованы и на Шарпе. Менее красиво, более громоздко, но могут.
И на С++ можно на функторах что-то залудить, вопрос в наличии развитого и удобного инструмента иначе, как ты сам любишь говорить, это закат солнца вручную.
ЗЫ Вообще не хочу холиваров Хаскелл vs С#, Хаскелл vs .Net и т.п. Просто на мой взгляд Хаскелл на данный момент наиболее мощный язык и если уж хотим максимальной декларативности и простого распараллеливания то лучше смотреть в эту сторону, но мнения своего никому не навязываю.
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
T>>Значит, не масштабируется. Либо класс задач с такими свойствами (много независимых актёров с изменяемым независимо состоянием) очень узкий.
R>Я не думаю, что он особо узкий. Большинство серверного ПО можно побить на множество актёров, воспользовавшись преимуществом отдельных соединений или запросов. Моделирование различных систем, описываемых графами. Даже в толстых клиентах можно 10-20 независимых актёров/подсистем выделить. Масштабироваться это будет замечательно. Особо много и не надо, достаточно сотен.
Рекомендую попробовать. Практика рассеивает иллюзии, как ничто другое.
Выделенным я занимаюсь последний месяц, похожим я занимался последних два года.
Мой опыт говорит мне прямо противоположное твоим утверждениям.
R>В любом случае непонятно смешивание модели актёров и факта, что они имеют состояние и внутренне не распараллеливаются. Это 2 абсолютно независимых вещи — можно параллелить на уровне актёров (отвлечёмся пока от факта, сколько актёров мы можем выделить в системе — параллелить на таком уровне мы всё равно можем), можно параллелить на уровне отдельных функций (пользуясь преимуществом неизменяемых данных), можно применить сразу оба метода.
Я не смешиваю, я указываю.
Если актер занят обработкой одного запроса и сменой состояния на его основе, он не может обрабатывать другой.
Вместо одного бутылочного горлышка получается сотня или сколько там актеров в системе.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, VladD2, Вы писали:
VD>Бред он, в прочем как всегда, излагает. Если попытаться выципить крупицы смысла из его рассуждений, то получится вот что. LINQ — это библиотека предназначенная для обработки последовательностей (ака списки). Библиотека эта инкапсулирует алгоритмы обработки списков. Эти алгоритмы могут быть уточнены функциями передающимися в качестве параметров.
VD>Исходя из этого просто не корректно обсуждать "почему LINQ не позволяет обрабатывать матрицы". А уж рассуждать о каких-то понижениях или повышения на 1, 2, 10 и т.п. Просто бессмысленно.
VD>Создай библиотеку инкапсулирующую алгоритмы обработки матриц и получишь то что воображении Дворкина называется "понижением на один", а у всех остальных называется банальной инкапсуляцией.
ты всего лишь споришь о словах...
Насколько я понял Павла, "понижением размерности на 2" он называл бы аналог SQL, который, например, мог бы работать с треугольными таблицами. Нафиг это надо -- спроси Павла.
VD>Вот ты явно пишешь на С++. Тебе знакомы Boost.Function, Boost: Function, Bind, Lambda?
Смотрел, но не использую. А как это связпно с темой?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, VladD2, Вы писали:
R>>Замечательно. А я не сталкиваюсь с особыми проблемами при работе в императивном стиле. И мне тоже С++ компилятор помогает тем, что ничем не мешает. VD>А как ты с ними столкнешся если ты даже стоя по колено в граблях думаешь, что так оно и должно быть и что с этим ничего не поделаешь.
Так может не надо искать проблемы-то? Если грабли не мешают, значит не мешают...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, AndrewVK, Вы писали:
E>>Ну о чём у вас спор-то? Ты не веришь, что аппаратно адаптированный под узкий круг задач чип может быть радикально эффективнее компа общего назначения (например однокристаллки)? AVK>Верю. Я не верю в то, что это можно использовать без дополнительных промежуточных абстракций.
Обычно он очень дырявый оказывается. Вообще всё так странно устроено, что для эффективной работы часто требуются дыры в слое абстракций. С и С++ скорее всего так популярны именно из-за дырявости своих обстракций. Свозь эти дыры всюду хорошо и близко доступна аппаратура.
E>>Ну в сторону CUDA посмотри, например, или на синоптические чипы... AVK>Неистребима страсть местного народа поучать
Это было не поучение, а аргумент.
Обрати, кстати, внимание, что слой абстракций "куды" тоже довольно таки дырявый...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
E>Обычно он очень дырявый оказывается. Вообще всё так странно устроено, что для эффективной работы часто требуются дыры в слое абстракций. С и С++ скорее всего так популярны именно из-за дырявости своих обстракций. Свозь эти дыры всюду хорошо и близко доступна аппаратура.
Не уловил мысль
E>Обрати, кстати, внимание, что слой абстракций "куды" тоже довольно таки дырявый...
Следствие убогости куды и недостаточного развития инструментальных средств. Здесь главное понимать — это проблема, которую надо решать, а не оставлять все как есть, заставляя прикладников вникать в тонкости организации внутренних конвееров конкретной железки.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>
Здравствуйте, Mr.Cat, Вы писали:
MC>Напомню, что все началось с того, как remark провел параллель между sql и функциональными языками.
Что значит параллель? Оригинальный SQL, без императивных расширений, это и есть функциональный язык.
MC> Я посчитал, что (т.к. sql довольно узкоспецтализированный dsl) он имеет в виду какое-либо из императивных расширений
При проведении параллелей с функциональными языками имел в виду императивные расширения? Ты его за кого принимаешь?
... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>
Здравствуйте, mkizub, Вы писали:
M>И весь этот бардак решается простым способом — я добавляю в язык новые семантические понятия (вроде арифметики векторов). Если компилятор не понимает этих понятий — компилирует (например) в библиотечные вызовы. Если понимает — прямо компилирует в SIMD инструкции. Быстро, просто, и с гарантированным результатом.
Здравствуйте, Erop, Вы писали:
E>Насколько я понял Павла, "понижением размерности на 2" он называл бы аналог SQL, который, например, мог бы работать с треугольными таблицами.
С прямоугольными.
>Нафиг это надо -- спроси Павла.
Спроси лучше Синклера. Это ему понадобилось объяснение, что такое понижение на 2, ну вот я ему и соорудил пример. Мне он не нужен.
Здравствуйте, Sinclair, Вы писали:
PD>>Хм. Дело в том, что тут не всегда четыре сложения, идущие подряд, есть. Это лишь простейший случай. Их просто может и не быть явно. Чтобы они появились, надо код переписать, сделать так, чтобы они появились. S>Нет. S>Начнем сначала: ты привел пример кода, где сложения выполняются в цикле. S>Да, такой код компилятору трудно векторизовать, но всё еще возможно.
S>Вот если ты постараешься испортить этот код, затуманить задачу — например, вручную распараллелив цикл и навтыкав туда volatile — тут да, точно, "алгоритм придется несколько поменять".
Да нет, все проще. Например, суммирование двух матриц без всякого распараллеливания. Если идем по строке, то 4 числа лежат рядом, их можно взять за один присест из одной матрицы, из другой и векторизованно просуммировать. А если идем по столбцам ? Числа лежат черт те как, их надо в отдельную область памяти скопировать, чтобы потом _m128 загрузить. Не уверен, что компилятор это будет делать, равно как сомневаюсь в осмысленности этого.
S>Легче всего компилятору действовать тогда, когда он компилирует с языка, на котором твои действия записаны в максимально осмысленном виде. Вместо конкретного цикла, с конкретным битоперемешиванием мелконарезанных фрагментов, компилятор, к примеру, наблюдает операцию типа a = b + c, где все компоненты — это, скажем, вектора. Семантика операции + компилятору полностью известна, в том числе коммутативность, а также отсутствие побочных эффектов. Благодаря этому он волен сам выбирать, при помощи чего складывать компоненты, паралелить это или нет, и пользоваться ли MMX/SSE или штатным скалярным execution unit.
См. ответ mkizub. Со своей строны отмечу, что ты привел простой уж очень пример. Да, a=b+c очень уж понятно. А если надо, скажем, a[i] = a[i-1] + b[i]+c[i] ? Или по диагоналям сумму найти ? Не запишешь ведь "понизив на порядок" (в моем определении этого).
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Да нет, все проще. Например, суммирование двух матриц без всякого распараллеливания. Если идем по строке, то 4 числа лежат рядом, их можно взять за один присест из одной матрицы, из другой и векторизованно просуммировать. А если идем по столбцам ? Числа лежат черт те как, их надо в отдельную область памяти скопировать, чтобы потом _m128 загрузить. Не уверен, что компилятор это будет делать, равно как сомневаюсь в осмысленности этого.
Еще раз поясняю: эти проблемы возникают только если "идти по столбцам". Не нужно этого делать: это мешает компилятору.
Если компилятор видит целиком выражение a*b+c*b, то он может применить злую магию и выбрать оптимальный набор операций. Включая транспонирование одной или нескольких матриц для того, чтобы обеспечить эффективность операций. Он может вообще сразу построить некоторые из промежуточных матриц в транспонированном виде.
PD>Со своей строны отмечу, что ты привел простой уж очень пример. Да, a=b+c очень уж понятно. А если надо, скажем, a[i] = a[i-1] + b[i]+c[i] ? Или по диагоналям сумму найти ?
А в этих случаях SIMD помогает? PD>Не запишешь ведь "понизив на порядок" (в моем определении этого).
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Erop, Вы писали: AVK>>Верю. Я не верю в то, что это можно использовать без дополнительных промежуточных абстракций. E>Обычно он очень дырявый оказывается. Вообще всё так странно устроено, что для эффективной работы часто требуются дыры в слое абстракций. С и С++ скорее всего так популярны именно из-за дырявости своих обстракций. Свозь эти дыры всюду хорошо и близко доступна аппаратура.
На досуге поинтересуйся судьбой ключевого слова register в C++, который ты тут всуе поминаешь.
И попробуй проэкстраполировать эту судьбу на другие "дыры, сквозь которые видна аппаратура"
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, VladD2, Вы писали:
VD>Хреновый надо сказать пример, если ты про дотнетгные регекспы. Это как раз пример того, что никакая рантайм-кодогенерация не может заменить качество алгоритмов.
Не уверен. Я что-то при беглом просмотре не нашел бенчмарков, которые бы сравнивали плюсовые и дотнетные регекспы. VD>Помнится у нас подсветка синтаксиса асма дико тормозила как раз в следствии того, что использовались регекспы.
А заменили ее на что? Не на ручной лексер, случайно?
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Спроси лучше Синклера. Это ему понадобилось объяснение, что такое понижение на 2, ну вот я ему и соорудил пример. Мне он не нужен.
Ну то есть был задан риторический вопрос относительно того, почему на SQL пишут мало "реальных программ", несмотря на его ориентированность на обработку данных.
На что ты дал ответ, построенный на некорректных предположениях о сути SQL.
Естественно, сам ответ тоже некорректен. Проблемы SQL совершенно точно не связаны с "недостаточным понижением размерности".
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Erop, Вы писали:
E>ты всего лишь споришь о словах... E>Насколько я понял Павла, "понижением размерности на 2" он называл бы аналог SQL, который, например, мог бы работать с треугольными таблицами. Нафиг это надо -- спроси Павла.
Ага, именно, терминологический спор. Наш препод со стажем к 2008-у году не соизволил разобраться в значении термина "инкапсуляция" и выдумывает какую-то феерическую терминологию.
VD>>Вот ты явно пишешь на С++. Тебе знакомы Boost.Function, Boost: Function, Bind, Lambda? E>Смотрел, но не использую. А как это связпно с темой?
Тогда я даже не знаю как тебе можно это объяснить. Ведь если я сейчас начну говорить о разных функциях высшего порядка и прочей лабуде, ты ровным счетом ничего не поймешь.
Попробуй прочесть о парадоксе блаба
А что таогда фигню говорил в предыдущих сообщениях?
Кстати, вот тебе здесьссылочка на реализацию комбинаторного парсера на C#.
VD>>А уж в языках поддерживающих ФП на 100% это делается точно не сложнее чем в Хаскеле.
DC>Дык кто спорит то? Хаскелл вообще в чистый Си преобразовать можно. Толку?
Ты. Вот сейчас чуть изменил тактику (так как понял, что прогнал фигню) и снова споришь.
Перепиши, скажем, тот же парсек на С или С++ и сравни что получилось. Реализация на Шарпе уступит Хаскелю, но не сильно. А вот в том, что у тебя хоть что-то выйдет из попытки переписать код на С++ я сильно сомневаюсь.
VD>>Я привел минимально достаточный пример. Вот, к примеру, тебе ссылка
где Elifant говорит о том, что он воспроизвел Parsec на Nemerle. Погляди на реализацию. Макросами там и не пахнет. Только функциональные комбинаторы которые могут быть реализованы и на Шарпе. Менее красиво, более громоздко, но могут.
DC>И на С++ можно на функторах что-то залудить, вопрос в наличии развитого и удобного инструмента иначе, как ты сам любишь говорить, это закат солнца вручную.
Ты языком-то не трепи. Пойди и попробуй на С++ тот же Парске переписать. Думаю, после этого нам обеспечен фейерверк эмоций. А до тех пор извини, ты разводишь никчемный трпе.
Можешь в общем-то обосновать свое мнение и без написания парсера (или другого примера). Но обоснование должно быть конструктивным и не противоречивым. Другими словами без лозунгов и по делу.
Я тебе свое обоснование уже дал — если в языке поддерживаются комбинаторы, то все выверты Хаскеля связанные с ним реализуются и на этом языке. Реализация Парсека на Шарпе и Немерле является неплохой иллюстрацией моих слов. Не так ли?
DC>ЗЫ Вообще не хочу холиваров Хаскелл vs С#, Хаскелл vs .Net и т.п. Просто на мой взгляд Хаскелл на данный момент наиболее мощный язык и если уж хотим максимальной декларативности и простого распараллеливания то лучше смотреть в эту сторону, но мнения своего никому не навязываю.
Ты не хочешь Холиваров, но делаешь ни чем не подкрепленные безапелляционные заявления единственная цель которых — это разжигание очередного холивара.
ЗЫ
Твой любимый Хаскель по целой кучи показателей объективно не пригоден для многих людей и многих задач. Начать с того, что он просто не позволяет создать (на сегодня) быстрого кода. Кроме того, в его составе нет библиотек для очень большого круга задач. А какой бы крутой не был язык написать он один фиг не позволит тебе в одиночку решить действительно сложные задачи. Так что если не хочешь холиваров, то не начинай их.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Sinclair, Вы писали:
VD>>Хреновый надо сказать пример, если ты про дотнетгные регекспы. Это как раз пример того, что никакая рантайм-кодогенерация не может заменить качество алгоритмов. S>Не уверен. Я что-то при беглом просмотре не нашел бенчмарков, которые бы сравнивали плюсовые и дотнетные регекспы.
А ты спроси у тех, кто раскраску нашего форума делал. Когда в регексы влоб заложили списко ключевых слов асма, то сайт начал ложиться при открытии страниц с ассемблерными листингами.
Сравнивать там просто не чего. Это детский сад первая четверть. Регексы реализуются на ДКА и НКА. Есть алгоритмы перевода НКА в ДКА. Большинство реализаций регексов производят это преобразование. Дальше совершенно по барабану будет ли использоваться таблица переходов или будет сгенерированны "свитчи" осуществлющие эти переходы. Быстродействие все равно будет O(n). А вот если использовать неоптимизированный НКА, как это делают в дотнетных регексах в следствии мощной системы откатов, то в некоторых случаях производительность будет падать с квадратичной зависимостью.
VD>>Помнится у нас подсветка синтаксиса асма дико тормозила как раз в следствии того, что использовались регекспы. S>А заменили ее на что? Не на ручной лексер, случайно?
Ее не меняли. Там что-то такое подшаманили и забили.
В общем, мои слова были не о том. Просто производительность определяется не только (и даже не главным образом) качеством оптимизации исполнения, сколько алгоритмом. Если алгоритм О(x*x), то хоть обкомпилируйся, а все будет тормозить.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали: VD>В общем, мои слова были не о том. Просто производительность определяется не только (и даже не главным образом) качеством оптимизации исполнения, сколько алгоритмом. Если алгоритм О(x*x), то хоть обкомпилируйся, а все будет тормозить.
Ну, это полностью противоречит позиции "ассемблерщиков".
В данном контексте мы, допустим, предполагаем, что все алгоритмические оптимизации уже сделаны. Дальше вопрос только о том, как оптимальнее всего реализовать алгоритм на целевой архитектуре. И вот тут мне как раз интересно, рулят ли прямые переходы, скомпилированные в асм по месту, или обобщённый код, прыгающий по таблицам.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Erop, Вы писали:
VD>>А как ты с ними столкнешся если ты даже стоя по колено в граблях думаешь, что так оно и должно быть и что с этим ничего не поделаешь.
E>Так может не надо искать проблемы-то? Если грабли не мешают, значит не мешают...
А ты это сказать не можешь. Потому что тебе сравнивать не с чем. Например, если ты всю жизнь ездил на совковых машинах (жугулях, скажем), то когда тебе скажут, что ездить практически на любой иномарке комфортнее и легче, то ты с большой вероятностью ответишь, что тебе и так хорош. Доказать тебе будет ничего не возможно, если конечно ты сам не попробуешь альтернативу.
ЗЫ
Вообще, я тебе гарантирую, что если ты не перейдешь в стадию Дворкина, то тебе через некоторое время будет очень стыдно за свои слова. Так что мой тебе совет, чем спорить о вкусе устриц с теми кто их пробовал, возьми и попробуй их сам. Уверяю тебя, что даже в С++ ты еще не знаешь огого как много. А уж если выйти за рамки этой песочницы, то тебе откроется огромный мир. Намного более интересный.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Sinclair, Вы писали:
VD>>В общем, мои слова были не о том. Просто производительность определяется не только (и даже не главным образом) качеством оптимизации исполнения, сколько алгоритмом. Если алгоритм О(x*x), то хоть обкомпилируйся, а все будет тормозить. S>Ну, это полностью противоречит позиции "ассемблерщиков".
А я на ней никогда не стоял. В прочем, как никтогда не кричал, что все можно написать на Руби.
Просто пример, ты выбрал плохой. С посылом я твоим согласен, а вот пример ухо дерет.
S>В данном контексте мы, допустим, предполагаем, что все алгоритмические оптимизации уже сделаны. Дальше вопрос только о том, как оптимальнее всего реализовать алгоритм на целевой архитектуре. И вот тут мне как раз интересно, рулят ли прямые переходы, скомпилированные в асм по месту, или обобщённый код, прыгающий по таблицам.
Если брать именно регексы, то ответ будет нетривиальным. Разница между переходами по таблицам и прыганию по свитчам (при условии, что анализ таблиц тоже скомпилирванный код, а не на Питоне написан) будет не обчень большой. И как не странно выигрыш не гарантирован. Все будет зависть от распределения в памяти, от размера таблицы и т.п. Скажем если строить автомат для грамматики с большим количеством распознаваемых идентификаторов, то производительность очень быстро упрется в скорость доступа к памяти, так как и таблицы и функция со свитчем будут иметь огромные размеры (вылетающие за пределы кэша). Так что с точки производительности выгоднее опять таки решить проблему алгоритмически. Написать одно граматическое правило которое распознает идетификатор (скажем [a-zA-z][a-zA-z0-9]+), а конкретные ключевые слова проверять по хэш-таблицы. Но такие оптимизации — это уже эвристики, которые автоматически (алгоритмически) не делаются.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Причем тут 1 или 10? Это же банальная инкапсуляция. Товарищь Дворкин в очередной раз не разобравшись пытается агитировать за отказ от инкапсуляции и радостно замечает, что инкапсуляция бывает на разных уровнях. Только заметив это он не может это выразить связанно. Вот и получается у него "на 1".
Чудная логика. Честное слово, я уж и не знаю, как с такими деятелями обращаться. В старые добрые времена... впрочем, не будем, а то меня к ответственности привлекут.
Все же интересно было бы знать, где именно я пытаюсь агитировать за отказ от инкапсуляции. Ну просто интересно найти такое !
VD>Нет там ни на 1, ни на 10, ни на 0.5, ни на 1000. Там есть инкапсуляция конкетных действий. Инкапсуляция: фильтрации, соединения, сортировки, выборки, группировки списков.
Вставку случайно забыл или преднамеренно ? В том-то и дело, что SELECT или UPDATE работает с массивом как со скаляром, а вот INSERT — нет , здесь приходится по одной записи вставлять. И поэтому UPDATE можно всю таблицу, а вот INSERT придется в цикле делать.
VD>Так что называйте вещи своими именами. Не размерность задачи, а ее инкапсуляция. Тогда и ошибок в логике не будет.
В огороде бузина, а в Киеве дядька. Инкапсуляция — никто и не спорит, только вот в одном случае все же работаем с массивом целиком, а в другом — поэлементно.
Ты про что именно? Про то что додиез нет сможет дать тех же преимуществ что и Хаскелл?
VD>Кстати, вот тебе здесьссылочка на реализацию комбинаторного парсера на C#.
У Хаскелла система типов банально мощьнее. Если уж обертывать высокпроизводительную либу на С/С++ в сборку, то лучше её юзать из Немерла или F# того же. Ты сам же давеча ругал C# и Хайлсберга за кривой дизайн и низкую скорость внедрения новых фич.
VD>Я тебе свое обоснование уже дал — если в языке поддерживаются комбинаторы, то все выверты Хаскеля связанные с ним реализуются и на этом языке. Реализация Парсека на Шарпе и Немерле является неплохой иллюстрацией моих слов. Не так ли?
Есть такая штука: HaskellDB, делает примерно то же что и LINQ for SQL, только для этого язык расширять не понадобилось, и даже без TemplateHaskell обошлись. Сделано на системе типов.
Кроме того я нигде не утверждал что на С# невозможно сделать комбинаторы и прочее, просто в Хаскелле это делается проще.
VD>Твой любимый Хаскель по целой кучи показателей объективно не пригоден для многих людей и многих задач. Начать с того, что он просто не позволяет создать (на сегодня) быстрого кода. Кроме того, в его составе нет библиотек для очень большого круга задач. А какой бы крутой не был язык написать он один фиг не позволит тебе в одиночку решить действительно сложные задачи.
Я его где-то назвал идеальным? У Павла есть конкретная задача с матрицами, чистая математика, насколько я понял. Так вот я сказал лишь то что Хаскелл мог бы помочь проще строить сложные алгоритмы, причём вовсе не факт что помог бы в его конкретном случае.
Вообще мой поинт в том, что если уж заморачиваться то уж лучше брать наиболее продвинутый инструмент, и если уж привязываться к .Net-у или JVM, то ни Java ни C# не являются наиболее фичастыми языками. А нужны ли эти фичи и насколько они помогут может показать только практика.
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Здравствуйте, Pavel Dvorkin, Вы писали: PD>Вставку случайно забыл или преднамеренно ? В том-то и дело, что SELECT или UPDATE работает с массивом как со скаляром, а вот INSERT — нет , здесь приходится по одной записи вставлять. И поэтому UPDATE можно всю таблицу, а вот INSERT придется в цикле делать.
Не придется. Insert тоже можно "всю таблицу".
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Mr.Cat, Вы писали:
MC>Здравствуйте, Gluk_Kazan, Вы писали: G_K>>PL/SQL никакого отношения к SQL не имеет
MC>Напомню, что все началось с того, как remark провел параллель между sql и функциональными языками. Я посчитал, что (т.к. sql довольно узкоспецтализированный dsl) он имеет в виду какое-либо из императивных расширений (t-sql, pl/sql). Короче, думаю, далее спорить по этому поводу нет смысла.
А где написано что PL/SQL расширение SQL ???
Про TSQL промолчу из скромности
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>См. ответ mkizub. Со своей строны отмечу, что ты привел простой уж очень пример. Да, a=b+c очень уж понятно. А если надо, скажем, a[i] = a[i-1] + b[i]+c[i] ? Или по диагоналям сумму найти ? Не запишешь ведь "понизив на порядок" (в моем определении этого).
a=a[1..$]+b+c
эквивалентно
a[i]=a[i+1]+b[i]+c[i]
это на Digital Mars D
Уолтер Брайт предвидел подобные вопросы и сделал ЭТО заранее
8))))
Здравствуйте, VladD2, Вы писали:
VD>А тебе не приходила в голову мысль, что можно создать библиотеку аналогичную LINQ-у которая будет точно так же инкапсулировать работу с матрицами. Да еще и позволит задавать их абстрактно?
VD>Кто тебе мешает создать свой вариант Where, Select и возможно еще неких других методов которые позволят тебе без циклов записывать суть твоих алгоритмов?
Здравствуйте, VladD2, Вы писали:
R>>>>Отсутствие разделяемого состояния = легкое распараллеливание = 100% загрузка всех ядер != линейная масштабируемость скорости работы приложения R>>>>Отсутствие разделяемого состояния = легкое распараллеливание = 100% загрузка всех ядер возможно= деградация скорости работы приложения
R>>Ты хочешь сказать, что присутствие разделяемого состояния устремляет вероятность распараллеливания к нулю? Я правильно понял аналогию?
VD>Я хочу сказать, что твои размышления приведенные выше столь же верны как и бессмысленны. Понятно, что линейное масштабирование на практике почти невозможно. Но это не значит, что масштабирование не нужно если оно не линейное. Бесспорно, что в некоторых случаях возможна даже деградация производительности. Но это не значит, что в большинстве случаев будет так.
... Даже не знаю, что сказать... Всё же ты занимался каким-то распараллеливанием? Если бы линейное масштабирование было бо практически не достижимо, то никто бы не делал систем с более, чем ~4 процессорами\ядрами. Однако делают системы и с тысячами процессоров и более.
VD>В общем, твои слова верны для редких частных случаев и не верны в общем.
Я бы сказал как раз наоборот. Просто так получается деградация, это — общий случай. Если приложить усилия специально для этого, то можно получить ускорение, это — частный случай.
VD>Чем, интересно, загружены ядра если не нужными нами вычислениями? Откуда возьмется деградация? У нас же есть независимые функции вычисляемые разными процессорами. Общего состояния у них нет. И значит, что их можно рассматривать как выполняющиеся на разных компьютерах.
Откуда возьмётся деградация?! Ну пожалйста, считай, что современный язык решит все проблемы за тебя.
VD>>>Да, это так. Только это замечание не имеет прикладного смысла.
R>>Ты когда-нибудь занимался распараллеливанием на многоядерных/многопроцессорых/NUMA системах? R>>Не имеет прикладного смысла? Очень смешно. Честно. Формальное, даже ручное, распараллеливание программы (т.е. формальное достижение того, что система вроде как может иметь линейное масштабирование с высоты птичьего полёта) зачастую выливается как и в суб-линейную масштабируемость (что-то типа log(N)), так и в деградацию. НО. При этом все процессоры загружены на 100%. А уж как обходить это при автоматическом распараллеливании я совсем не представляю.
VD>Это ты описываешь свой опыт и свои проблемы. Все они проистекают как раз из того, что твои алгоритмы в доску императивный и опираются на общее состояние.
Хммм... я гляжу, ты так и не научился отличать ситаксис от сути...
По поводу императивных алгоритмов, опирающихся на общее состояние — попробуй реализовать эффективную параллельную одновременную сборку мусора без общего состояния.
Или как ты думаешь "императивные" программисты суммируют вектора или ищёт по-элементный минимум\максимум? Специально вводят разделяемое состояние, что б поинтереснее было?
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, mkizub, Вы писали:
M>>И весь этот бардак решается простым способом — я добавляю в язык новые семантические понятия (вроде арифметики векторов). Если компилятор не понимает этих понятий — компилирует (например) в библиотечные вызовы. Если понимает — прямо компилирует в SIMD инструкции. Быстро, просто, и с гарантированным результатом.
AVK>Я эту ссылку уже приводил недавно: http://tirania.org/blog/archive/2008/Nov-03.html
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, remark, Вы писали:
R>>Да, всё правильно. Самые интеллектуальные из работающих сейчас и постоянно развивающихся средств поддержки таких парадигм, которые я знаю (средства), — есть библиотеки для С++ и Fortran.
VD>В С++ (Open MP) как раз я вижу самые убогие и экстенсивные средства. Массовый параллелизм на них делать очень сложно.
Ааа. Ты опять про синтаксис что ли?
VD>Из того что есть можно выделить PLINQ и Эрланг (а так же похожие решения: акторы в Скале и Рандеву в Ада).
По PLINQ и Эрланг есть какие-то статьи? Я ничего серьёзного не встречал, но судя по тому, что я слышал про Эрланг там как раз всё достаточно тривиально. Там есть тот интеллект, про который ты пишешь? Про PLINQ я так тоже понимаю, что там просто построено поверх TPL, а TPL судя по всему максимально примитивен, большей частью просто калька с Cilk (1994 год).
Здравствуйте, thesz, Вы писали:
T>>>Значит, не масштабируется. Либо класс задач с такими свойствами (много независимых актёров с изменяемым независимо состоянием) очень узкий.
R>>Я не думаю, что он особо узкий. Большинство серверного ПО можно побить на множество актёров, воспользовавшись преимуществом отдельных соединений или запросов. Моделирование различных систем, описываемых графами. Даже в толстых клиентах можно 10-20 независимых актёров/подсистем выделить. Масштабироваться это будет замечательно. Особо много и не надо, достаточно сотен.
T>Рекомендую попробовать. Практика рассеивает иллюзии, как ничто другое.
T>Выделенным я занимаюсь последний месяц, похожим я занимался последних два года.
T>Мой опыт говорит мне прямо противоположное твоим утверждениям.
Я уже отвечал по поводу этого — я думаю, что ты не адресовал 2 момента — (1) грануялярность работы и (2) локальность работы. Это не проблемы агентного подхода как такового. Пожалуйста, прокомментируй по поводу этого? Как ты делал ран-тайм?
R>>В любом случае непонятно смешивание модели актёров и факта, что они имеют состояние и внутренне не распараллеливаются. Это 2 абсолютно независимых вещи — можно параллелить на уровне актёров (отвлечёмся пока от факта, сколько актёров мы можем выделить в системе — параллелить на таком уровне мы всё равно можем), можно параллелить на уровне отдельных функций (пользуясь преимуществом неизменяемых данных), можно применить сразу оба метода.
T>Я не смешиваю, я указываю.
T>Если актер занят обработкой одного запроса и сменой состояния на его основе, он не может обрабатывать другой.
T>Вместо одного бутылочного горлышка получается сотня или сколько там актеров в системе.
Никто не мешает делать кол-во актёров зависимое от размерности входных данных, а не фиксированное. И задачи симуляции как раз могут подпадать под это. Что скажешь? Фактически, тут такая же ситуация как при применении распараллеливания по данным.
А во-вторых, сотня актёров хватит лет на 5 точно, а то и больше. Для серверного ПО это может быть более, чем приемлемо.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Pavel Dvorkin, Вы писали:
S>Еще раз поясняю: эти проблемы возникают только если "идти по столбцам". Не нужно этого делать: это мешает компилятору.
Слушай, ты так говоришь, как будто уверен, что всегда можно в терминах матриц любой код написать, не записывая цикл явно. Попробуй так простенький антиалиасинг сделать, например.
S>Если компилятор видит целиком выражение a*b+c*b, то он может применить злую магию и выбрать оптимальный набор операций. Включая транспонирование одной или нескольких матриц для того, чтобы обеспечить эффективность операций.
Упаси боже! У меня может памяти не хватить! Матрица-то не квадратная. И не одна.
>Он может вообще сразу построить некоторые из промежуточных матриц в транспонированном виде.
Что за промежуточные матрицы — не понял. Сложение матриц реализуется без них. Умножение 3 матриц — тоже, да и больше 3 — ИМХО тоже.
PD>>Со своей строны отмечу, что ты привел простой уж очень пример. Да, a=b+c очень уж понятно. А если надо, скажем, a[i] = a[i-1] + b[i]+c[i] ? Или по диагоналям сумму найти ? S>А в этих случаях SIMD помогает?
А почему нет ? Сложить-то b[i] и c[i] векторизованно ничто не мешает. А остальное — вручную через intrinsic. Суммы(4 штуки) — с регистра в массив float[4] (это одна команда), расчет atemp[i] в цикле от 0 до 3 (atemp — массив из 4 float) , потом запись в a (или опять через регистр, или memcpy)
Для сложения не уверен, что это даст выигрыш, а вот если b[i]/c[i] — ИМХО даст.
Вот это я и имел в виду, говоря, что придется менять алгортитм. То есть вместо
for(i = 0; i < N; i++)
будет
for(i = 0; i < N; i+=4)
{
// действия над тетрадами
// и где-то внутри
for(k=0; k < 4; k++)
// ручная разборка тетрады и те действия, которые не векторизуются
}
Ну и , конечно, если N не кратно 4 — предусмотреть.
Здравствуйте, Sinclair, Вы писали:
S>Ну то есть был задан риторический вопрос относительно того, почему на SQL пишут мало "реальных программ", несмотря на его ориентированность на обработку данных.
На этот вопрос я не отвечал.
S>На что ты дал ответ, построенный на некорректных предположениях о сути SQL.
Ну это лишь твое ИМХО.
S>Естественно, сам ответ тоже некорректен. Проблемы SQL совершенно точно не связаны с "недостаточным понижением размерности".
А о проблемах SQL я вообще не говорил. Ссылку в студию, где я их обсуждал.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Pavel Dvorkin, Вы писали: PD>>Вставку случайно забыл или преднамеренно ? В том-то и дело, что SELECT или UPDATE работает с массивом как со скаляром, а вот INSERT — нет , здесь приходится по одной записи вставлять. И поэтому UPDATE можно всю таблицу, а вот INSERT придется в цикле делать. S>Не придется. Insert тоже можно "всю таблицу".
Вот специально не стал об этом говорить. Все ждал, отметит ли кто-нибудь, и как. Ну и естственно. А то, что речь идет совсем не ою этом (а о вставке отдельных элементов) — не важно. Чудные способы дискутирования.
Здравствуйте, VladD2, Вы писали:
VD>Ага, именно, терминологический спор. Наш препод со стажем к 2008-у году не соизволил разобраться в значении термина "инкапсуляция" и выдумывает какую-то феерическую терминологию.
Ну вот что, уважаемый. Долго я терпел твои выходки в мой адрес, но мне это в конце концов надоело. Я их со своей стороны не допускал, но теперь все. Получишь все, что тебе причитается. Жди.
Здравствуйте, Gluk_Kazan, Вы писали:
PD>>Еще раз — понижение размерности есть оперирование с массивами (списками, коллекциями, наборами — как хочешь назови) — как со скалярами. А циклы при этом могут быть хоть одинарные, хоть двойные, хоть больше. Возведение элементов массива в квадрат — линейный цикл, пузырек — двойной, а массив все равно линейный.
G_K>Он сразу становится менее линейный если рассмотреть чуть более сложные задачи, НЕ МАССИВ это, а набор кортежей (не упорядоченный, не индексированный)
Да бога ради, называй как хочешь. Я же выше об этом сказал. Меня только одно интересует — это массовая структура, а поэтому массовые операции.
G_K>SQL предоставляет абстракции реализация которых может различаться в зависимости от фаз луны.
G_K>цыкл — это по любому конкретика
Конкретика или нет — а без цикла никаких реальных действий надо массовой структурой (кроме тривиальных) не произведешь. Из этого отнюдь не следует, что цикл линейный или двойной и т.п.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, Sinclair, Вы писали:
S>>Здравствуйте, Pavel Dvorkin, Вы писали: PD>>>Вставку случайно забыл или преднамеренно ? В том-то и дело, что SELECT или UPDATE работает с массивом как со скаляром, а вот INSERT — нет , здесь приходится по одной записи вставлять. И поэтому UPDATE можно всю таблицу, а вот INSERT придется в цикле делать. S>>Не придется. Insert тоже можно "всю таблицу".
PD>Вот специально не стал об этом говорить. Все ждал, отметит ли кто-нибудь, и как. Ну и естственно. А то, что речь идет совсем не ою этом (а о вставке отдельных элементов) — не важно. Чудные способы дискутирования.
не уловил логику
select - Можно выбрать набор
- Можно выбрать одну запись
update - Можно изменить набор (с известными гемороями)
- Можно изменить одну запись
insert - Можно вставить набор (можно даже в несколько таблиц в Oracle)
Можно вставить одну запись
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, Gluk_Kazan, Вы писали:
PD>>>Еще раз — понижение размерности есть оперирование с массивами (списками, коллекциями, наборами — как хочешь назови) — как со скалярами. А циклы при этом могут быть хоть одинарные, хоть двойные, хоть больше. Возведение элементов массива в квадрат — линейный цикл, пузырек — двойной, а массив все равно линейный.
G_K>>Он сразу становится менее линейный если рассмотреть чуть более сложные задачи, НЕ МАССИВ это, а набор кортежей (не упорядоченный, не индексированный)
PD>Да бога ради, называй как хочешь. Я же выше об этом сказал. Меня только одно интересует — это массовая структура, а поэтому массовые операции.
G_K>>SQL предоставляет абстракции реализация которых может различаться в зависимости от фаз луны.
G_K>>цыкл — это по любому конкретика
PD>Конкретика или нет — а без цикла никаких реальных действий надо массовой структурой (кроме тривиальных) не произведешь. Из этого отнюдь не следует, что цикл линейный или двойной и т.п.
Ага, а может и не цикл вовсе
Это абстракция, как она реализуется НЕ ИЗВЕСТНО
T>>Рекомендую попробовать. Практика рассеивает иллюзии, как ничто другое. T>>Выделенным я занимаюсь последний месяц, похожим я занимался последних два года. T>>Мой опыт говорит мне прямо противоположное твоим утверждениям. R>Я уже отвечал по поводу этого — я думаю, что ты не адресовал 2 момента — (1) грануялярность работы и (2) локальность работы. Это не проблемы агентного подхода как такового. Пожалуйста, прокомментируй по поводу этого? Как ты делал ран-тайм?
Я бы порекомендовал тебе попробовать. Настойчиво порекомендовал бы.
Сейчас ты рассуждаешь об агентном подходе "в вакууме", без приложения к какой-то определённой задаче или классу задач. У тебя присутствует некоторое "серверное ПО", без фиксации, что же это такое.
Поэтому у меня просьба: зафиксируй класс задач, реализуй типичную и посмотри, что произойдёт.
Рантайм у меня был Хаскельный, я просто расставил в нужных местах аннотации par+pseq и запускал с разным количеством процессоров. Потратить 20 минут на ускорение в 20% — приемлемо, по-моему.
T>>Если актер занят обработкой одного запроса и сменой состояния на его основе, он не может обрабатывать другой. T>>Вместо одного бутылочного горлышка получается сотня или сколько там актеров в системе. R>Никто не мешает делать кол-во актёров зависимое от размерности входных данных, а не фиксированное. И задачи симуляции как раз могут подпадать под это. Что скажешь?
Рекомендую взять задачу симуляции и проверить. Да что угодно взять, и проверить решением.
У меня, например, получается совершенно нетривиально. Например, необходимо выделять слабосвязанные подграфы и тщательно смотреть, не может ли кто послать некоторому подграфу лишнего или гарантировать низкую вероятность этой посылки.
Вот тогда можно этот подграф выполнять параллельно определённое небольшое (или чуть большее) время с другими подграфами. А потом надо синхронизироваться и смотреть, можем ли мы зафиксировать результаты работы или надо откатываться.
На данном примере — задачи моделирования аппаратуры, — мы воочию наблюдаем, что агентный подход требует не менее сложной предварительной обработки, чем любой другой.
Не думаю, что это будет легче для любой другой задачи.
R>Фактически, тут такая же ситуация как при применении распараллеливания по данным. R>А во-вторых, сотня актёров хватит лет на 5 точно, а то и больше. Для серверного ПО это может быть более, чем приемлемо.
Э-эх.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>>Вставку случайно забыл или преднамеренно ? В том-то и дело, что SELECT или UPDATE работает с массивом как со скаляром, а вот INSERT — нет , здесь приходится по одной записи вставлять. И поэтому UPDATE можно всю таблицу, а вот INSERT придется в цикле делать. S>>Не придется. Insert тоже можно "всю таблицу".
PD>Вот специально не стал об этом говорить. Все ждал, отметит ли кто-нибудь, и как. Ну и естственно. А то, что речь идет совсем не ою этом (а о вставке отдельных элементов) — не важно. Чудные способы дискутирования.
Ничего непонятно.
Если ты хочешь вставить одну запись — значит надо вставлять одну запись. В принципе, одиночная запись это тоже множество, только очень маленькое
Если ты хочешь вставлять сразу множество записей — можешь вставлять множество:
insert into tbl1 select a as b, c as d, xyz as etc from tbl2 where (allMyIntellectualFiltrationAndOtherTrickyThings)
Чего ты хочешь? Такой инсерт, который пишется вручную, но при этом позволяет вставить сразу несколько записей? Сделать его не проблема, только в нем никакой пользы по сравнению с серией одиночных инсертов. Вот его и не добавили.
Здравствуйте, fmiracle, Вы писали:
F>Чего ты хочешь? Такой инсерт, который пишется вручную, но при этом позволяет вставить сразу несколько записей? Сделать его не проблема, только в нем никакой пользы по сравнению с серией одиночных инсертов. Вот его и не добавили.
Опять же, никто не мешает селект, который возвратит набор константно заданных кортежей.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>
Здравствуйте, Pavel Dvorkin, Вы писали: PD>На этот вопрос я не отвечал.
>Иногда это может помочь, иногда помешать. Это палка о двух концах. Например, в SQL есть много чего для экстремально комфортной работы с данными, однако только на SQL пишут мало реальных систем.
А попробую я некоторые соображения изложить. Благо SQL тут хороший пример , да и LinQ от него недалеко ушел.
Выглядит именно как ответ S>>На что ты дал ответ, построенный на некорректных предположениях о сути SQL. PD>Ну это лишь твое ИМХО.
Павел, это медицинский факт. Я уже объяснил различие между твоим подходом к SQL и корректным.
PD>А о проблемах SQL я вообще не говорил. Ссылку в студию, где я их обсуждал.
Цитирую:
Ну а если еще ORDER или GROUP добавить, то SQL с LinQ вообще рулят. Потому что на императивном языке тут и цикл будет посложнее, а может, и не один цикл понадобится.
Пока все замечательно.
Проблемы начинаются как только потребуется делать что-то, что не укладывается в условие "понизить размерность на единицу".
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Pavel Dvorkin, Вы писали:
S>>Еще раз поясняю: эти проблемы возникают только если "идти по столбцам". Не нужно этого делать: это мешает компилятору.
PD>Слушай, ты так говоришь, как будто уверен, что всегда можно в терминах матриц любой код написать, не записывая цикл явно. Попробуй так простенький антиалиасинг сделать, например.
Антиалиасинг — это понижение размерности матрицы, где мы каждый пиксель считаем как сумму квадрата n*n, деленную на n*n?
Простенький антиалиасинг записывается как T*A*T', где A — исходная матрица, а T — матрица даунсэмплинга, размером N * N/cellsize.
S>>Если компилятор видит целиком выражение a*b+c*b, то он может применить злую магию и выбрать оптимальный набор операций. Включая транспонирование одной или нескольких матриц для того, чтобы обеспечить эффективность операций. PD>Упаси боже! У меня может памяти не хватить! Матрица-то не квадратная. И не одна.
Ну и что? Если это jit-компилятор, то он точно знает, сколько у тебя памяти. Потоковые алгоритмы еще никто не отменял.
PD>Что за промежуточные матрицы — не понял. Сложение матриц реализуется без них. Умножение 3 матриц — тоже, да и больше 3 — ИМХО тоже.
Честно признаюсь — в умножении матриц я не специалист. Не знаю, можно ли выполнить умножение 3х матриц без построения промежуточной. Наверное, можно, только циклов будет очень много. Это, особенно для больших матриц, должно приводить к ухудшению cache locality, ради которого, в принципе, наверное можно и сохранить результаты.
Но опять же, максимальные возможности по оптимизации будут у того компилятора, который "видит" задачу целиком. Не просто "без циклов", чтобы выбрать циклы оптимально, а и сразу цепочку операций, чтобы суметь обойтись без промежуточных объектов.
PD>А почему нет ? Сложить-то b и c[i] векторизованно ничто не мешает. А остальное — вручную через intrinsic. Суммы(4 штуки) — с регистра в массив float[4] (это одна команда), расчет atemp[i] в цикле от 0 до 3 (atemp — массив из 4 float) , потом запись в a (или опять через регистр, или memcpy) PD>Для сложения не уверен, что это даст выигрыш, а вот если b[i]/c[i] — ИМХО даст.
То-то и оно, что ты — не уверен. А в компиляторе — более-менее точная модель целевого процессора. Ему видно, какие операции стоит загонять в SSE, а какие дешевле пешком выполнить.
PD>Вот это я и имел в виду, говоря, что придется менять алгортитм. То есть вместо
Павел, вот это "изменение алгоритма" называется "развертка цикла" и применяется в промышленных компиляторах лет 15 уже. И, в частности, именно потому, что позволяет [i]дальнейшие оптимизации. PD>Ну и , конечно, если N не кратно 4 — предусмотреть.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
>Иногда это может помочь, иногда помешать. Это палка о двух концах. Например, в SQL есть много чего для экстремально комфортной работы с данными, однако только на SQL пишут мало реальных систем.
S>А попробую я некоторые соображения изложить. Благо SQL тут хороший пример , да и LinQ от него недалеко ушел.
S>Выглядит именно как ответ
Нет. Я просто решил некоторые соображения изложить. Ни о чем по фразе выше я не говорил, а просто совсем в другую сторону ушел.
S>>>На что ты дал ответ, построенный на некорректных предположениях о сути SQL. PD>>Ну это лишь твое ИМХО. S>Павел, это медицинский факт. Я уже объяснил различие между твоим подходом к SQL и корректным.
Все же я одно не пойму. Ты уверен, что такими аргументами можно что-то доказать ? Для тебя это верно, допустим, даже очевидно, для другого нет. Аргументируя же "это общеизвестно", "это медицинский факт" — ИМХО ничего не докажешь.
PD>>А о проблемах SQL я вообще не говорил. Ссылку в студию, где я их обсуждал. S>Цитирую: S>
Ну а если еще ORDER или GROUP добавить, то SQL с LinQ вообще рулят. Потому что на императивном языке тут и цикл будет посложнее, а может, и не один цикл понадобится.
S>Пока все замечательно.
S>Проблемы начинаются как только потребуется делать что-то, что не укладывается в условие "понизить размерность на единицу".
Выдергивая фразы из контекста, можно что угодно доказать. В данном случае речь идет о действиях, которые (в моей терминологии) не укладываются в схему "понизить на 1 ". Но SQL это ни к чему, оно там просто не нужно, поскольку там нет таких средств, оперируем с наборами (кроме INSERT). А вот LinQ — это все же часть C#, а там такие средства (работы с отдельными записями) есть. Поэтому в SQL эти проблемы я и не обсуждаю, а в LinQ они возникают, когда пытаешься делать то, что позволяет обычный доступ к элементам, к примеру.
Здравствуйте, Gluk_Kazan, Вы писали:
G_K>select — Можно выбрать набор G_K> — Можно выбрать одну запись
Может быть, я плохо знаю SQL, но мне все же кажется, что с помощью SELECT мы выбираем в любом случае набор. Пусть таблица содержит что угодно и никаких PK там нет, а значит, дубликаты вполне возможны. Можно, конечно, указать LIMIT 1, но это лишь будет означать, что ты выбираешь набор, в котором будет одна запись. Ну не может же быть, чтобы LIMIT 2 и LIMIT 1 возвращали в одном случае именно набор, а в другом — не набор. Кстати, даже LIMIT 1 отнюдь не гарантирует, что ты выберешь одну запись — ты можешь получить 0 записей, то есть пустой набор.
Конечно, при наличии PK можно гарантировать выборку именно одной записи, но это все равно будет выборкой набора, в котором не может быть (из-за PK) больше одной. А ни одной все равно может.
PD>Все же я одно не пойму. Ты уверен, что такими аргументами можно что-то доказать ? Для тебя это верно, допустим, даже очевидно, для другого нет. Аргументируя же "это общеизвестно", "это медицинский факт" — ИМХО ничего не докажешь.
А какими аргументами тебе надо что-то доказывать? Когда я начинаю разжевывать, ты дуешься и говоришь, что тебе надоели мои лекции.
Я уже привел тебе основные соображения по поводу того, что в SQL (а, точнее, в реляционной алгебре) ты понимаешь неправильно.
Подробнее можно выяснить в любом учебнике по базам данных.
PD>Выдергивая фразы из контекста, можно что угодно доказать. В данном случае речь идет о действиях, которые (в моей терминологии) не укладываются в схему "понизить на 1 ". Но SQL это ни к чему, оно там просто не нужно, поскольку там нет таких средств, оперируем с наборами (кроме INSERT).
Еще раз напоминаю, что insert тоже оперирует с наборами. Павел, это что, так трудно — признать, что ошибся и пойти почитать книги/документацию?
Во-вторых, еще раз объясняю, что действия, которые ты считаешь "неуложимыми" прекрасно выполняются на SQL.
PD>А вот LinQ — это все же часть C#, а там такие средства (работы с отдельными записями) есть. Поэтому в SQL эти проблемы я и не обсуждаю, а в LinQ они возникают, когда пытаешься делать то, что позволяет обычный доступ к элементам, к примеру.
И в LinQ, соответственно, тоже нет таких проблем, которые тебе кажутся. Или слова "проблемы начинаются" относилось и не к Linq?
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Pavel Dvorkin, Вы писали: PD>Может быть, я плохо знаю SQL, но мне все же кажется, что с помощью SELECT мы выбираем в любом случае набор.
Да, совершенно верно. Ну, точнее, есть некоторые диалект-специфические вещи, но в целом — именно набор.
PD>Пусть таблица содержит что угодно и никаких PK там нет, а значит, дубликаты вполне возможны. Можно, конечно, указать LIMIT 1, но это лишь будет означать, что ты выбираешь набор, в котором будет одна запись. Ну не может же быть, чтобы LIMIT 2 и LIMIT 1 возвращали в одном случае именно набор, а в другом — не набор. Кстати, даже LIMIT 1 отнюдь не гарантирует, что ты выберешь одну запись — ты можешь получить 0 записей, то есть пустой набор. PD>Конечно, при наличии PK можно гарантировать выборку именно одной записи, но это все равно будет выборкой набора, в котором не может быть (из-за PK) больше одной. А ни одной все равно может.
С точки зрения SQL, это не более чем оптимизация. То есть "тип" select никак не меняется в зависимости от where. То, что будет возвращаться ровно одна либо 0 записей, может использоваться в оптимизаторе, но на семантику никак не влияет.
Семантика insert на самом деле ровно такая же. Просто придуман "сахар", специальный синтаксис для описания реляции из одной строки.
В некоторых диалектах такой же синтаксис позволяет описать реляцию в несколько строк; в других нужно явным образом строить резалтсет из select и union.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Pavel Dvorkin, Вы писали:
S>Антиалиасинг — это понижение размерности матрицы, где мы каждый пиксель считаем как сумму квадрата n*n, деленную на n*n?
Разные варианты есть. У меня центральный пиксель берется с весом 4. Его ближайшие соседи (4) с весом 1. Матрица, конечно.
S>Простенький антиалиасинг записывается как T*A*T', где A — исходная матрица, а T — матрица даунсэмплинга, размером N * N/cellsize.
Чудненько. Надеюсь, ты хоть матрицу транспонировать не будешь, а то кто знает. А вот код
for ( i = LineCoOrdinates->Left + 1; i < LineCoOrdinates->Right; i++)
for ( j = LineCoOrdinates->Top + 1 ; j < LineCoOrdinates->Bottom; j++)
{
centre = SrcBuf[j * InImage->BufferWidthInBytes + i];
left = SrcBuf[j * InImage->BufferWidthInBytes + i - 1];
right = SrcBuf[j * InImage->BufferWidthInBytes + i + 1];
top = SrcBuf[(j - 1) * InImage->BufferWidthInBytes + i];
bottom = SrcBuf[(j + 1) * InImage->BufferWidthInBytes + i];
result = (centre * 4 + left + right + top + bottom ) >> 3;
if(result !=255) result = 0;
OutBuf[(j- LineCoOrdinates->Top) * nWidth + i - LineCoOrdinates->Left] = result;
}
И никаких умножений матриц, и тем более транспонирования.
И то это не оптимальный вариант.
S>>>Если компилятор видит целиком выражение a*b+c*b, то он может применить злую магию и выбрать оптимальный набор операций. Включая транспонирование одной или нескольких матриц для того, чтобы обеспечить эффективность операций. PD>>Упаси боже! У меня может памяти не хватить! Матрица-то не квадратная. И не одна. S>Ну и что? Если это jit-компилятор, то он точно знает, сколько у тебя памяти. Потоковые алгоритмы еще никто не отменял.
Нет уж, спасибо за потоковые алгоритмы в моей задаче. Мне и память на них жалко, и времени нет. А насчет того, что он знает, сколько памяти — это просто заблуждение. Сколько свободной памяти на машине сейчас — это он знает. Сколько ее будет через 100 мсек — никто не знает. А теперь представь себе рабочую станцию, на которой крутятся 5-10 таких процессов, и в каждом из них jit "знает". Через секунду они все по памяти передерутся, их страницы начнут сбрасываться в своп и будет весело.
В моей задаче только я имею право знать, сколько у меня памяти задействовано, и не допускать, чтобы лишняя память была занята. И я это знаю. С точностью до 10 Кбайт
PD>>Что за промежуточные матрицы — не понял. Сложение матриц реализуется без них. Умножение 3 матриц — тоже, да и больше 3 — ИМХО тоже. S>Честно признаюсь — в умножении матриц я не специалист. Не знаю, можно ли выполнить умножение 3х матриц без построения промежуточной.
Эх...
Было мне 20 с чем-то лет. И вот на машине с памятью 32 КСлова (слово — 48 бит) надо было множественную линейную регрессию сделать. А там как раз C'AC. Сделать промежуточную матрицу — значить понизить размеры массивов, а это очень нехорошо, задача не уложится. Вот я и сидел больше часа и изобретал этот алгоритм. Нутром чуял — можно, а никак не получалось. Но сделал все же.
>Наверное, можно, только циклов будет очень много.
Нет, все равно тройной цикл. Просто циклы переставить надо
>Это, особенно для больших матриц, должно приводить к ухудшению cache locality, ради которого, в принципе, наверное можно и сохранить результаты.
Это да. Приведет, скорее всего, так как там будут проходы по столбцам. Но тогда это меня не волновало из-за незнания слова "кэш" и из-за отсутствия кэша
S>Но опять же, максимальные возможности по оптимизации будут у того компилятора, который "видит" задачу целиком. Не просто "без циклов", чтобы выбрать циклы оптимально, а и сразу цепочку операций, чтобы суметь обойтись без промежуточных объектов.
Вот здесь наше с тобой основное расхождение. И не только с тобой. Ты уверен, что лучше все поручить компилятору. Я готов с этим даже частично согласиться — достаточно стандартные действия — да, если в него зашит оптимизирующий блок для этих стандартных действий. Действительно, сказать ему C=A*B, и пусть применит наилучший способ. Проблема же в том, что порой нужна тонкая настройка, а компилятор просто не может иметь в себе все ее варианты. Вот ты матрицы для антиалиасинга предложил умножать. Формально — корректно. Может, даже некий гипотетический компилятор это очень хорошо сделает. А я вообще ничего умножать не буду.
PD>>А почему нет ? Сложить-то b и c[i] векторизованно ничто не мешает. А остальное — вручную через intrinsic. Суммы(4 штуки) — с регистра в массив float[4] (это одна команда), расчет atemp[i] в цикле от 0 до 3 (atemp — массив из 4 float) , потом запись в a (или опять через регистр, или memcpy) PD>>Для сложения не уверен, что это даст выигрыш, а вот если b[i]/c[i] — ИМХО даст. S>То-то и оно, что ты — не уверен. А в компиляторе — более-менее точная модель целевого процессора. Ему видно, какие операции стоит загонять в SSE, а какие дешевле пешком выполнить.
Я не уверен, да. Пробовать надо. Тут от многого зависит, в том числе, к примеру, от необходимости выравнивать на 16 для SSE2. Компилятору виднее, верно. Но для этого он должен быть в состоянии это сделать! А это совсем не очевидно.
PD>>Вот это я и имел в виду, говоря, что придется менять алгортитм. То есть вместо S>Павел, вот это "изменение алгоритма" называется "развертка цикла" и применяется в промышленных компиляторах лет 15 уже. И, в частности, именно потому, что позволяет [i]дальнейшие оптимизации.
Черти бы эту развертку цикла взяли. Я свою программу довел до кондиции и решил Intel C++ откомпилировать, думаю, хоть процентов 10 еще получу. Получил с точностью до наоборот, именно из-за этой развертки. Экспетиментировал с его настройками — все без толку.
Но во всем свой плюс есть. Дкмал, придется заказчику рекомендовать покупку ICC. Теперь не придется
А вообще насчет развертки — все не так просто. Местами разворачивается, местами нет.
Здравствуйте, thesz, Вы писали:
T>>>Рекомендую попробовать. Практика рассеивает иллюзии, как ничто другое. T>>>Выделенным я занимаюсь последний месяц, похожим я занимался последних два года. T>>>Мой опыт говорит мне прямо противоположное твоим утверждениям. R>>Я уже отвечал по поводу этого — я думаю, что ты не адресовал 2 момента — (1) грануялярность работы и (2) локальность работы. Это не проблемы агентного подхода как такового. Пожалуйста, прокомментируй по поводу этого? Как ты делал ран-тайм?
T>Я бы порекомендовал тебе попробовать. Настойчиво порекомендовал бы.
T>Сейчас ты рассуждаешь об агентном подходе "в вакууме", без приложения к какой-то определённой задаче или классу задач. У тебя присутствует некоторое "серверное ПО", без фиксации, что же это такое.
T>Поэтому у меня просьба: зафиксируй класс задач, реализуй типичную и посмотри, что произойдёт.
T>Рантайм у меня был Хаскельный, я просто расставил в нужных местах аннотации par+pseq и запускал с разным количеством процессоров. Потратить 20 минут на ускорение в 20% — приемлемо, по-моему.
Ну я надеюсь, ты понимаешь, что вот так просто "на слабо" никто не будет садиться и реализовывать полноценную систему. Поэтому намекни просто, что же я должен увидеть после самостоятельной реализации. Вполне вероятно, что намёка будет достаточно. Так в чём же была причина плохой распараллеливаемости? Это именно агентный подход плох для распараллеливания задач симуляции или конкретная реализация? У меня подозрение, что конкретная реализация.
По поводу 20% — смотря какую цель ставить. Само по себе 20% за 20 минут, конечно, не плохо. Но если задача, например, — создать среду для эфективного моделирования на современном многоядерном железе (сейчас — 2/4 ядра, завтра — 8) — то задача не решена. Если на 2 ядрах, у тебя 20%, это значит, что на 4 будет 30%, а на 8 — 35%, т.е. используем только 17% вычислительной мощности.
T>>>Если актер занят обработкой одного запроса и сменой состояния на его основе, он не может обрабатывать другой. T>>>Вместо одного бутылочного горлышка получается сотня или сколько там актеров в системе. R>>Никто не мешает делать кол-во актёров зависимое от размерности входных данных, а не фиксированное. И задачи симуляции как раз могут подпадать под это. Что скажешь?
T>Рекомендую взять задачу симуляции и проверить. Да что угодно взять, и проверить решением.
T>У меня, например, получается совершенно нетривиально. Например, необходимо выделять слабосвязанные подграфы и тщательно смотреть, не может ли кто послать некоторому подграфу лишнего или гарантировать низкую вероятность этой посылки.
Так проблема была в низкой гранулярности?
T>Вот тогда можно этот подграф выполнять параллельно определённое небольшое (или чуть большее) время с другими подграфами. А потом надо синхронизироваться и смотреть, можем ли мы зафиксировать результаты работы или надо откатываться.
T>На данном примере — задачи моделирования аппаратуры, — мы воочию наблюдаем, что агентный подход требует не менее сложной предварительной обработки, чем любой другой.
T>Не думаю, что это будет легче для любой другой задачи.
Ну то, что эффективная многоядерность будет лёгкой никто (по-крайней мере я) и не говорит.
По поводу автоматического увеличения гранулярности, пока ничего не могу сказать — это я просто на скорую руку рекомендовал человеку куда надо думать, что бы достить эффективного распараллеливания. Скорее всего я буду думать над этой задачей, но пока не могу ничего сказать. Гипотеза, что есть некоторые относительно простые эвристики, которые позволят автоматически добиваться близкой к оптимальной кластеризации.
R>>Фактически, тут такая же ситуация как при применении распараллеливания по данным. R>>А во-вторых, сотня актёров хватит лет на 5 точно, а то и больше. Для серверного ПО это может быть более, чем приемлемо.
T>Э-эх.
Не согласен? Если, например, имеется 4-ядерный сервер, или 2-процессорный х 4-ядерный, сотня агентов более чем хватит. Нет? А через 3 года при существенном увеличении нагрузки всё-равно большую часть переписывать.
Здравствуйте, Sinclair, Вы писали:
PD>>Все же я одно не пойму. Ты уверен, что такими аргументами можно что-то доказать ? Для тебя это верно, допустим, даже очевидно, для другого нет. Аргументируя же "это общеизвестно", "это медицинский факт" — ИМХО ничего не докажешь. S>А какими аргументами тебе надо что-то доказывать? Когда я начинаю разжевывать, ты дуешься и говоришь, что тебе надоели мои лекции.
Да. Но ты просто не можешь никак согласиться, что мнение может быть иным.
S>Я уже привел тебе основные соображения по поводу того, что в SQL (а, точнее, в реляционной алгебре) ты понимаешь неправильно.
Я тебе тоже объяснял, что дело вовсе не в реляционной алгебре.
S>Подробнее можно выяснить в любом учебнике по базам данных.
Спасибо
PD>>Выдергивая фразы из контекста, можно что угодно доказать. В данном случае речь идет о действиях, которые (в моей терминологии) не укладываются в схему "понизить на 1 ". Но SQL это ни к чему, оно там просто не нужно, поскольку там нет таких средств, оперируем с наборами (кроме INSERT). S>Еще раз напоминаю, что insert тоже оперирует с наборами.
Да кто же спорит, Антон ? Я разве сказал, что не оперирует ? Я просто сказал, что оперирует и с отдельными записями.
>Павел, это что, так трудно — признать, что ошибся и пойти почитать книги/документацию?
Да нет, конечно, не трудно, но я никак не пойму, в какой ошибке ты меня упрекаешь ? В реляционной алгебре ? Я же объяснил, что не о ней речь.
S>Во-вторых, еще раз объясняю, что действия, которые ты считаешь "неуложимыми" прекрасно выполняются на SQL.
По диагонали тоже ?
S>И в LinQ, соответственно, тоже нет таких проблем, которые тебе кажутся. Или слова "проблемы начинаются" относилось и не к Linq?
Редкий случай — мне не приходится возражать Одно лишь замечание.
S>Да, совершенно верно. Ну, точнее, есть некоторые диалект-специфические вещи, но в целом — именно набор.
Так если набор, почему же ты не согласен, что мы именно с набором и оперируем ? Это ведь все, что я хотел сказать, говоря о специфике SQL. Одной "командой" получаем набор. Вот и все. В императивных языках такого нет (я не о вызовах говорю, а о реализации в языке). В Альфе (помнишь, я о ней говорил) было
S>Семантика insert на самом деле ровно такая же. Просто придуман "сахар", специальный синтаксис для описания реляции из одной строки.
Тоже не возражаю. Правда, ИМХО дело не в сахаре, а в том, что по реальным потребностям выполнить некую выборку или змену для всего набора имеет смысл часто, а вставляют все же чаще по одной. Жизнь такова
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Вот здесь наше с тобой основное расхождение. И не только с тобой. Ты уверен, что лучше все поручить компилятору. Я готов с этим даже частично согласиться — достаточно стандартные действия — да, если в него зашит оптимизирующий блок для этих стандартных действий. Действительно, сказать ему C=A*B, и пусть применит наилучший способ. Проблема же в том, что порой нужна тонкая настройка, а компилятор просто не может иметь в себе все ее варианты. Вот ты матрицы для антиалиасинга предложил умножать. Формально — корректно. Может, даже некий гипотетический компилятор это очень хорошо сделает. А я вообще ничего умножать не буду.
Компилятору можно помогать с помощью декларации rewriting rules, например.
PD>А вообще насчет развертки — все не так просто. Местами разворачивается, местами нет.
Эти проблемы и проистекают от низкоуровневости языка и неизвестной компилятору семантики. Если компилятор знает о чистоте функции, коммутативности и ассоциативности операции, знает где у нас свертка, а где отображение — он может оптимизировать не только кое-где и кое-что, в соответствии с какими-то эвристиками для какого-то набора частных случаев, а осуществлять преобразования по набору правил, как при символьном дифференцировании, например.
... << RSDN@Home 1.2.0 alpha 4 rev. 1110>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, Gluk_Kazan, Вы писали:
G_K>>select — Можно выбрать набор G_K>> — Можно выбрать одну запись
PD>Может быть, я плохо знаю SQL, но мне все же кажется, что с помощью SELECT мы выбираем в любом случае набор. Пусть таблица содержит что угодно и никаких PK там нет, а значит, дубликаты вполне возможны. Можно, конечно, указать LIMIT 1, но это лишь будет означать, что ты выбираешь набор, в котором будет одна запись. Ну не может же быть, чтобы LIMIT 2 и LIMIT 1 возвращали в одном случае именно набор, а в другом — не набор. Кстати, даже LIMIT 1 отнюдь не гарантирует, что ты выберешь одну запись — ты можешь получить 0 записей, то есть пустой набор.
PD>Конечно, при наличии PK можно гарантировать выборку именно одной записи, но это все равно будет выборкой набора, в котором не может быть (из-за PK) больше одной. А ни одной все равно может.
Выбираем то мы набор, да только не везде набор состоящий не из одной строки не приведет к ошибке.
Взять к примеру подзапросы в фразе select
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Тоже не возражаю. Правда, ИМХО дело не в сахаре, а в том, что по реальным потребностям выполнить некую выборку или змену для всего набора имеет смысл часто, а вставляют все же чаще по одной. Жизнь такова
Жизнь она разная бывает. Не стоит так категорично
Кстати в большинстве OLTP update и delete (да и select тоже, что греха таить)
ТОЖЕ идут по одной записи
T>>Рантайм у меня был Хаскельный, я просто расставил в нужных местах аннотации par+pseq и запускал с разным количеством процессоров. Потратить 20 минут на ускорение в 20% — приемлемо, по-моему.
R>Ну я надеюсь, ты понимаешь, что вот так просто "на слабо" никто не будет садиться и реализовывать полноценную систему.
Причём здесь "на слабо"?
Вот тебе интересна какая-то тема. Её надо обязательно изучить. Любое теоретическое изучение будет неполным, поэтому надо изучить практически.
Значит, надо сделать систему.
Мне этот агентный подход совсем не нужен. Мне больше нравится dynamic dataflow, в котором состояние уже разбито, как надо, то есть так, чтобы никому лишнему ничего не мешало. С его помощью можно добиться практически теоретического потолка параллелизма.
R>Поэтому намекни просто, что же я должен увидеть после самостоятельной реализации. Вполне вероятно, что намёка будет достаточно. Так в чём же была причина плохой распараллеливаемости? Это именно агентный подход плох для распараллеливания задач симуляции или конкретная реализация? У меня подозрение, что конкретная реализация.
Я утверждаю, что необходимые для применения агентного подхода преобразования программ не проще, чем необходимые для, допустим, применения OpenMP. Читай, любого другого современного подхода.
R>По поводу 20% — смотря какую цель ставить. Само по себе 20% за 20 минут, конечно, не плохо. Но если задача, например, — создать среду для эфективного моделирования на современном многоядерном железе (сейчас — 2/4 ядра, завтра — 8) — то задача не решена. Если на 2 ядрах, у тебя 20%, это значит, что на 4 будет 30%, а на 8 — 35%, т.е. используем только 17% вычислительной мощности.
А если она не решается? Ась?
(вообще-то решается, конечно, но отнюдь не простым вставлением par и pseq. Преобразования будут потяжелее. И для разных типов систем — синхронные, асинхронные — разными, с разным результатом.)
T>>У меня, например, получается совершенно нетривиально. Например, необходимо выделять слабосвязанные подграфы и тщательно смотреть, не может ли кто послать некоторому подграфу лишнего или гарантировать низкую вероятность этой посылки. R>Так проблема была в низкой гранулярности?
Не "была", а "будет".
Это я рассуждал о будущей системе, которую я сейчас прикидываю.
R>По поводу автоматического увеличения гранулярности, пока ничего не могу сказать — это я просто на скорую руку рекомендовал человеку куда надо думать, что бы достить эффективного распараллеливания. Скорее всего я буду думать над этой задачей, но пока не могу ничего сказать. Гипотеза, что есть некоторые относительно простые эвристики, которые позволят автоматически добиваться близкой к оптимальной кластеризации.
Её, как и всё остальное, надо проверять.
Бремя доказательства лежит на высказавшем.
R>>>А во-вторых, сотня актёров хватит лет на 5 точно, а то и больше. Для серверного ПО это может быть более, чем приемлемо.
T>>Э-эх.
R>Не согласен? Если, например, имеется 4-ядерный сервер, или 2-процессорный х 4-ядерный, сотня агентов более чем хватит. Нет? А через 3 года при существенном увеличении нагрузки всё-равно большую часть переписывать.
Я про другое.
Ты сперва добейся независимой работы этой сотни агентов.
А то ты о самом сложном говоришь, как о решённой задаче.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Так если набор, почему же ты не согласен, что мы именно с набором и оперируем ?
Я не согласен с тем, что "там где-то внутри цикл".
В SQL циклов нет — есть именно что наборы. Есть операторы понижения мерности наборов — на вполне любую величину. Есть операторы повышения мерности.
Реальное ограничение теоретического SQL только одно — он оперирует предикатами первого порядка.
Но это же не размерность данных!
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
PD>Я тебе тоже объяснял, что дело вовсе не в реляционной алгебре.
Вот этот момент мне так и не понятен. PD>Да кто же спорит, Антон ? Я разве сказал, что не оперирует ? Я просто сказал, что оперирует и с отдельными записями.
Ты и споришь. Ты, по какой-то неясной мне причине, докопался до insert.
>>Павел, это что, так трудно — признать, что ошибся и пойти почитать книги/документацию? PD>Да нет, конечно, не трудно, но я никак не пойму, в какой ошибке ты меня упрекаешь ? В реляционной алгебре ? Я же объяснил, что не о ней речь.
В трактовке реляции как линейного массива и трактовке SQL как сокращенной записи цикла.
PD>По диагонали тоже ?
Если ты переформулируешь задачу от "шахматных" терминов к реальным, то окажется, что номер диагонали — это сумма row и column, и SQL вполне себе позволяет вот такой запрос:
select row+column as diagonal, sum(value) as diagonalSum from matrixData group by row+column
Невозможными в SQL являются совсем другие запросы.
PD>Именно к LinQ.
Хорошо. Тогда можно мне еще раз, медленно, объяснить, в чем проблема Linq?
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Я тебе тоже объяснял, что дело вовсе не в реляционной алгебре. S>Вот этот момент мне так и не понятен.
Да что же тут непонятного. Ладно, еще раз. Есть оператор языка, который работает с набором, но при этом не обращается к отдельным элементам. Как он там внутри работает — мне все равно, а поэтому реляционная алгебра тут ни при чем. В вымышленном мной языке для матриц он работал бы тоже с набором (двумерным), здесь — с одномерным. Но он работает с набором, с контейнером как со скаляром. Вот и все, что я хотел сказать.
PD>>Да кто же спорит, Антон ? Я разве сказал, что не оперирует ? Я просто сказал, что оперирует и с отдельными записями. S>Ты и споришь. Ты, по какой-то неясной мне причине, докопался до insert.
А вот insert работает с отдельным элементом. И тот факт, что insert может тоже работать с набором, этого не отменяет. Потому что если insert не будет вставлять наборы — будут проблемы. А вот если он не будет вставлять отдельные записи — не будет SQL вообще. Потому что чтобы вставить набор, надо его создать и вставить записи. Отдельные
Кстати, в SQL есть-таки работа с отдельными элементами не только для вставки. Я об этом просто забыл, а ты не напомнил, может потому, что в C# это не очень популярно, скажем так. Думаю, ты догадался, о чем речь идет. Курсоры. Типичный IEnumerable. Работает с отдельными записями набора.
>>>Павел, это что, так трудно — признать, что ошибся и пойти почитать книги/документацию? PD>>Да нет, конечно, не трудно, но я никак не пойму, в какой ошибке ты меня упрекаешь ? В реляционной алгебре ? Я же объяснил, что не о ней речь. S>В трактовке реляции как линейного массива и трактовке SQL как сокращенной записи цикла.
Да оставь ты этот массив в покое. Я уже десять раз объяснил, что не о массиве речь, а просто о массовой структуре. И не о цикле речь — тоже десять раз объяснял. А только о массовой структуре и массовых операциях, выполняемых с точки зрения синтаксиса языка как со скаляром.
PD>>По диагонали тоже ? S>Если ты переформулируешь задачу от "шахматных" терминов к реальным, то окажется, что номер диагонали — это сумма row и column, и SQL вполне себе позволяет вот такой запрос: S>
S>select row+column as diagonal, sum(value) as diagonalSum from matrixData group by row+column
S>
А что такое row и column ? И как ты обеспечишь, чтобы при этом все элементы диагонали были ? Если row и column — это поля, то вот нет в таблице записи со значениями 0,0. Есть 1,1; 2,2. 3,3 опять нет. 4,4 есть. И т.д. Это не по диагонали, а просто выборка элементов.
Если же речь идет о моем вымышленном языке, то там не реляционная алгебра вообще будет, а некий "матричный набор действий". Вырезать подматрицу. UNION двух матриц. Сложение и умножение их. И т.д. И вырезать диагональ даст вектор а не набор элементов у которых row+col == const.
PD>>Именно к LinQ. S>Хорошо. Тогда можно мне еще раз, медленно, объяснить, в чем проблема Linq?
В том. что он хорошо годится для тех ситуаций, когда имеет место последовательный перебор, и не очень — если перебор совсем не последовательный. Не случайно Андрею так сильно не понравилось мое предложение пройти матрицу по диагонали.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Так если набор, почему же ты не согласен, что мы именно с набором и оперируем ? S>Я не согласен с тем, что "там где-то внутри цикл".
Принимается. Корректирую свое высказывание — где-то там есть в большинстве случаев некая массовая операция (то есть операция хуже чем O(1)). Годится ?
Здравствуйте, Gluk_Kazan, Вы писали:
G_K>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Тоже не возражаю. Правда, ИМХО дело не в сахаре, а в том, что по реальным потребностям выполнить некую выборку или змену для всего набора имеет смысл часто, а вставляют все же чаще по одной. Жизнь такова
G_K>Жизнь она разная бывает. Не стоит так категорично
Нет, не согласен.
Выбрать можно хоть всю таблицу, заменить — тоже по всей, а вот вставлять в конечном счете придется все же по одной. Потому что для того, чтобы вставить набор, надо в него сначала вставить что-то, а если это что-то есть набор, то в него надо сначала ... и т.д., а в конце концов придется все же отдельные записи вставлять. Ну никак нельзя вставить одной командой записи обо мне и о тебе сразу
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>>Именно к LinQ. S>>Хорошо. Тогда можно мне еще раз, медленно, объяснить, в чем проблема Linq?
PD>В том. что он хорошо годится для тех ситуаций, когда имеет место последовательный перебор, и не очень — если перебор совсем не последовательный. Не случайно Андрею так сильно не понравилось мое предложение пройти матрицу по диагонали.
Если ты про тот топик, где тебе показывали решение для работы с матрицами через линк, то на твое предложение пройти по диагонали, тебе там же и объяснили, что источником данных служит IEnumerator, который как раз и задает порядок обхода изначальной структуры. При этом его в шарпе очень легко описать для обхода матрицы в любом порядке — хоть по строкам, хоть по столбцам, хоть по диагонали, хоть змейкой, хоть случайной выборкой...
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Да что же тут непонятного. Ладно, еще раз. Есть оператор языка, который работает с набором, но при этом не обращается к отдельным элементам. Как он там внутри работает — мне все равно, а поэтому реляционная алгебра тут ни при чем.
Как это ни при чем? Операторы как раз реализуют расширенную реляционную алгебру.
PD>В вымышленном мной языке для матриц он работал бы тоже с набором (двумерным), здесь — с одномерным. Но он работает с набором, с контейнером как со скаляром. Вот и все, что я хотел сказать.
Ок, понятно.
PD>А вот insert работает с отдельным элементом. И тот факт, что insert может тоже работать с набором, этого не отменяет. Потому что если insert не будет вставлять наборы — будут проблемы. А вот если он не будет вставлять отдельные записи — не будет SQL вообще. Потому что чтобы вставить набор, надо его создать и вставить записи. Отдельные
Нет. Не будет никаких проблем. Можно вставить сразу набор. Совершенно необязательно для этого вствлять "отдельные" записи.
Всё, что нужно — это иметь конструктор наборов. Точно так же, как С++ поддерживает константы определенных типов, SQL достаточно поддерживать описание констант типа "набор".
PD>Кстати, в SQL есть-таки работа с отдельными элементами не только для вставки. Я об этом просто забыл, а ты не напомнил, может потому, что в C# это не очень популярно, скажем так. Думаю, ты догадался, о чем речь идет. Курсоры. Типичный IEnumerable. Работает с отдельными записями набора.
Курсоры — это "тёмная сторона силы". Без них SQL продолжит корректно работать.
PD>Да оставь ты этот массив в покое. Я уже десять раз объяснил, что не о массиве речь, а просто о массовой структуре. И не о цикле речь — тоже десять раз объяснял. А только о массовой структуре и массовых операциях, выполняемых с точки зрения синтаксиса языка как со скаляром.
Совершенно верно. Есть массовые операции. И если хочется поговорить о проблемах SQL, то нужно это учитывать.
PD>А что такое row и column ?
Как что? Это компоненты составного ключа. PD>И как ты обеспечишь, чтобы при этом все элементы диагонали были ? Если row и column — это поля, то вот нет в таблице записи со значениями 0,0. Есть 1,1; 2,2. 3,3 опять нет. 4,4 есть. И т.д. Это не по диагонали, а просто выборка элементов.
Совершенно верно. Я уже говорил, что реляция — это набор фактов, т.е. кортежей. Факт — это точка в N-мерном пространстве.
Если в реляции нет записи с координатами (0, 0), то такого факта нет.
PD>Если же речь идет о моем вымышленном языке, то там не реляционная алгебра вообще будет, а некий "матричный набор действий". Вырезать подматрицу. UNION двух матриц. Сложение и умножение их. И т.д. И вырезать диагональ даст вектор а не набор элементов у которых row+col == const.
Вектор в SQL — это реляция с одномерным ключом. Поэтому вырезание диагонали — это ровно "набор элементов, у которых row+col == const". По определению.
Вырезание подматрицы, UNION двух матриц и прочие пожелания прекрасно выражаются операторами реляционной алгебры.
PD>В том. что он хорошо годится для тех ситуаций, когда имеет место последовательный перебор, и не очень — если перебор совсем не последовательный.
Это заблуждение.
PD>Не случайно Андрею так сильно не понравилось мое предложение пройти матрицу по диагонали.
Почему не понравилось? Тебе привели решения с перебором матрицы по диагонали. При желании можно хоть шахматным конем ее перебрать.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Pavel Dvorkin, Вы писали: PD>Выбрать можно хоть всю таблицу, заменить — тоже по всей, а вот вставлять в конечном счете придется все же по одной. Потому что для того, чтобы вставить набор, надо в него сначала вставить что-то, а если это что-то есть набор, то в него надо сначала ... и т.д., а в конце концов придется все же отдельные записи вставлять. Ну никак нельзя вставить одной командой записи обо мне и о тебе сразу
Можно, Павел, можно. Учим матчасть.
Вот тебе простой пример:
insert into People(name)
select "Павел"
union
select "Антон"
На всякий случай напомню, что здесь фигурирует три реляции. Две из них сконструированы при помощи специального синтаксиса оператора select, который возвращает "реляцию из одной записи", а третья — при помощи union первых двух.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Принимается. Корректирую свое высказывание — где-то там есть в большинстве случаев некая массовая операция (то есть операция хуже чем O(1)). Годится ?
Годится, но пользы от такого высказывания — o(0).
Потому, что
а) "в большинстве случаев" — утверждение крайне размытое. С тем же успехом его можно заменить на "иногда" или "может статься, что".
б) Не очень понятно, асимптотику от какого параметра мы сравниваем с O(1).
в) Не очень понятно, почему мы вообще критерием "массовости" операции мы ставим ее затратность. Затраты на операцию в SQL, вообще говоря, зависят далеко не только от ее аргументов.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Выбрать можно хоть всю таблицу, заменить — тоже по всей, а вот вставлять в конечном счете
Не согласен (c) Нельзя выбрать одну запись или таблицу
Можно выбрать набор из одной записи или всех записей таблицы
PD>придется все же по одной. Потому что для того, чтобы вставить набор, надо в него сначала вставить что-то, а если это что-то есть набор, то в него надо сначала ... и т.д., а в конце концов придется все же отдельные записи вставлять. Ну никак нельзя вставить одной командой записи обо мне и о тебе сразу
insert into test(id)
select rownum from dual
group by cube (1,1,1)
Здравствуйте, Sinclair, Вы писали:
S>Годится, но пользы от такого высказывания — o(0).
Ну нет
S>Потому, что S>а) "в большинстве случаев" — утверждение крайне размытое. С тем же успехом его можно заменить на "иногда" или "может статься, что".
Антон, ты прекрасно понимаешь, о чем я говорю. Естественно, SELECT count(*) from tbl не есть массовая операция. И другие есть. Но если запрашивается набор, то это массовая операция. И т.д.
S>б) Не очень понятно, асимптотику от какого параметра мы сравниваем с O(1).
Количество записей. Для простоты одну таблицу рассмотрим. Если линейный выбор — O(N), иначе O(log(N))
S>в) Не очень понятно, почему мы вообще критерием "массовости" операции мы ставим ее затратность.
А где это я про затратность в применении к SQL вообще говорил ?. Я тут вообще молчу — заменить LinQ конструкцию я могу, а SELECT чем я заменю ? Остается просто принимать как есть. Что тут обсуждать — разве что качество ее реализации в разных БД.
>Затраты на операцию в SQL, вообще говоря, зависят далеко не только от ее аргументов.
Спасибо за совет, мне такое действительтно не приходило в голову , но суть дела это мало изменяет. Посоветуй такой способ ввода данных в реальных формах
S>На всякий случай напомню, что здесь фигурирует три реляции. Две из них сконструированы при помощи специального синтаксиса оператора select, который возвращает "реляцию из одной записи", а третья — при помощи union первых двух.
Здравствуйте, Gluk_Kazan, Вы писали:
G_K>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Выбрать можно хоть всю таблицу, заменить — тоже по всей, а вот вставлять в конечном счете
G_K>Не согласен (c) Нельзя выбрать одну запись или таблицу G_K>Можно выбрать набор из одной записи или всех записей таблицы
Да, я же об этом и псал чуть раньше. Неточно выразился, сорри.
PD>>придется все же по одной. Потому что для того, чтобы вставить набор, надо в него сначала вставить что-то, а если это что-то есть набор, то в него надо сначала ... и т.д., а в конце концов придется все же отдельные записи вставлять. Ну никак нельзя вставить одной командой записи обо мне и о тебе сразу
G_K>insert into test(id) G_K>select rownum from dual G_K>group by cube (1,1,1)
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, Gluk_Kazan, Вы писали:
G_K>>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>>Выбрать можно хоть всю таблицу, заменить — тоже по всей, а вот вставлять в конечном счете
G_K>>Не согласен (c) Нельзя выбрать одну запись или таблицу G_K>>Можно выбрать набор из одной записи или всех записей таблицы
PD>Да, я же об этом и псал чуть раньше. Неточно выразился, сорри.
PD>>>придется все же по одной. Потому что для того, чтобы вставить набор, надо в него сначала вставить что-то, а если это что-то есть набор, то в него надо сначала ... и т.д., а в конце концов придется все же отдельные записи вставлять. Ну никак нельзя вставить одной командой записи обо мне и о тебе сразу
G_K>>insert into test(id) G_K>>select rownum from dual G_K>>group by cube (1,1,1)
PD>Ну не знаю. dual — это что ?
фиктивная табличка в Oracle. Когда нужно вернуть данные откуда угодно, но не из этой таблицы
В отличии от MSSQL в Oracle фраза from обязательна
Здравствуйте, Sinclair, Вы писали:
PD>>В вымышленном мной языке для матриц он работал бы тоже с набором (двумерным), здесь — с одномерным. Но он работает с набором, с контейнером как со скаляром. Вот и все, что я хотел сказать. S>Ок, понятно.
Ну слава богу
PD>>А вот insert работает с отдельным элементом. И тот факт, что insert может тоже работать с набором, этого не отменяет. Потому что если insert не будет вставлять наборы — будут проблемы. А вот если он не будет вставлять отдельные записи — не будет SQL вообще. Потому что чтобы вставить набор, надо его создать и вставить записи. Отдельные S>Нет. Не будет никаких проблем. Можно вставить сразу набор. Совершенно необязательно для этого вствлять "отдельные" записи. S>Всё, что нужно — это иметь конструктор наборов. Точно так же, как С++ поддерживает константы определенных типов, SQL достаточно поддерживать описание констант типа "набор".
Ладно, принято. я об этом уже писал.
PD>>Да оставь ты этот массив в покое. Я уже десять раз объяснил, что не о массиве речь, а просто о массовой структуре. И не о цикле речь — тоже десять раз объяснял. А только о массовой структуре и массовых операциях, выполняемых с точки зрения синтаксиса языка как со скаляром. S>Совершенно верно. Есть массовые операции. И если хочется поговорить о проблемах SQL, то нужно это учитывать.
Нет, о проблемах SQL я говорить не хочу. Не моя это тематика. Я в SQL только благодушный дилетант
PD>>И как ты обеспечишь, чтобы при этом все элементы диагонали были ? Если row и column — это поля, то вот нет в таблице записи со значениями 0,0. Есть 1,1; 2,2. 3,3 опять нет. 4,4 есть. И т.д. Это не по диагонали, а просто выборка элементов. S>Совершенно верно. Я уже говорил, что реляция — это набор фактов, т.е. кортежей. Факт — это точка в N-мерном пространстве. S>Если в реляции нет записи с координатами (0, 0), то такого факта нет.
А я тебе говорю отнюдь не про SQL и реляции. В общем, один про Фому, а другой про Ерему. Давай закроем эту часть.
S>Курсоры — это "тёмная сторона силы". Без них SQL продолжит корректно работать.
Но они есть. "Если звезды зажигают, значит, это кому-то нужно"
S>Вектор в SQL — это реляция с одномерным ключом. Поэтому вырезание диагонали — это ровно "набор элементов, у которых row+col == const". По определению. S>Вырезание подматрицы, UNION двух матриц и прочие пожелания прекрасно выражаются операторами реляционной алгебры.
Точно про Фому и Ерему
PD>>В том. что он хорошо годится для тех ситуаций, когда имеет место последовательный перебор, и не очень — если перебор совсем не последовательный. S>Это заблуждение.
PD>>Не случайно Андрею так сильно не понравилось мое предложение пройти матрицу по диагонали. S>Почему не понравилось?
Он это "кривым обходом" обозвал
>Тебе привели решения с перебором матрицы по диагонали. При желании можно хоть шахматным конем ее перебрать.
Здравствуйте, AndrewVK, Вы писали:
MC>>Напомню, что все началось с того, как remark провел параллель между sql и функциональными языками.
AVK>Что значит параллель? Оригинальный SQL, без императивных расширений, это и есть функциональный язык.
Декларативный он, да. Но не функциональный ни в одном месте.
Здравствуйте, fmiracle, Вы писали:
F>Чего ты хочешь? Такой инсерт, который пишется вручную, но при этом позволяет вставить сразу несколько записей? Сделать его не проблема, только в нем никакой пользы по сравнению с серией одиночных инсертов. Вот его и не добавили.
В MySQL есть.
INSERT INTO tab (col1,col2..) VALUES (val11,val12...),(val21,val22...),...
Хорошо, ты не согласен. Объясни, пожалуйста, возможно, я заблуждаюсь — почему ты считаешь "оригинальный SQL, без императивных расширений" функциональным?
Здравствуйте, lomeo, Вы писали:
L>Хорошо, ты не согласен. Объясни, пожалуйста, возможно, я заблуждаюсь — почему ты считаешь "оригинальный SQL, без императивных расширений" функциональным?
А почему нет? Функции как first class сущность есть, комбинировать с определенными ограничениями их можно. Что еще требуется?
... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>
Здравствуйте, AndrewVK, Вы писали:
FR>>Хаскелевская кстати тоже статическая и на ней тоже вполне проходят все фокусы C++ типа вычисления факториала в compile time.
AVK>Только оно при этом не выглядит как чес левой ногой за правым ухом.
Скорее, выглядит, чем нее выглядит
VladD2 как то говорил (если убрать его как обычно сочные выражения), что задача типизации вовсе не в вычислениях, он это обосновывал, если не ошибаюсь изначальными задачами, для которых конкретная типизация разрабатывалась. Частично с ним даже можно согласится
Так вот dependept type системы для этого разарабатывались. А Хаскелевская — нет, если мы не будем говорить о расширениях типа GADT, где тоже не всё гладко.
где Elifant говорит о том, что он воспроизвел Parsec на Nemerle. Погляди на реализацию. Макросами там и не пахнет. Только функциональные комбинаторы которые могут быть реализованы и на Шарпе. Менее красиво, более громоздко, но могут.
По ссылке не нашёл реализацию. Где можно посмотреть?
Ну и чуть чуть за Хаскель, куда без этого!.
Что касается удобства Хаскеля для написания комбинаторов (и создания собственных eDSL) — то оно, по моему, является следствием: лени, карринга/секций, ФВП и, конечно, же бесскобочного вызова функций. По мелочи ещё пользовательские операторы и возможность инфиксного вызова функции:
Вместо
assignments <- p_sep_by1(p_assignment, p_symbol(','))
будет
assignments <- p_assignment `sepBy1` p_symbol ','
На данном примере не очень хорошо видно, но для длинных выражений отсутствие скобок и инфиксный вызов спасают.
Но есть и недостатки, не позволяющие иногда реализовать тот DSL, который мне нужен (если мы не берём TH и QQ из последнего GHC).
С макросами (в Хаскеле или где ещё) всё это само-собой делается.
Здравствуйте, AndrewVK, Вы писали:
AVK>А почему нет? Функции как first class сущность есть, комбинировать с определенными ограничениями их можно. Что еще требуется?
Наверное, мне подкачать скилзы Я не знал, что в SQL есть first class functions. В инете сходу не нашёл, сам не знаю ни одного примера — не раз не пользовал в SQL FCF и не представляю как. Не подскажешь где почитать или кейвордов/примеров накидаешь?
Здравствуйте, VladD2, Вы писали:
VD>>>Вот ты явно пишешь на С++. Тебе знакомы Boost.Function, Boost: Function, Bind, Lambda? E>>Смотрел, но не использую. А как это связпно с темой?
VD>Тогда я даже не знаю как тебе можно это объяснить. Ведь если я сейчас начну говорить о разных функциях высшего порядка и прочей лабуде, ты ровным счетом ничего не поймешь.
А ты не о лабуде попробуй писать, а по делу. LISP я одно время использовал довольно много. Потом отказался от него в сторону своего языка. Тоже довольно мощного, в некотором смысле... VD>Попробуй прочесть о парадоксе блаба
. Может быть это подтолкнет тебя на изучение того, что ты пытаешся обсуждать не имея базы.
Ну и что это всё даёт, если очистить от шелухи? Что LISP программа может сама себя редактировать?
Ну у меня есть саморедактирующийся код, например. То есть в С++ программе есть данные и есть функции. И данные компи лируются в функции, которые потом исполняются. Конечно на LISP это сделать было бы проще, зато на асме работает быстрее... И что?
С другой стороны я при разработке на С++ широко использую генераторы кода. И тоже всё хорошо работает. И что?
И главное, какое отношение это всё имеет к функциональности? Сама суть ФЯ не в том, что на нём можно самомодифицируемый код писать, а в том, что алгорим выражается при помощи неизменных и неразделяемых данных и взаимосвязей между ними. Во всяком случае AFAIK.
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, VladD2, Вы писали:
VD>А ты это сказать не можешь. Потому что тебе сравнивать не с чем. Например, если ты всю жизнь ездил на совковых машинах (жугулях, скажем), то когда тебе скажут, что ездить практически на любой иномарке комфортнее и легче, то ты с большой вероятностью ответишь, что тебе и так хорош. Доказать тебе будет ничего не возможно, если конечно ты сам не попробуешь альтернативу.
Ну тут уже кто-то справедливо замечал, что машина с 100 л. с. позволяет ездить комфортно и прекрасно. А как только пересядешь на 200 л. с., сразу понимаешь, что и 200 -- это очень мало
Это кстати очень показательная история. Просто когда ты ездишь на тачке 100 л. с. -- то твоя цель доехать, а как только пересаживаешься на 200+ -- то твоя цель меняется. Теперь тебе важно не доехать, а круто покататься. И в С++ и в современных, можных языках такой эффект тоже присутсвует. Одним хочется решить задачу, скажем разработать систему управления С-300. А другим хочется решать задачу максимально прикольным способом. Если в целом пользя от деятельности состоит в решении задач, а не в самом процессе решения, то первые обычно эффективнее.
VD>Вообще, я тебе гарантирую, что если ты не перейдешь в стадию Дворкина, то тебе через некоторое время будет очень стыдно за свои слова. Так что мой тебе совет, чем спорить о вкусе устриц с теми кто их пробовал, возьми и попробуй их сам. Уверяю тебя, что даже в С++ ты еще не знаешь огого как много. А уж если выйти за рамки этой песочницы, то тебе откроется огромный мир. Намного более интересный.
1) Не надо всё время оскорблять коллег. Дворкин конкретно в этом щамечании не при чём. Зачем ты его мокаешь?
2) Я думаю, что твои гарантии ничего не стоит, так как стыдно мне не будет. Я знаю, что я говорю. Интересный мир мне уже давно открылся. Много лет назад, когда я понял, что прототип сложной ИИ проги удобно писать на PROLOG. Но для коммерческой разработки на PROLOG можно написать только прототип, к сожалению. Просто потому, что проблемы при разработке совсем не там возникают, где их помогает решать PROLOG. А ещё более интересный и прекрасный мир открылся мне, когда я осознал сколько миллионов людей с радостью пользуются результатами моего труда. И это, IMHO, намного важнее той радости, которую кому-то доставляет кодирование на любом языке...
Мало того, я и сейчас использую и декларативные и функциональные языки. И даже отчасти их разарбатываю. Не такие продивнутые и общего назначения, как известные тебе, но зато вполне хорошо заточенные под свои задачи. Но в конце концов всех этих штук стоит исполнение на компе, и С/С++ предоставляет очень удобную абстракцию исполнительной среды компа. В терминах С++ удобно думать о том, как компьютер исполняет мою программу...
Особенно, если трудности кодирования несущественны по сравнению со сложностью разработки алгоритмов...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, VladD2, Вы писали:
VD>...Скажем если строить автомат для грамматики с большим количеством распознаваемых идентификаторов, то производительность очень быстро упрется в скорость доступа к памяти, так как и таблицы и функция со свитчем будут иметь огромные размеры (вылетающие за пределы кэша). Так что с точки производительности выгоднее опять таки решить проблему алгоритмически. Написать одно граматическое правило которое распознает идетификатор (скажем [a-zA-z][a-zA-z0-9]+), а конкретные ключевые слова проверять по хэш-таблицы. Но такие оптимизации — это уже эвристики, которые автоматически (алгоритмически) не делаются.
по идее всё должно быстро сийтись к битовой строке на каждую букву алфавита, и оптимизировать можно эти строки.
Ну а можно, конечно, расширить язык регэкспов термом "слово из словаря", правда не так эффективно будет недетерминированность КА отрабатываться, зато в словаре может быть реально много слов. Например весь русский язык...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Sinclair, Вы писали:
S>На досуге поинтересуйся судьбой ключевого слова register в C++, который ты тут всуе поминаешь. S>И попробуй проэкстраполировать эту судьбу на другие "дыры, сквозь которые видна аппаратура"
Ну какие-то задачи удаётся автоматизировать. Но сильно не все.
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, AndrewVK, Вы писали:
E>>Обычно он очень дырявый оказывается. Вообще всё так странно устроено, что для эффективной работы часто требуются дыры в слое абстракций. С и С++ скорее всего так популярны именно из-за дырявости своих обстракций. Свозь эти дыры всюду хорошо и близко доступна аппаратура. AVK>Не уловил мысль
Ну C++ можно воспринимать как некую виртуальную машину высокго уровня. Можно, например, написать интерпретатор С++, который проверяет корректность всех указателей и т. п., но на практике частенько бывает нужно воспользоваться какими-то особенностями реализации, для решения практических задач...
E>>Обрати, кстати, внимание, что слой абстракций "куды" тоже довольно таки дырявый... AVK>Следствие убогости куды и недостаточного развития инструментальных средств. Здесь главное понимать — это проблема, которую надо решать, а не оставлять все как есть, заставляя прикладников вникать в тонкости организации внутренних конвееров конкретной железки.
Ну понятно, что хочется чтобы программировать "КУДУ" было бы проще. Но пока что такая вот "дырявая абстракция" позволяет добиться намного лучших результатов...
Хороший пример -- FORTRAN, который умел правильно написанную программу компилить и на крэй и на х86. Но при этом тебе всё равно надо было писать такие алгоритмы, которые ложатся на архитектуру...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Было мне 20 с чем-то лет. И вот на машине с памятью 32 КСлова (слово — 48 бит) надо было...
В названии магинки число "6" часом не присутствовало?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
E>Ну C++ можно воспринимать как некую виртуальную машину высокго уровня.
Можно. Но разве от этого что то изменится?
E> Можно, например, написать интерпретатор С++, который проверяет корректность всех указателей и т. п.
Нельзя, семантика С++ не позволяет. Чтобы позволяла нужен safe код.
E>Ну понятно, что хочется чтобы программировать "КУДУ" было бы проще.
Ну вот поэтому и существуют такие технологии как linq. Да да, еще один слой абстракций.
E> Но пока что такая вот "дырявая абстракция" позволяет добиться намного лучших результатов...
Пока куда ничего кроме демок не позволяет особо. Сырая еще очень технология.
E>Хороший пример -- FORTRAN, который умел правильно написанную программу компилить и на крэй и на х86.
Хороший. Потому что FORTRAN намного абстрактнее С++, и, как следствие, позволяет намного больше оптимизатору.
E> Но при этом тебе всё равно надо было писать такие алгоритмы, которые ложатся на архитектуру...
Потому что уровень абстракций недостаточен . Вот для SQL уже не надо учитывать архитектуру платформы.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>
Не обязательно вложенный. Есть еще операции над отношениями (union/except/intersect), CTE и т.п.
L> Ладно, я понял твою мысль, спасибо за разъяснения. В общем, тут огромное поле для дискуссии, но мне кажется, она будет бесполезной, нес па?
Будет, если спорить о терминологии. А по сути SQL вполне себе специализированный ФП, хотя и сильно отличающийся от ML-семейства.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>
Здравствуйте, AndrewVK, Вы писали:
E>>Хороший пример -- FORTRAN, который умел правильно написанную программу компилить и на крэй и на х86. AVK>Хороший. Потому что FORTRAN намного абстрактнее С++, и, как следствие, позволяет намного больше оптимизатору.
????
Фортран — он самый неабстрактный язык, который только можно придумать (ну разве что Brainf**k неабстрактнее). Оптимизатору там простор из-за того, что сам язык очень ограничен, и ты вынужден строить программ из оптимизаторно-дружественных примитивов.
Здравствуйте, AndrewVK, Вы писали:
E>>Ну C++ можно воспринимать как некую виртуальную машину высокго уровня. AVK>Можно. Но разве от этого что то изменится?
Если ты хочешь понять, что я имел в виду, то я пояснил очень подробно.
А если ты хочешь спорить -- то спорь по существу, а не с примерами и объяснениями...
На "КУДЕ" есть очень даже прикольные проги. Просто по маркетинговым соображениям с ней лучше не связываться
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Cyberax, Вы писали:
C>Фортран — он самый неабстрактный язык, который только можно придумать
Да? А как нибудь обосновать?
C> Оптимизатору там простор из-за того, что сам язык очень ограничен, и ты вынужден строить программ из оптимизаторно-дружественных примитивов.
Это и есть высокая степень абстракции.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>
Здравствуйте, AndrewVK, Вы писали:
E>>Ну какие-то задачи удаётся автоматизировать. Но сильно не все. AVK>И какой из этого вывод?
Вывод такой, что опыт популярности С/С++ учит нас тому, что "дырявость" абстракций сильно востребованна, именно из-за того, что проще приспосабливаться к аппаратуре и получить лучшие результаты за меньшие деньги...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, AndrewVK, Вы писали:
E>> Можно, например, написать интерпретатор С++, который проверяет корректность всех указателей и т. п.
AVK>Нельзя, семантика С++ не позволяет. Чтобы позволяла нужен safe код.
Можно, можно. Он и будет safe в таком интерпретаторе.
Здравствуйте, Erop, Вы писали:
E>Если ты хочешь понять, что я имел в виду, то я пояснил очень подробно.
Не знаю я, что ты там подробно объяснил, но я таки не смог понять, как твоя фраза поясняет, как можно прикладному программисту использовать FPGA без промежуточных слоев абстракций. На всякий случай — FPGA отстоит от С++ по уровню абстракций очень намного дальше, нежели C# от куды. Внутри даже довольно высокоуровневых ксайлинксов там набор универсальных логических блоков с программируемой таблицей истинности, набор универсальных гейтов, завязанных на ноги микросхемы, и программируемая матрица межсоединений. И фсе.
E>А если ты хочешь спорить -- то спорь по существу, а не с примерами и объяснениями...
Я? С тобой? Ты ничего не перепутал? Это ты мне в этой ветке вопрсы начал задавать.
E>На "КУДЕ" есть очень даже прикольные проги.
Да ради бога, я ж не против. Я против того, чтобы писать продакшн софт под эту куду прямо в родных кудовых кодах.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>
Здравствуйте, Erop, Вы писали:
E>>>Ну какие-то задачи удаётся автоматизировать. Но сильно не все. AVK>>И какой из этого вывод?
E>Вывод такой, что опыт популярности С/С++ учит нас тому, что "дырявость" абстракций сильно востребованна
Ошибка в логике. "А одновременно с Б" не означает "из А следует Б".
E>, именно из-за того, что проще приспосабливаться к аппаратуре и получить лучшие результаты за меньшие деньги...
За меньшие деньги это точно не про С++.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>
Здравствуйте, AndrewVK, Вы писали:
C>>Фортран — он самый неабстрактный язык, который только можно придумать AVK>Да? А как нибудь обосновать?
А ты на нём писал?
C>> Оптимизатору там простор из-за того, что сам язык очень ограничен, и ты вынужден строить программ из оптимизаторно-дружественных примитивов. AVK>Это и есть высокая степень абстракции.
Нет. Это высокая степень ограниченности. Скажем, в Фортране-77 запрещена рекурсия, невозможен алиасинг, массивы переменной длины и т.п. Так что оптимизатору из-за этого очень просто работать.
Из "высокой степенни абстракции" там только встроенные настоящие многомерные массивы.
Здравствуйте, AndrewVK, Вы писали:
M>>Можно, можно. Он и будет safe в таком интерпретаторе.
AVK>Safe он будет, только если зарезать мегафичи навроде реинтерпретации памяти или голых указателей.
Отнюдь. Это его верифицировать нельзя будет, если использовать касты. А в интерпретаторе на каждое слово в "памяти" можно держать свой дескриптор, и все unsafe операции проверять на валидность в рантайме.
Здравствуйте, AndrewVK, Вы писали:
E>>Если ты хочешь понять, что я имел в виду, то я пояснил очень подробно.
AVK>Не знаю я, что ты там подробно объяснил, но я таки не смог понять, как твоя фраза поясняет, как можно прикладному программисту использовать FPGA без промежуточных слоев абстракций.
Так не в наличии промежуточных уровней абстракции дело, а в невозможности их перепрыгнуть, в отсутствии в них "дырок".
Если у тебя есть JVM — то ты её перепрыгнуть не можешь. Если есть .NET — то можешь, написав unsafe код.
Если у тебя есть FPGA — не надо писать программы в терминах вентилей, надо только из программы иметь возможность перенастроить эти вентили.
Да, это будет делать промежуточный слой абстракции. Но написанный (или модифицированный) специально под твою программу — будет предоставлять все возможности необходимые твоей программе. И фсё.
Здравствуйте, Cyberax, Вы писали:
AVK>>Да? А как нибудь обосновать? C>А ты на нём писал?
Приходилось.
AVK>>Это и есть высокая степень абстракции. C>Нет. Это высокая степень ограниченности.
Это связанные понятия. Ограничения сами по себе бессмысленны. А вот если они вкупе с абстракциями, тогда и получается самое оно.
C> Скажем, в Фортране-77 запрещена рекурсия, невозможен алиасинг, массивы переменной длины и т.п. Так что оптимизатору из-за этого очень просто работать.
При этом, заметь, самому компилятору никто не мешает использовать в генерируемом коде эти вещи.
C>Из "высокой степенни абстракции" там только встроенные настоящие многомерные массивы.
Abstraction is the process or result of generalization by reducing the information content of a concept or an observable phenomenon, typically in order to retain only information which is relevant for a particular purpose.
Здравствуйте, mkizub, Вы писали:
M>Отнюдь. Это его верифицировать нельзя будет, если использовать касты
safe это оно и есть.
M>. А в интерпретаторе на каждое слово в "памяти" можно держать свой дескриптор, и все unsafe операции проверять на валидность в рантайме.
Только все равно нет никакой гарантии, что при любом, сколь угодно большом количестве прогонов без проблем втоя программа доказанно корректна.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>
Здравствуйте, mkizub, Вы писали:
M>Так не в наличии промежуточных уровней абстракции дело, а в невозможности их перепрыгнуть, в отсутствии в них "дырок".
То есть в асбтракции самой по себе уже ничего плохого нет? Уже хорошо. Ну а вместо наличия дырок нормальные люди делают абстракции расширяемыми. Начиная с примитивных решений навроде intrinsic функция и заканчивая теми же макросами Немерле или механикой linq в шарпе.
M>Если у тебя есть JVM — то ты её перепрыгнуть не можешь.
Могу. Воспользовавшись JNI.
M>Если у тебя есть FPGA — не надо писать программы в терминах вентилей, надо только из программы иметь возможность перенастроить эти вентили.
Нет, нужна возможность добавить в компилятор FPGA возможность расширения. Прямое управление через все слои абстракции это бееее.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Не знаю я, что ты там подробно объяснил, но я таки не смог понять,
Ну не смог и не смог, бывает.
AVK>как твоя фраза поясняет, как можно прикладному программисту использовать FPGA без промежуточных слоев абстракций. На всякий случай — FPGA отстоит от С++ по уровню абстракций очень намного дальше, нежели C# от куды. Внутри даже довольно высокоуровневых ксайлинксов там набор универсальных логических блоков с программируемой таблицей истинности, набор универсальных гейтов, завязанных на ноги микросхемы, и программируемая матрица межсоединений. И фсе.
И что? У тебя должен быть какой-то инструмент разработки под FPGA. Так вот, я сильно предполагаю, что если этот инструмент будет "дырявым" и позволит завинтить код так, чтобы учесть особенности конкртеного FPGA, то в целом получится лучше...
А если он не будет дырявым, то будет удобно доработать напильником под конкретно твои задачи.
E>>На "КУДЕ" есть очень даже прикольные проги. AVK>Да ради бога, я ж не против. Я против того, чтобы писать продакшн софт под эту куду прямо в родных кудовых кодах.
Не совсем понимаю, что ты имеешь в виду. Например, если ты пишешь какой-то числодробительный алгоритм, и явно используешь особенности архитектуры конкретной карточки. Например, различаешь доступ через память текстур и доступ через обычный канал -- это "в КУДОвых кодах" или нет?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, AndrewVK, Вы писали:
AVK>Только все равно нет никакой гарантии, что при любом, сколь угодно большом количестве прогонов без проблем втоя программа доказанно корректна.
Так цель-то не в этом...
Кроме того указатели могут быть устроены как-то так, что память вообще фиг испортишь. Скажем неинициализированные и приведённые из мусора всегда приводят к UB, а на каждую аллокацию свой уникальный сегмент...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[22]: Ну ты же не оспариваешь популярности С/С++? :)
Здравствуйте, AndrewVK, Вы писали:
E>>Вывод такой, что опыт популярности С/С++ учит нас тому, что "дырявость" абстракций сильно востребованна AVK>Ошибка в логике. "А одновременно с Б" не означает "из А следует Б".
Это у тебя ошибка в логике. Я считаю, что нас учит именно опыт, а не факт какой-то там одновременности. "Дырявость" С++ явно востребованна. Вот есть Ада, например, где с дырявостью осознанно поборолись. И что и где? Неудобно получается
E>>, именно из-за того, что проще приспосабливаться к аппаратуре и получить лучшие результаты за меньшие деньги... AVK>За меньшие деньги это точно не про С++.
За меньшие деньги за аппаратуру, так скажем...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
E>И что? У тебя должен быть какой-то инструмент разработки под FPGA. Так вот, я сильно предполагаю, что если этот инструмент будет "дырявым" и позволит завинтить код так, чтобы учесть особенности конкртеного FPGA, то в целом получится лучше...
И на чем основаны такие предположения?
AVK>>Да ради бога, я ж не против. Я против того, чтобы писать продакшн софт под эту куду прямо в родных кудовых кодах.
E>Не совсем понимаю, что ты имеешь в виду.
Я имею в виду, что если использование мегатехнологии Х не будет завернуто в удобные абстракции, рыночного успеха у нее скорее всего не будет.
E> Например, если ты пишешь какой-то числодробительный алгоритм, и явно используешь особенности архитектуры конкретной карточки. Например, различаешь доступ через память текстур и доступ через обычный канал -- это "в КУДОвых кодах" или нет?
В них. Поэтому, скажем, для шейдеров придуман универсальных язык.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>
Здравствуйте, Erop, Вы писали:
AVK>>Только все равно нет никакой гарантии, что при любом, сколь угодно большом количестве прогонов без проблем втоя программа доказанно корректна.
E>Так цель-то не в этом...
А в чем?
E>Кроме того указатели могут быть устроены как-то так, что память вообще фиг испортишь.
Вот это "как то так" и приведет в итоге к статически верифицируемому коду.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>
Здравствуйте, Erop, Вы писали:
E>>>Вывод такой, что опыт популярности С/С++ учит нас тому, что "дырявость" абстракций сильно востребованна AVK>>Ошибка в логике. "А одновременно с Б" не означает "из А следует Б". E>Это у тебя ошибка в логике.
Ясно, вопросов больше не имею.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>
Здравствуйте, AndrewVK, Вы писали:
AVK>И на чем основаны такие предположения?
Наа опыте использования очень дырявых абстракций и не очень
AVK>Я имею в виду, что если использование мегатехнологии Х не будет завернуто в удобные абстракции, рыночного успеха у нее скорее всего не будет.
Аргументы? В том числе и на примере С/С++ vs Ада
AVK>В них. Поэтому, скажем, для шейдеров придуман универсальных язык.
Ну, наверное, по этой пирчине дайректиксовые вычислительные шейдеры сливают "куде" по производительности
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, AndrewVK, Вы писали:
AVK>Вот это "как то так" и приведет в итоге к статически верифицируемому коду.
Дык о том-то и речь, что С++ спроектирова так, что нифига не изолирует тебя от аппаратуры. Абастракция-то дырявая!
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[24]: Ну ты же не оспариваешь популярности С/С++? :)
Здравствуйте, AndrewVK, Вы писали:
AVK>Ясно, вопросов больше не имею.
То, что ты разрешил наконец свои вопросы -- это, IMHO, хорошо. А вот то, что ты пропустил информативную часть моего сообщения -- не очень
Ну да если тебе наконец стало понятно, то и ладно
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, AndrewVK, Вы писали:
E>> Можно, например, написать интерпретатор С++, который проверяет корректность всех указателей и т. п.
AVK>Нельзя, семантика С++ не позволяет. Чтобы позволяла нужен safe код.
Не надо писать никаких интерпретаторов и не нужен никакой safe код. Надо просто взять Bounds Checker , инструментировать программу и запустить. Он прекрасно справлялся с этой задачей (говорю в прошлом времени потому что , увы, как утверждают, нынешние версии хуже).
E>>Хороший пример -- FORTRAN, который умел правильно написанную программу компилить и на крэй и на х86.
AVK>Хороший. Потому что FORTRAN намного абстрактнее С++, и, как следствие, позволяет намного больше оптимизатору.
А С он тоже намного абстрактнее ?
E>> Но при этом тебе всё равно надо было писать такие алгоритмы, которые ложатся на архитектуру...
AVK>Потому что уровень абстракций недостаточен . Вот для SQL уже не надо учитывать архитектуру платформы.
Здравствуйте, Cyberax, Вы писали:
C>>> Оптимизатору там простор из-за того, что сам язык очень ограничен, и ты вынужден строить программ из оптимизаторно-дружественных примитивов. AVK>>Это и есть высокая степень абстракции. C>Нет. Это высокая степень ограниченности. Скажем, в Фортране-77 запрещена рекурсия
Реально разрешена была в тех компиляторах, которыми я пользовался.
> невозможен алиасинг
А это что такое ? EQUIVALENCE куда девал ? Или ты о другом ?
>массивы переменной длины
Ввели в Фортран-90. ИМХО довольно криво.
C>Из "высокой степенни абстракции" там только встроенные настоящие многомерные массивы.
Здравствуйте, thesz, Вы писали:
T>>>Рантайм у меня был Хаскельный, я просто расставил в нужных местах аннотации par+pseq и запускал с разным количеством процессоров. Потратить 20 минут на ускорение в 20% — приемлемо, по-моему.
R>>Ну я надеюсь, ты понимаешь, что вот так просто "на слабо" никто не будет садиться и реализовывать полноценную систему.
T>Причём здесь "на слабо"?
T>Вот тебе интересна какая-то тема. Её надо обязательно изучить. Любое теоретическое изучение будет неполным, поэтому надо изучить практически.
T>Значит, надо сделать систему.
Ну почему же сразу обязательно. Во-первых, я интересуюсь таким кол-вом вещей, что на всё делать по полномасштабной системе — это мне надо будет по 48 часов свободного времени в сутки. Приходится искать какие-то разумные компромиссы, что-то я пробую практически, что-то — нет. Во-вторых, с опытом и знаниями приходит т.н. "техническая интуиция", это когда даже не пробуя технологию практически можешь предвидеть, где у неё будут сильные стороны, где слабые, откуда ждать подвохов и т.д.
Симуляцию на агентном подходе я не пробовал, но 2 самых критичных места я подозреваю — я их указывал. И я не говорил, что сделанная с наскоку симуляция на агентном подходе будет прекрасно масштабироваться, я как раз уверен в обратном — поэтому писать целиковую систему, что бы увидеть, что она действительно не будет масштабироваться мне мало смысла...
T>Мне этот агентный подход совсем не нужен. Мне больше нравится dynamic dataflow, в котором состояние уже разбито, как надо, то есть так, чтобы никому лишнему ничего не мешало. С его помощью можно добиться практически теоретического потолка параллелизма.
А можешь дать какие-то ссылки на "dynamic dataflow".
Исходя из того, что я нашёл (хотя я не уверен, что нашёл именно то, что ты имеешь в виду), это фактически тот же агентный подход — имеем фифо-очереди, имеем агентов. Как я понял отличие в том, что агенты — примитивные, т.е. выполняют очень простые операции (хотя это и не было там явно указано).
Если это так, то сильно напоминает COSA: http://pages.sbcglobal.net/louis.savain/Cosas/COSA.htm
Правда COSA — синхронная и детерминированная, а из-за этих свойств там достаточно сложно добиться эффективной реализации — автор как-то очень уклончиво говорит о реализации...
R>>Поэтому намекни просто, что же я должен увидеть после самостоятельной реализации. Вполне вероятно, что намёка будет достаточно. Так в чём же была причина плохой распараллеливаемости? Это именно агентный подход плох для распараллеливания задач симуляции или конкретная реализация? У меня подозрение, что конкретная реализация.
T>Я утверждаю, что необходимые для применения агентного подхода преобразования программ не проще, чем необходимые для, допустим, применения OpenMP. Читай, любого другого современного подхода.
Что ты имеешь в виду под преобразованиями? Для OpenMP в общем случае не нужны никакие преобразования (хотя анализ нужен). Для агентного — это зависит. Если гранулярность обработчиков сообщений достаточна, то особо ничего делать и не надо; если недостаточна, то один вариант — действительно делать какие-то преобразования программы (возможно — тривиальные, возможно — нет), второй вариант — всё же попытаться наделить ран-тайм достаточным интеллектом.
R>>По поводу 20% — смотря какую цель ставить. Само по себе 20% за 20 минут, конечно, не плохо. Но если задача, например, — создать среду для эфективного моделирования на современном многоядерном железе (сейчас — 2/4 ядра, завтра — 8) — то задача не решена. Если на 2 ядрах, у тебя 20%, это значит, что на 4 будет 30%, а на 8 — 35%, т.е. используем только 17% вычислительной мощности.
T>А если она не решается? Ась?
То что? По-моему — ничего, просто не очень хороший контекст для разговора о распараллеливании.
Гораздо более интересно если всё же решается, то тут видно, что одни подходы решают её, другие — нет.
Или ты имеешь в виду, что теоретический максимум это и есть те самые 20% и наша задача как выжать их? Ну тогда тут надо заниматься такими вещами как ограничивать кол-во рабочих потоков числом 2, иначе мы в лучшем случае будем тратить процессорное время впустую, а в худшем производительность будет деградировать. Далее детектировать топологию системы и привязать эти два потока к ближайшим ядрам желательно разделяющим кэш (но ни в коем случае ни к двум аппаратным потокам внутри одного ядра, и ни в коем случае не к двум процессорам, находящимся на разных NUMA узлах).
Кстати, хороший вопрос — какие из упоминавшихся систем (Haskell, Erlang) это могут?
T>(вообще-то решается, конечно, но отнюдь не простым вставлением par и pseq. Преобразования будут потяжелее. И для разных типов систем — синхронные, асинхронные — разными, с разным результатом.)
T>>>У меня, например, получается совершенно нетривиально. Например, необходимо выделять слабосвязанные подграфы и тщательно смотреть, не может ли кто послать некоторому подграфу лишнего или гарантировать низкую вероятность этой посылки. R>>Так проблема была в низкой гранулярности?
T>Не "была", а "будет".
T>Это я рассуждал о будущей системе, которую я сейчас прикидываю.
Ты это хочешь перекладывать на конечного программиста? Или этот анализ будет делать ран-тайм?
R>>По поводу автоматического увеличения гранулярности, пока ничего не могу сказать — это я просто на скорую руку рекомендовал человеку куда надо думать, что бы достить эффективного распараллеливания. Скорее всего я буду думать над этой задачей, но пока не могу ничего сказать. Гипотеза, что есть некоторые относительно простые эвристики, которые позволят автоматически добиваться близкой к оптимальной кластеризации.
T>Её, как и всё остальное, надо проверять.
T>Бремя доказательства лежит на высказавшем.
Её надо не только проверять, для начала надо придумать алгоритм, как это можно делать...
R>>>>А во-вторых, сотня актёров хватит лет на 5 точно, а то и больше. Для серверного ПО это может быть более, чем приемлемо.
T>>>Э-эх.
R>>Не согласен? Если, например, имеется 4-ядерный сервер, или 2-процессорный х 4-ядерный, сотня агентов более чем хватит. Нет? А через 3 года при существенном увеличении нагрузки всё-равно большую часть переписывать.
T>Я про другое.
T>Ты сперва добейся независимой работы этой сотни агентов.
T>А то ты о самом сложном говоришь, как о решённой задаче.
Не понял. Работа разных агентов по определению независима. Что ты имеешь в виду?
PD>>Было мне 20 с чем-то лет. И вот на машине с памятью 32 КСлова (слово — 48 бит) надо было...
E>В названии магинки число "6" часом не присутствовало?
БЭСМ-6. Но точно не из-за этого. Хотя... До этого была БЭСМ-4, а вот БЭСМ-5, насколько я знаю, не было.
Здравствуйте, AndrewVK, Вы писали:
AVK>Только все равно нет никакой гарантии, что при любом, сколь угодно большом количестве прогонов без проблем втоя программа доказанно корректна.
Не подменяй понятий. Речь шла о том, что это можно сделать, а не о том, что можно доказать корректность этой программы.
Здравствуйте, AndrewVK, Вы писали:
M>>Так не в наличии промежуточных уровней абстракции дело, а в невозможности их перепрыгнуть, в отсутствии в них "дырок".
AVK>То есть в асбтракции самой по себе уже ничего плохого нет? Уже хорошо.
Не прошло и года, как до тебя это дошло.
AVK>Ну а вместо наличия дырок нормальные люди делают абстракции расширяемыми. Начиная с примитивных решений навроде intrinsic функция и заканчивая теми же макросами Немерле или механикой linq в шарпе.
intrinsic — это не расширение. Ну, я подожду, пока до тебя и это дойдёт.
M>>Если у тебя есть JVM — то ты её перепрыгнуть не можешь.
AVK>Могу. Воспользовавшись JNI.
Далеко не всегда. Если речь идёт о том, чтоб иметь возможность сделать нечто "в принципе" — то можешь.
Если речь идёт о дырке нужной для оптимизации кода — то JNI тебе здесь не помошник.
M>>Если у тебя есть FPGA — не надо писать программы в терминах вентилей, надо только из программы иметь возможность перенастроить эти вентили.
AVK>Нет, нужна возможность добавить в компилятор FPGA возможность расширения. Прямое управление через все слои абстракции это бееее.
Вот чтоб была возможность добавить расширение в компилятор FPGA — тебе и нужна возможность управления через все слои абстракции.
Никак иначе это сделать нельзя.
Здравствуйте, AndrewVK, Вы писали:
AVK>И в этом основная проблема С++
Ну а я считаю, что кроме того, что это основная проблеме С++, это ещё и основное его достоинство
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>БЭСМ-6. Но точно не из-за этого. Хотя... До этого была БЭСМ-4, а вот БЭСМ-5, насколько я знаю, не было.
Упс, а я именно на эту пашинку и намекал. А про то, что там ещё и аллюзия на размер тамошнего слова получилась не подумал
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Pavel Dvorkin, Вы писали: PD>Спасибо за совет, мне такое действительтно не приходило в голову , но суть дела это мало изменяет. Посоветуй такой способ ввода данных в реальных формах
При чём здесь формы? Мы говорим о языке программирования, а не UI.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
T>>Мне этот агентный подход совсем не нужен. Мне больше нравится dynamic dataflow, в котором состояние уже разбито, как надо, то есть так, чтобы никому лишнему ничего не мешало. С его помощью можно добиться практически теоретического потолка параллелизма.
R>А можешь дать какие-то ссылки на "dynamic dataflow".
Можно начать с английской Wikipedia.
R>Исходя из того, что я нашёл (хотя я не уверен, что нашёл именно то, что ты имеешь в виду), это фактически тот же агентный подход — имеем фифо-очереди, имеем агентов. Как я понял отличие в том, что агенты — примитивные, т.е. выполняют очень простые операции (хотя это и не было там явно указано). R>Если это так, то сильно напоминает COSA: R>http://pages.sbcglobal.net/louis.savain/Cosas/COSA.htm R>Правда COSA — синхронная и детерминированная, а из-за этих свойств там достаточно сложно добиться эффективной реализации — автор как-то очень уклончиво говорит о реализации...
Нет, это не так.
FIFO очередей нет, агентов тоже нет. Вся информация для выполнения "узла" (отдельного элемента пространства вычислений программы) содержится в отправленной узлу информации. Для изменения знака числа нужно всего лишь это число, для сложения/умножения/деления — левый и правый операнды.
Программа узла настолько примитивна (одна-две полезных операции), что даже говорить об агентном подходе вообще нельзя. И состояния нет.
Вместо FIFO очередей используется так называемая ассоциативная память, позволяющая выделять готовые к выполнению узлы из десятков и даже сотен тысяч ожидающих.
T>>Я утверждаю, что необходимые для применения агентного подхода преобразования программ не проще, чем необходимые для, допустим, применения OpenMP. Читай, любого другого современного подхода. R>Что ты имеешь в виду под преобразованиями? Для OpenMP в общем случае не нужны никакие преобразования (хотя анализ нужен).
Приватизация, например.
Я же изучал преобразования, необходимые для работы с OpenMP.
R> Для агентного — это зависит. Если гранулярность обработчиков сообщений достаточна, то особо ничего делать и не надо; если недостаточна, то один вариант — действительно делать какие-то преобразования программы (возможно — тривиальные, возможно — нет), второй вариант — всё же попытаться наделить ран-тайм достаточным интеллектом.
Ты сперва преобразуй программу побольше в агентный вариант исполнения.
Возьми пример, и попробуй.
А потом попробуй последовательно избавляться от любых препятствий.
T>>А если она не решается? Ась? R>То что? По-моему — ничего, просто не очень хороший контекст для разговора о распараллеливании. R>Гораздо более интересно если всё же решается, то тут видно, что одни подходы решают её, другие — нет.
Динамический поток данных настолько хорош в решении задач параллелизации, что для систем выполнения на его основе приходится изобретать способы уменьшения параллелизма.
"В отличии от."
R>Или ты имеешь в виду, что теоретический максимум это и есть те самые 20% и наша задача как выжать их? Ну тогда тут надо заниматься такими вещами как ограничивать кол-во рабочих потоков числом 2, иначе мы в лучшем случае будем тратить процессорное время впустую, а в худшем производительность будет деградировать. Далее детектировать топологию системы и привязать эти два потока к ближайшим ядрам желательно разделяющим кэш (но ни в коем случае ни к двум аппаратным потокам внутри одного ядра, и ни в коем случае не к двум процессорам, находящимся на разных NUMA узлах). R>Кстати, хороший вопрос — какие из упоминавшихся систем (Haskell, Erlang) это могут?
Вообще ничего не понял.
Переформулируй.
T>>Не "была", а "будет". T>>Это я рассуждал о будущей системе, которую я сейчас прикидываю. R>Ты это хочешь перекладывать на конечного программиста? Или этот анализ будет делать ран-тайм?
Рантайм, само собой. Специально заточенный под моделирование аппаратуры.
Не под любую задачу, заметь.
T>>Её, как и всё остальное, надо проверять. T>>Бремя доказательства лежит на высказавшем. R>Её надо не только проверять, для начала надо придумать алгоритм, как это можно делать...
А для динамического потока данных, когда нет состояния в агентах, этот алгоритм уже готов.
И для OpenMP тоже есть.
Ну, и кто в проигрыше?
По-моему, в проигрыше агентный подход.
T>>Ты сперва добейся независимой работы этой сотни агентов. T>>А то ты о самом сложном говоришь, как о решённой задаче.
R>Не понял. Работа разных агентов по определению независима. Что ты имеешь в виду?
Я имею в виду алгоритм, который "для начала надо придумать".
Ты его ещё, оказывается, не придумал, а уже споришь о преимуществах агентного подхода.
По-моему, ты зря тратишь чужое время.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, lomeo, Вы писали:
IT>>Ну-ка, ну-ка? Что у нас за той дверью?
L>С++!
Понятно. Только что вышел из комнаты с плюсами и тут же опять в неё попал. Это называетя circle reference, проблема не имеющая вменяемого решения для плюсов.
Неясность изложения обычно происходит от путаницы в мыслях.
Если нам не помогут, то мы тоже никого не пощадим.
Если нам не помогут, то мы тоже никого не пощадим.
Потому что принуждение к распараллеливанию из ниоткуда не возьмется 
Хотя я знаю почему их нет, правильно, мы выучили, что есть задача — есть адекватный инструмент. А иммутабельность точно так же как мутабельность может привести к деградации.
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
Я не знал, что в SQL есть first class functions. В инете сходу не нашёл, сам не знаю ни одного примера — не раз не пользовал в SQL FCF и не представляю как. Не подскажешь где почитать или кейвордов/примеров накидаешь?
