Здравствуйте, 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>Поэтому использование их "для оптимизации" мне показалось несколько бесполезным.

Вот это ты зря.

Здравствуйте, mkizub, Вы писали:

M>Видишь в чём дело, я говорил о некоей абстрактной адаптируемости, а ты её перевёл в привычный тебе термин FPGA, и на этом построил свои дальнейшие рассуждения.

Ну что ж поделаешь, ты же уже сказал, что я не в состоянии твои идеи понять.

M>Я не имел в виду конкретно FPGA. Вообще-то я имел в виду другие вещи, скажем, человеческий мозг.

И кто сказал, что количество транзисторов потраченное на все эти конвееры и предсказания я не мог бы лучше использовать? Вместо одного ядра я бы сделал 16 специализированных под решение моего типа задач, из того же числа транзисторов. И оно бы летало намного быстрее. Если я могу распараллелить свою задачу. И наоборот, если не могу — то лучше сделать один сверх-умный проц, а не 16 тупых.

Это, оказывается, было про человеческий мозг? Занятно.

M>Я не знаю, как будет работать подобная технология для кремния (и для кремния-ли), но это в принципе достижимо.

И чем тебе FPGA не нравится?

M> Я не знаю, будет новая конфигурация процессора загружаться в него в течении микросекунд

FPGA на основе SRAM обеспечивают очень быструю загрузку.

M> А суть в том, что адаптивность процессоров возможна.

Возможна. Только не на уровне прикладного программирования и даже не на уровне разработчиков компиляторов.

M> И пример из биологической жизни (адаптируемость нервной системы животных, а не жестко зашитая программа, как у насекомых) показывает, что возможны и успешны оба варианта

Не, этот пример показывает, что доказательство по аналогии является формой демагогии.

M>FPGA — это самое начало адаптивности, что-то вроде ламповых компьютеров.

Вопрос тот же — чем конкретно оно тебя не устраивает?

Здравствуйте, 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 операций и пр.

Здравствуйте, Gluk_Kazan, Вы писали:


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а для большинства методов.

Здравствуйте, mkizub, Вы писали:

M>Какой, кстати?

Зависит от конкретного типа. Но не меньше чем на порядок. С этим борятся путем обвязки обычными микросхемами — памятью, контроллерами шин и т.п., хотя все это есть и в виде библиотек.

M>Вот если сравнить с нынешними x86 процессорами? Я так понимаю, что x86 процессоры имеют приблизительно 10-кратный запас

Это не тот оверхед. В FPGA все начинается на уровень ниже — там нет даже совсем простой логики — сумматоров, регистров. Все это формируется из стандартных вентилей.

Здравствуйте, mkizub, Вы писали:

AVK>>Ну что ж поделаешь, ты же уже сказал, что я не в состоянии твои идеи понять.

M>Вот именно поэтому и не можешь.

У меня свое мнение на этот счет. Ну да ты продолжай.

AVK>>Это, оказывается, было про человеческий мозг? Занятно.

M>Попробуй перейти на другой уровень абстракции.

Не, мужик, ты там говорил вполне конкретно о конкретных вещах.

AVK>>И чем тебе FPGA не нравится?

M>Почему не нравится?

Ты утверждаешь, что это не то. Вот и продемонстрируй, чего там не хватает.

M> Я о нём кроме общих слов ничего не знаю.

Откуда тогда такие далеко идущие выводы. На всякий случай, чтобы не было разговоров о высших абстракциях, я процитирую:

FPGA — это самое начало адаптивности, что-то вроде ламповых компьютеров.

Вот и поясни, какими будут транзисторные компьютеры.

M> Как он может мне нравится или не нравится?

Это ты себе вопрос задай.

Здравствуйте, fmiracle, Вы писали:

F>Я, кстати, так и не смог толком понять, чего же тебе хочется получить.

Ну так ты тоже, не в состоянии понять ввиду ущербности своего мышления.

Здравствуйте, Pavel Dvorkin, Вы писали:
PD>0 >= 0 ? Не менее, верно.
Совершенно точно

PD>Я IL плохо знаю, но что-то не помню, чтобы там были инструкции в стиле SIMD. ИМХО все же просто компилятор должен бы некие IL-SIMD инструкции генерировать (т.е в IL должны быть команды SIMD типа).
Нет, это плохая идея.
PD>А сейчас JIT их создавать будет на базе тех инструкций, которые там есть ? Что-то мне идея "наоборот" кажется совсем странной.
Конечно. Вон народ говорит по соседству, что плюсовый компайлер это и делает.

PD>Хм. Дело в том, что тут не всегда четыре сложения, идущие подряд, есть. Это лишь простейший случай. Их просто может и не быть явно. Чтобы они появились, надо код переписать, сделать так, чтобы они появились.
Нет.
Начнем сначала: ты привел пример кода, где сложения выполняются в цикле.
Да, такой код компилятору трудно векторизовать, но всё еще возможно.

Вот если ты постараешься испортить этот код, затуманить задачу — например, вручную распараллелив цикл и навтыкав туда volatile — тут да, точно, "алгоритм придется несколько поменять". Именно об этом я и говорю — отсутствие удачной абстракции ограничивает возможности компилятора
PD> Алгоритм несколько поменять. А вот когда они будут, тогда либо вручную, либо компилятор, может,и сумеет.
Легче всего компилятору действовать тогда, когда он компилирует с языка, на котором твои действия записаны в максимально осмысленном виде. Вместо конкретного цикла, с конкретным битоперемешиванием мелконарезанных фрагментов, компилятор, к примеру, наблюдает операцию типа a = b + c, где все компоненты — это, скажем, вектора. Семантика операции + компилятору полностью известна, в том числе коммутативность, а также отсутствие побочных эффектов. Благодаря этому он волен сам выбирать, при помощи чего складывать компоненты, паралелить это или нет, и пользоваться ли MMX/SSE или штатным скалярным execution unit.