OSDev

для всех
Текущее время: 19 ноя 2017, 04:15

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 285 ]  На страницу 1, 2, 3, 4, 5 ... 29  След.
Автор Сообщение
СообщениеДобавлено: 06 дек 2014, 15:58 
Аватара пользователя

Зарегистрирован: 17 фев 2013, 16:13
Сообщения: 163
Я открываю настоящую тему с целью поделиться своими размышлениями о том, каким мог бы быть новый язык программирования и компилятор к нему. Сразу оговорюсь, что какого-то целостного видения такого языка у меня нет, есть только замечания к существующим и некоторые мысли о том, что должен уметь делать язык высокого уровня, предназначенный для сложнейших научных расчётов. Также читатели должны понимать, что на мои взгляды накладывает большой отпечаток и специфика моей деятельности: я занимаюсь труднорешаемыми задачами (NP, #P) перечислительной комбинаторики с использованием высокопроизводительных параллельных вычислений (HPC). Эти задачи, как правило, требуют больших ресурсов как по числу процессоров, так и по объёму оперативной памяти. Можно сказать и проще: это самые трудные задачи из всех, которыми можно грузить компьютер, поэтому если новый язык будет удовлетворять моим требованиям, то он, скорее всего, подойдёт для реализации любых других задач, для которых сейчас используют, например, С++/Assembler. Долгое время я пользовался различными СКА (системами компьютерной алгебры типа Maple, Mathematica, Maxima) для своей работы, а также языками С++ и Assembler (yasm), что непременно наложит отпечаток на ход моих мыслей также. Например, мыслимый мною язык будет похож на СКА, при этом беря для себя лучшее от языков типа C++.

Моими основными задачами при разработке языка, которые прямо вытекают из моей научной деятельности, я вижу задачи следующие.
  • Определение узких мест, концептуальных недоработок и прочих недостатков имеющихся инструментов для научных расчётов.
  • Определение требований к тому, какими свойствами должен обладать инструмент на самом деле.
  • Поиск способов осуществления требований в едином языке.
  • Предложение конкретных синтаксических особенностей языка.
  • Может что-то ещё, посмотрим…

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

! Сразу предупреждаю, что холиварить ни с кем не буду. Кому эти идеи помогут – буду рад, берите, не жалко, а кому не нравятся – аргументируйте, но данная тема настолько личная для меня, что успешная аргументация может быть только на мировоззренческом уровне. То есть, скорее всего, каждый останется при своём. Пишите свои идеи тоже, кому не жалко.

Для начала я буду рассказывать о некоторых принципиальных особенностях, которые должны быть в новом инструменте.

[ 1 ] :: Компилятор или интерпретатор?

Речь не пойдёт о поиске универсального способа трансляции, поскольку все мы знаем, что в каждом случае подходит свой способ: кому-то больше подойдет только компиляция, кому-то только интерпретация, а кому-то динамическая компиляция, ведь всё зависит от целей. Для моих целей, а, следовательно, для целей множества других людей, занимающихся требовательными к ресурсам научными расчётами, наиболее хорошим может стать некий компромисс между интерпретируемым и компилируемым инструментом. Выглядеть это должно примерно так: имеется некая среда разработки, напоминающая среду Maple, Mathematica или другие похожие СКА, пользователь вводит команды, а среда исполняет их, выдавая результат. Но все эти команды, вызываемые из ядра или библиотеки СКА, являются заранее скомпилированными под конкретное железо подпрограммами. Пользователь может по своему желанию превратить и набранную им в этой среде программу в бинарный код, который будет оптимизирован под его машину.

Таким образом, новый инструмент должен предоставлять как функции интерпретатора, так и компилятора в бинарный код. Теперь я поясню свою мысль более подробно, приводя (только короткие) обоснования из собственного опыта.

Проблема в том, что интерпретаторы работают медленно, так как полноценная оптимизация кода в чистом интерпретаторе невозможна. Бинарная реализация, даже не очень аккуратная, рвёт любую интерпретируемую СКА на части, если руки у программиста растут и плеч, конечно. Я не буду долго описывать конкретные случаи (их очень много), но могу с уверенностью заявить, что разница в эффективности порой достигает нескольких порядков. Так, мне пришлось переписать в бинарный код (на C++) функцию rgf_findrecur; из Maple, поскольку она умела выводить рекуррентные соотношения порядком («глубиной») лишь несколько сотен. Мне в то время нужно было найти соотношение порядком 14 с половиной тысяч, а впоследствии понадобилось вводить соотношения порядком почти 30 тысяч. Так вот, моя функция этим соотношением даже не подавилась, тогда как Maple уже не смог считать из файла исходные данные, по которым её нужно строить.

Почему? Всё просто, Maple - это интерпретатор. Пусть даже он вызывает примитивные функции своего уже откомпилированного ядра (например, длинную арифметику GMP), это не спасает его от необходимости высокий уровень абстракции переводить «на лету» в эти самые примитивные функции, поскольку все промежуточные функции, которые подключатся с помощью различных пакетов, также интерпретируются. Я же хочу, чтобы подключаемые модули были исключительно бинарными. Но почему бы тогда вообще не избавиться от интерпретатора и не писать всегда компилируемый код для нужных вычислений?

Компилятор для работы с набором вычислений тоже не очень хорошо подходит. Основная причина в том, что исследователь – не всегда профессиональный программист. Он совершенно не обязан владеть методами разработки полноценных программ и всеми тонкостями проектирования, отладки, профилировки и т. д и т. п.

С интерпретатором должно быть удобно работать в интерактивном диалоговом режиме. Представьте, мне нужно провести ряд расчётов, причём следующий мой шаг может зависеть (а может и не зависеть) от ответа системы на предыдущих шагах. Например, если некоторая функция вернула мне отрицательное число, я делаю для себя один вывод и веду исследование одним способом, если число положительное, я выполняю совершенно другой набор действий. Казалось бы, почему бы не написать тогда условие и не реализовать обе ветки? Потому что на самом деле нужна только одна! Нафига писать вторую (причём я заранее не знаю, которая сработает), если она никогда не понадобится? А если ветвлений не 1, а 10, то что, мне нужно реализовать 1024 куска? Пусть даже можно будет сократить это число до двух-трёх десятков, если заранее подумать, какие могут быть варианты. Но, повторюсь, исследователь - это не совсем программист. Он не обязан сидеть и разрабатывать проект своей программы, рассматривать и прописывать в коде все случаи, почти 100% из которых всё равно не осуществляется. Процесс научных расчётов напоминает скорее диалог с компьютером, и каждая фраза этого диалога, сказанная компьютеру, должна быть понята максимально эффективно. Затем учёный может сохранить результат диалога и отправить его своему коллеге, а тот сможет заново прогнать диалог на своей системе.

Если резюмировать, то от компилятора у СКА должна быть скорость работы бинарного кода его подключаемых модулей (библиотек) и его минимальная требовательность к памяти, от интерпретатора у СКА должно быть удобство диалогового режима общения и упрощённый процесс разработки несложных программ, когда отсутствует необходимость владения профессиональными навыками программирования. При этом возможность написать полноценный код, компилируемый в бинарный, должна оставаться для создания каких-то своих пакетов, с которыми затем можно будет работать в диалоговом режиме, ведь системой будут пользоваться и профессиональные программисты. В этом случае уже вступают в силу законы разработки ПО в своей полной силе, поэтому инструмент должен предоставлять функции редактора кода, отладчика, профилировщика и другие (кому какие нужны).

Ещё один, но слабый, аргумент в пользу интерпретатора. Это переносимость и документированность. Переносимость обеспечивается тем, что программу нельзя запустить без самой среды СКА, поэтому если среда на машине работает (то есть под машину удалось скомпилировать все библиотеки и интерфейс), то будет работать и любой написанный для неё код. При этом интерпретируемый код, особенно выводящий результаты выполнения операций сразу после их выполнения в тот же worksheet, во многом больше напоминает некий научный текст, который так же удобно читать, как научную статью. Там прослеживается ход мыслей автора, сразу виден результат выполнения того или иного шага.

[ 2 ] :: Принцип параллельности

Такая СКА должна быть сразу параллельной без всяких вариантов. Параллельность должна быть также естественно зашита в синтаксисе вызова команд, как естественно зашиты там операторы присваивания или сравнения. Каждая скомпилированная заранее функция, которую можно вызвать из командной строки интерпретатора, реализована в параллельном исполнении. У каждой функции есть описание, которое показывает, насколько хорошо функция масштабируется по результатам исследования её разработчика.

Разумеется, эти результаты не должны вводить в заблуждение пользователя, а должны лишь подсказывать, что ему делать, на сколько ядер запускать процесс для первой пробы, чтобы определить для себя золотую середину, если это потребуется.

Таким образом, любую функцию можно запустить с некоторым параметром, означающем число процессов или потоков (в зависимости от ситуации).

Различные функции и команды синхронизации также должны быть частью языка, как и прочие функции управления параллельными процессами и потоками. Представьте себе команды MPI или директивы OpenMP. Вот всё это должно наличествовать в языке не как надстройка, а как часть встроенной системы команд и операторов.

[ 3 ] :: Принцип отзывчивости и дружественности

Любой вызов функции не должен блокировать командную строку. Пользователь запустил функцию и может работать дальше, а функция крутится в фоновом режиме. Чаще всего происходит наоборот: ввёл команду и сиди жди или создавай новый worksheet и работай там. Но это мелочи по сравнению со следующей проблемой.

Одна из основных проблем взаимодействия между пользователем и СКА - отсутствие обратной связи, то есть информирования пользователя.
Выглядит это примерно так: пользователь ввёл команду, нажал Enter, и ждёт... Он совершенно не представляет, сколько ему ждать. Может час, а может неделю. Были случаи, когда приходилось ждать две недели, а потом дома выключали свет, или он просто «моргнул» :) Поэтому нужен бесперебойник.

Это состояние неопределённости просто выбешивает. При работе с чрезвычайно затратными задачами наивно полагать, что всё происходит так же быстро, как в компьютерной игре. Расчёты ответа одной задачи могут занимать от суток до полугода.

Любой алгоритм, если он работает долго, выполняет какой-то набор шагов, которые условно можно разделить на ряд блоков, итераций или каких-то ещё структурных элементов. По запросу пользователя система просто обязана выдать позицию, на которой находятся вычисления. В описании вызываемой функции обязательно должно быть предусмотрено краткое описание алгоритма ровно на таком уровне, чтобы пользователь мог примерно прикинуть «ага, тут у нас ожидается миллион итераций какого-то цикла, почти все итерации выполняются с одной сложностью, хорошо», и наблюдать в реальном времени, на каком шаге сейчас находится алгоритм. Другой вариант – создавать так называемые info_level. Чем выше это число при вызове функции, тем больше промежуточной информации выводит функция в процессе своей работы, то есть тем более детально она описывает обход определённых контрольных точек. Механизм создания таких контрольных точек должен быть зашит в язык как родной.

Далее, я сторонник той позиции, что командная строка должна быть доступна с наивысшим приоритетом. Ничто и никогда не должно как-либо отрезать пользователя от управления процессом. Даже если процессор занят на полную мощность, даже если на нём уже можно жарить сосиски, командная строка обязана послушно принять любую команду! Единственное, что может тут помешать - сбой аппаратуры. Ни одна СКА даже близко не отвечает этому требованию. Наиболее частая грабля, на которую я наступал, состояла в том, что система могла незаметно уйти в своп. Всё, можно сразу нажимать Reset (у Вас ведь ещё есть такая кнопка?), расчёты уже не спасти. В Maple при глубоком свопе никакие прерывания ОС просто не доходят до компьютера на протяжении нескольких часов.

--- Далее идёт лирическое отступление ---

Почему Maple может незаметно уйти в своп? Потому что он совершенно неконтролируемо жрёт память. В моей практике были случаи, когда на пустом месте сжиралось два с половиной десятка гигабайт, тогда как если пытаться руководствоваться здравым смыслом, там больше двух с половиной гигов быть не может в принципе.

Простой пример: записать в массив числа от 1 до 2^20 в Maple 18. Сразу съедает 20 Мб. Не многовато? А если заполнить этот массив полиномами a[k]=1+x^k, то сожрано будет уже 250 Мб.

Даже если Maple делает «запас на будущее», процесс этот не контролируется никак. Когда он хапнет и сколько, предсказать невозможно. Дело в том, что внутренние структуры Maple, различные типы данных и способ их организации до ужаса неэффективны в плане экономии ресурсов системы. И проблема не только в интерпретации кода (хотя она кажется мне главной). Так, например, функция rgf_findrecur, упомянутая выше, которая выводит линейное рекуррентное соотношение по заданной последовательности чисел, помимо прочего решает систему линейных уравнений в целых числах. И всё бы ничего, но система эта теплицева (т. е. матрица системы n x n состоит только из 2n-1 различных чисел, которые копируются в неё в особом и очень простом порядке, дублируя друг друга)! Это значит, что для хранения матрицы нужна линейная память, а не квадратичная, что в алгоритме никак не заложено. Алгоритм сначала послушно создаёт теплицеву матрицу из длинных чисел - это просто преступление. Отчасти это объясняет причину тормознутости функции, но лишь отчасти.

Подобных глупостей в системе чрезвычайно много. При всём при этом, указанная функция работает на порядки быстрее аналогичных функций, которые есть (если вообще есть) в других СКА. Это вообще удивительно. Но ещё более странным является то, что есть в Maple функция listtoratpoly которая по сути делает абсолютно то же самое, но вместо рекуррентного соотношения выводит рациональную производящую функцию (я уверяю читателя, что в данном контексте это одна и та же задача и по сути разница только в выводе, если не считать одной мелкой и быстрой операции, которая их отличает). Так вот, эта функция на порядок медленнее, чем первая. Почему? Для меня это осталось загадкой. Первая функция более ранняя и находится в пакете genfunc, вторая появилась позже в пакете gfun. Оба пакета призваны делать по сути одну и ту же работу, однако являются разными, и второй умеет делать больше всяких полезных штук, но и тормозит сильнее.

Такого не должно быть в СКА. Система команд должна быть продумана очень хорошо, а если это невозможно сделать сразу, должен быть продуман стандарт, по которому будет расширяться система команд, чтобы не получилось так, что когда один пакет настолько обрастает ошибками или настолько выходит из-под контроля, что пишут второй (третий, четвёртый), который делает по сути то же самое или чуть больше, а первый оставляют для совместимости со всем мусором, там образованным.

--- Конец лирического отступления ---

Что касается интерфейса, то он должен быть быстрым. Мне не так важно, будет он красивым или нет. Он должен быть быстрым. В Maple взаимодействие с пользователем осуществляется через Java-морду. Она настолько безбожно тормозит, что порой хочется взять и выключить компьютер. В последних версиях (17, 18) тормоза стали меньше, и вроде бы даже команда типа «1+1» уже выполняется быстрее, чем за одну секунду (раньше приходилось ждать 2-3 секунды). Но тормоза остаются при работе с достаточно большими файлами, где много команд, особенно когда включается сборщик мусора. Я убеждён, что интерфейс должен быть максимально независимым от самих вычислений. Нельзя функции взаимодействия с пользователем хоть как-то объединять с вычислениями.

Можно сделать красивый и удобный интерфейс, но при условии, что он будет моментально отзываться на любую просьбу. Я даже «за» красивый интерфейс, в котором будет не просто голая командная строка, а разные информеры, сообщающие полезную информацию, подсказки, справки и т. д. Всё это можно удобно расположить по бокам монитора. Например, где-то же нужно отображать список запущенных в фоновом режиме команд и иметь кнопки их отключения, отображать контрольные точки восстановления, объём съеденной и оставшейся памяти и т. д.

[ 4 ] :: Принцип безопасности расчётов

Очень обидно, когда в случае возникновения ошибки (в любом месте программы), вся промежуточная информация теряется. В язык должны быть зашиты простые средства работы с log-файлами для выяснения причины сбоя и отката на предыдущую удачно выполненную операцию.

Также очень часто требуется такой механизм, как создание точек восстановления. Представьте себе, что по техническим причинам работа программы должна быть прервана. В этом случае плохо терять месяц или два работы, если никак нельзя сохранить dump на диск, чтобы при следующем запуске программа начала ровно с того же места. Либо должен быть механизм транзакций, позволяющий создавать точки восстановления после каких-то определённых моментов. Но я проще всего вижу ситуацию следующим образом. Программа работает, пользователь вводит команду создания точки восстановления, создаётся такая точка, теперь программу можно отключить. При следующем запуске старт по желанию пользователя начинается с любой желаемой точки восстановления. Средства безопасности, перечисленные в этом абзаце, должны быть продуманы в синтаксисе и семантике языка. Понятно же, что организация подобных контрольных точек потребует в коде программы указывать места, где программа может безопасно остановиться, где данные потоков гарантированно синхронизированы и можно сливать свою копию на диск, временно блокируя все порождённые процессы и потоки.

[ Продолжение следует ]


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 06 дек 2014, 17:48 
Аватара пользователя

Зарегистрирован: 16 май 2007, 23:46
Сообщения: 1056
Цитата:
являются заранее скомпилированными под конкретное железо подпрограммами. Пользователь может по своему желанию превратить и набранную им в этой среде программу в бинарный код, который будет оптимизирован под его машину.

Надо доработать либо прояснить. Под конкретную ручная либо автоматическая под произвольную.
Цитата:
Таким образом, новый инструмент должен предоставлять как функции интерпретатора, так и компилятора в бинарный код.

Да все маломальский большие интерпретаторы компилят в бинарный код или P-cod.

Цитата:
Почему? Всё просто, Maple - это интерпретатор. Пусть даже он вызывает примитивные функции своего уже откомпилированного ядра (например, длинную арифметику GMP), это не спасает его от необходимости высокий уровень абстракции переводить «на лету» в эти самые примитивные функции, поскольку все промежуточные функции, которые подключатся с помощью различных пакетов, также интерпретируются.

Это не анализ. Если вам надо считать данные, то вы их считываете. Даже если взять худший случай всё интерпритируем то 16 ГБайт считается за 1600 секунд.
Иначе данные просто представленны в неудобном формате. Но это проблема формата, а читалки или компилятора.
Да тут как бы оптимизаторы слабые. Но если ставить задачу, то она решаемая.
Есть проблемы со стыковкой такой оптимизатор не может оптимизировать бинарный код.

Цитата:
Компилятор для работы с набором вычислений тоже не очень хорошо подходит. Основная причина в том, что исследователь – не всегда профессиональный программист. Он совершенно не обязан владеть методами разработки полноценных программ и всеми тонкостями проектирования, отладки, профилировки и т. д и т. п.

Это ещё бабушка на двое сказала. Есть задачи которые редки и их делать жесткими не имеет смысл. Да пожалуй это исследовательские.
А есть задачи которые повторяются часто и их неплохо бы автоматизировать.


Цитата:
Потому что на самом деле нужна только одна! Нафига писать вторую (причём я заранее не знаю, которая сработает), если она никогда не понадобится? А если ветвлений не 1, а 10, то что, мне нужно реализовать 1024 куска? Пусть даже можно будет сократить это число до двух-трёх десятков, если заранее подумать, какие могут быть варианты. Но, повторюсь, исследователь - это не совсем программист. Он не обязан сидеть и разрабатывать проект своей программы, рассматривать и прописывать в коде все случаи, почти 100% из которых всё равно не осуществляется. Процесс научных расчётов напоминает скорее диалог с компьютером, и каждая фраза этого диалога, сказанная компьютеру, должна быть понята максимально эффективно. Затем учёный может сохранить результат диалога и отправить его своему коллеге, а тот сможет заново прогнать диалог на своей системе.

Это плохой исследователь. Задача исследователя исключить всё лишнее. Если он не может то это его проблемы. А программы пишутся также.

Цитата:
Ещё один, но слабый, аргумент в пользу интерпретатора. Это переносимость и документированность. Переносимость обеспечивается тем, что программу нельзя запустить без самой среды СКА, поэтому если среда на машине работает (то есть под машину удалось скомпилировать все библиотеки и интерфейс), то будет работать и любой написанный для неё код. При этом интерпретируемый код, особенно выводящий результаты выполнения операций сразу после их выполнения в тот же worksheet, во многом больше напоминает некий научный текст, который так же удобно читать, как научную статью. Там прослеживается ход мыслей автора, сразу виден результат выполнения того или иного шага.

Типичное заблуждение. Как бы хорошо вы не писали код документацию он не отменяет.
А вот в документации как раз и описывается семантика, т.е глубокий ход мыслий автора.


Цитата:
У каждой функции есть описание, которое показывает, насколько хорошо функция масштабируется по результатам исследования её разработчика.

Разумеется, эти результаты не должны вводить в заблуждение пользователя, а должны лишь подсказывать, что ему делать, на сколько ядер запускать процесс для первой пробы, чтобы определить для себя золотую середину, если это потребуется.

Написание паральльных функций более чем в 5 раз сложнее обычных.


Цитата:
Различные функции и команды синхронизации также должны быть частью языка, как и прочие функции управления параллельными процессами и потоками. Представьте себе команды MPI или директивы OpenMP. Вот всё это должно наличествовать в языке не как надстройка, а как часть встроенной системы команд и операторов.

А смысл? Почему бы не сделать как это сделано в C#?

Цитата:
Любой вызов функции не должен блокировать командную строку. Пользователь запустил функцию и может работать дальше, а функция крутится в фоновом режиме. Чаще всего происходит наоборот: ввёл команду и сиди жди или создавай новый worksheet и работай там. Но это мелочи по сравнению со следующей проблемой.

Это противоречт предыдущим высказываниям. Если поручить работнику рутинную работу а потом отвликать. То как инимум он будет делать все медленее нежели чем последовательно, так вообще черевато ошибкам.

Цитата:
Это состояние неопределённости просто выбешивает. При работе с чрезвычайно затратными задачами наивно полагать, что всё происходит так же быстро, как в компьютерной игре. Расчёты ответа одной задачи могут занимать от суток до полугода.

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


Цитата:
Почему Maple может незаметно уйти в своп? Потому что он совершенно неконтролируемо жрёт память. В моей практике были случаи, когда на пустом месте сжиралось два с половиной десятка гигабайт, тогда как если пытаться руководствоваться здравым смыслом, там больше двух с половиной гигов быть не может в принципе.

В моей практике в бинарном коде было. Называется фрагментация памяти.

Цитата:
Даже если Maple делает «запас на будущее», процесс этот не контролируется никак

Золотое правило программистов. Выигрываешь в скорости проигрываешь в памяти и наоборот.


Цитата:
Такого не должно быть в СКА. Система команд должна быть продумана очень хорошо, а если это невозможно сделать сразу, должен быть продуман стандарт, по которому будет расширяться система команд, чтобы не получилось так, что когда один пакет настолько обрастает ошибками или настолько выходит из-под контроля, что пишут второй (третий, четвёртый), который делает по сути то же самое или чуть больше, а первый оставляют для совместимости со всем мусором, там образованным.

Это трудный вопрос. Заложишься на расширения будет тормозить и трудно писать. Не заложишься будешь переписывать.
В этом плане неспешная разработка паскаля и Delphi в котором появления новых фишек было постепенным спустя годы после того как их уже попробовали в СИ++. Правда сейчас они ускорились и качество снизилось.

Цитата:
Также очень часто требуется такой механизм, как создание точек восстановления. Представьте себе, что по техническим причинам работа программы должна быть прервана. В этом случае плохо терять месяц или два работы, если никак нельзя сохранить dump на диск, чтобы при следующем запуске программа начала ровно с того же места. Либо должен быть механизм транзакций, позволяющий создавать точки восстановления после каких-то определённых моментов. Но я проще всего вижу ситуацию следующим образом. Программа работает, пользователь вводит команду создания точки восстановления, создаётся такая точка, теперь программу можно отключить. При следующем запуске старт по желанию пользователя начинается с любой желаемой точки восстановления. Средства безопасности, перечисленные в этом абзаце, должны быть продуманы в синтаксисе и семантике языка. Понятно же, что организация подобных контрольных точек потребует в коде программы указывать места, где программа может безопасно остановиться, где данные потоков гарантированно синхронизированы и можно сливать свою копию на диск, временно блокируя все порождённые процессы и потоки.

Совсем не юзаблити. Вы просто не знакомы с пользователями.
Они повернуть монитор не могут без бумажки. Или пыль протирать.
Не говоря уже о том чтобы дамп сделать и запустить.
Из фильма:
Они пишут такие умные программы, что ими могут пользоваться только умники.

Ну да Maple пожалуй верх тормознутасти. Даже в 13 уже можно было жить при сложении 1+1.
И переделать её надо. Вот только какой это объем?
Поэтому и жертвуют качеством разработки в пользу объема.
И как я уже писал есть много критериев и они противоречивы так что сделать лучше трудно.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 07 дек 2014, 02:09 
Аватара пользователя

Зарегистрирован: 28 май 2012, 23:44
Сообщения: 237
Откуда: Санкт-Петербург
pavia писал(а):
В этом плане неспешная разработка паскаля и Delphi в котором появления новых фишек было постепенным спустя годы после того как их уже попробовали в СИ++. Правда сейчас они ускорились и качество снизилось.

Неспешная разработка Delphi -- следствие неэффективности руководства и пораженческой политики Borland, добровольно отказавшейся развивать продукт, -- с закономерным результатом. А потом, пока компания ходила по рукам, часть ведущих разработчиков, видимо, ушла, плюс теперь они находятся в положении догоняющего. Вот и имеем что имеем.

Пока дождусь остальных частей, в дискуссию вступать не буду.


Последний раз редактировалось Freeman 15 фев 2015, 21:41, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 07 дек 2014, 08:38 
Аватара пользователя

Зарегистрирован: 17 фев 2013, 16:13
Сообщения: 163
pavia писал(а):
Цитата:
являются заранее скомпилированными под конкретное железо подпрограммами. Пользователь может по своему желанию превратить и набранную им в этой среде программу в бинарный код, который будет оптимизирован под его машину.

Надо доработать либо прояснить. Под конкретную ручная либо автоматическая под произвольную.

Автоматическая под произвольную. Сам компилятор должен быть оптимизирующим и под каждую машину оптимизация у него своя. О ручной оптимизации речь ещё пойдёт.


Цитата:
Иначе данные просто представленны в неудобном формате. Но это проблема формата, а читалки или компилятора.
Да тут как бы оптимизаторы слабые. Но если ставить задачу, то она решаемая.
Есть проблемы со стыковкой такой оптимизатор не может оптимизировать бинарный код.

Все задачи решаемы, однако практика показывает, что либо нет людей, которые их решают правильно, либо руки у них или их руководителей растут из другого места. Это проблема не только читалки или компилятора, а самого подхода. Порочный подход даёт порочный результат.

Цитата:
Это ещё бабушка на двое сказала. Есть задачи которые редки и их делать жесткими не имеет смысл. Да пожалуй это исследовательские.
А есть задачи которые повторяются часто и их неплохо бы автоматизировать.

Не важно, кто это сказал и когда. Важно, что это есть и отрицать это - значить впадать в заблуждение. Не скажу, что исследовательские задачи редки, просто они в другой плоскости и как бы незаметны обычным программистам.

Цитата:
Это плохой исследователь. Задача исследователя исключить всё лишнее. Если он не может то это его проблемы. А программы пишутся также.

Чтобы исключить всё лишнее, нужно знать, что исключать. В исследовательских задачах совершенно не очевидно бывает, каким путём пойдут расчёты, так как нередко, что задача решается впервые. Автоматизировать подход и написать полноценную программу можно, но для этого нужно сначала набить много шишек, определить это самое "лишнее" и т. д. Если бы всё было так просто, не нужен был бы компьютера для исследователя - сел, да и написал сразу значение функции на бумаге.

Цитата:
Типичное заблуждение. Как бы хорошо вы не писали код документацию он не отменяет.
А вот в документации как раз и описывается семантика, т.е глубокий ход мыслий автора.

А я не отменяю документацию, а лишь говорю, что такой worksheet будет более читаемым. Документацию пишут, когда продукт уже почти готов и его функции определены, в целом, однозначно. В научном поиске так не бывает, и нет смысла писать документацию, когда поначалу не ясно, что делать с результатами.

Цитата:
Написание паральльных функций более чем в 5 раз сложнее обычных.

Во-первых, число 5 взято с потолка (тут может быть 1, а может быть и 100). Во-вторых, сложность не отменяет необходимости.

Цитата:
А смысл? Почему бы не сделать как это сделано в C#?

Как именно это будет сделано, пока не важно. Важно, чтобы язык поддерживал средства работы с параллельностью. И передачи сообщений, и создание потоков и синхронизацию и всё остальное. Чтобы не было двух отдельных инструментов MPI и OpenMP (а также их гибридов), а весь этот (или похожий) инструментарий был бы частью языка.

Цитата:
Это противоречт предыдущим высказываниям. Если поручить работнику рутинную работу а потом отвликать. То как инимум он будет делать все медленее нежели чем последовательно, так вообще черевато ошибкам.

Ничего не противоречит. Если работник запустил одну команду на 10 ядер, а у него их 100, то ему можно запустить ещё сколько-нибудь команд, если их результат тоже нужен для исследования. Кроме того, командная строка должна быть доступна для служебных запросов. Когда процесс крутится, пользователь может захотеть узнать его состояние (на каком шаге работает алгоритм).

Цитата:
Если человек не понимает что делает то кто же ему поможет?
Во-вторых поставить на паузу есть во многих средах просто этим умеют пользоваться единицы.

Ничего подобного. В научных исследованиях НИКТО не понимает, сколько будет считать программа. Можно предсказать это, когда уже запустил и смотришь, с какой скоростью идут итерации цикла. Однако в Maple это нереально, там нет стабильной скорости работы одного и того же кода. Кроме того, это не отменяет, того факта, что за программой нужно следить, если она считает, например, полгода. Кто знает, вдруг в программе ошибка и она просто банально зациклилась где-то, а мы ждём, не понимая, что происходит? Приём тут пауза? Она не спасает от проблемы.

Цитата:
В моей практике в бинарном коде было. Называется фрагментация памяти.

Потому что нужно, чтобы ОС не фрагментировала память. А в сложных программах лучше выделять себе всю память одним куском и с ней работать, никогда не обращаясь к палёным менеджерам памяти ОС.

Цитата:
Цитата:
Даже если Maple делает «запас на будущее», процесс этот не контролируется никак

Золотое правило программистов. Выигрываешь в скорости проигрываешь в памяти и наоборот.

Причём тут это правило? Здесь речь идёт о том, что если Maple хочет отхапать кусок памяти побольше раз в 10, чем ему нужно, он отхапает и не подавится. И тут как раз получается другое правило для Maple: проигрываешь и в памяти, и в скорость и вообще всё плохо.

Цитата:
Цитата:
Такого не должно быть в СКА. Система команд должна быть продумана очень хорошо, а если это невозможно сделать сразу, должен быть продуман стандарт, по которому будет расширяться система команд, чтобы не получилось так, что когда один пакет настолько обрастает ошибками или настолько выходит из-под контроля, что пишут второй (третий, четвёртый), который делает по сути то же самое или чуть больше, а первый оставляют для совместимости со всем мусором, там образованным.

Это трудный вопрос.

Трудный. Как и практически любой научный вопрос. Нужно очень хорошо продумывать, что делать, а для этого нужны люди с годами опыта работы с подобными системами.

Цитата:
Совсем не юзаблити. Вы просто не знакомы с пользователями.
Они повернуть монитор не могут без бумажки. Или пыль протирать.
Не говоря уже о том чтобы дамп сделать и запустить.
Из фильма:
Они пишут такие умные программы, что ими могут пользоваться только умники.

Нет, Вы не правы. Продукт разрабатывается не для секретарш. Меня лично достало постоянно разрабатывать под каждую программу свой способ сброса точек восстановления и тела программы на диск. Должны быть функции, позволяющие это оптимизировать и упростить. Учёный - не программист, он не обязан без косяков кодировать подобные вещи.

Цитата:
Ну да Maple пожалуй верх тормознутасти. Даже в 13 уже можно было жить при сложении 1+1.
И переделать её надо. Вот только какой это объем?
Поэтому и жертвуют качеством разработки в пользу объема.
И как я уже писал есть много критериев и они противоречивы так что сделать лучше трудно.

Трудно - не значит, невозможно. Нужно не Maple переписать, а новую систему по уму делать. Объём не имеет значения и далеко не факт, что именно я буду этим заниматься. На разработку концепции могут уйти ещё годы.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 07 дек 2014, 12:36 
Аватара пользователя

Зарегистрирован: 17 фев 2013, 16:13
Сообщения: 163
[ 5 ] :: Доступ к инструкциям процессора

Огорчает то обстоятельство, что многие языки часто не позволяет спуститься на самый нижний уровень процесса программирования, поскольку язык не даёт возможности явно пользоваться инструкциями процессора или хотя бы косвенно вызывать их. Например, как по мнению читателя нужно сложить два 128-битных целых числа, которые в ЯП, в котором максимальная разрядность переменной составляет 64 бита, реализованы в виде пары таких переменных?

Один из правильных ответов (если брать C++):
Код:
const Int128 operator + ( const Int128 & a, const Int128 & b ) {       
  Int128 res;
  res . l = a . l + b . l;
  res . h = a . h + b . h + ( int64 ) ( ( ( a . l & b . l ) | ( ( a . l | b . l ) & ( ~ res . l )  ) ) >> 63 );   
  return res;
}

Здесь класс Int128 содержит две переменных h (high) и l (low) типа int64 (это псевдоним для long long). Подробнее за объяснениями я отсылаю читателя к книге Генри Уоррена «Алгоритмические трюки для программистов».

Возникает естественный вопрос: «а нафига?». У нас же есть классический приём add / adc. В результате того факта, что в языке C++ нет возможности явно указать компилятору необходимость использовать эти инструкции, и даже нет возможности работать с флагами, программист в благородной попытке обеспечить переносимость между различными ОС и различными компиляторами вынужден заниматься ерундой.

Единственное оправдание этой ерунды - желание обеспечить совместимость на уровне архитектуры, но обычно подобный код не пишется для разных архитектур, это очень «бодяжно», как и многие другие попытки быть универсальным...

--- Лирическое отступление ---

Кстати, вот и ещё один недостаток некоторых систем - склонность к универсальности. Разработчики хотят, чтобы их система всенепременно работала везде. Ну прямо-таки везде. В результате, например, интерфейс Maple был переписан на Java. Более глупое решение и выдумать трудно, но об этом я уже говорил.

--- Конец лирического отступления ---

Язык и компилятор должны развиваться согласованно с архитектурой компьютера. То есть: либо архитектура и язык разрабатываются одновременно и друг для друга, либо язык разрабатывается под конкретную архитектуру (пусть даже виртуальную). Команды и операторы языка должны как можно точнее отображаться на архитектуру процессора и соответствовать ей, либо должна быть возможность спускаться на низкий уровень и управлять командами непосредственно.

Как вариант, можно использовать inline assembler, лишь бы он был удобно связан с высокоуровневыми конструкциями языка (например, поддержка операций типа mov rax, a.l или call someFunction ( p, q, r ) -> rax)

[ 6 ] :: Совместимость с предыдущими версиями

Вопрос совместимости с предыдущими версиями как нельзя остро возникает в подобных системах. С одной стороны, совместимость сильно портит жизнь разработчикам СКА, так как часто приходится создавать костыли, когда радикальная операция была бы значительно более эффективной. С другой стороны, отсутствие совместимости сильно портит жизнь пользователям СКА, поскольку их старые программы перестанут работать. Привожу пример.

Мои коллеги разрабатывали задачник-методичку для работы с СКА на примере Maxima. Эта система обновлялась тогда примерно раз в 1-2 месяца. Вот, пишут они свои задачи в системе, проверяют, чтобы ответы были правильными, пишут методические указания для работы с функциями, как вдруг появляется обновление.

Вот они прогоняют файлы с решениями после обновления и выясняется, что теперь функции работают не так, как было в предыдущей версии, хотя в Maxima совместимость якобы соблюдается. Приходится часть работы переделывать и снова добиваться правильности ответов. Проходит месяц, вот всё исправлено – и вот выходит очередная версия. Всё сначала : )

Я не знаю, как долго они занимались этой ерундой, но не один год точно. Желание работать в Maxima лично у меня отпало сразу же, хотя я пытался себя преодолеть. Имея врождённое внутреннее чутьё к халтурной или непродуманной системе, я сразу им сказал, что добром их порыв не закончится. Кроме того, в этой системе неудобно работать и работает она медленно. Впрочем, как и многие другие (встреченные мной) свободно разрабатываемые кем попало продукты.

Итак, что же делать? Я считаю, что должен быть некий компромисс в вопросах совместимости. Пока продукт ещё в начале своего пути в течении нескольких лет, нужно плевать на совместимость и принимать даже самые радикальные решения. В какой-то определённый момент времени мы говорим, что «всё, вот этот набор функций, ключевых слов и синтактических конструкций больше меняться не будет», – и действительно, тащим его дальше для совместимости. Если однажды мы приходим к выводу, что всё плохо, то пишем новую систему, объявляя её другой, несовместимой с первой. Как, например, Python 3, который не вполне совместим со вторыми версиями. Если возможно, то имеет смысл создать конвертер программ из предыдущей версии в следующую.

Порой недальновидность или ошибки проектировщиков вынуждают радикально пересматривать всю структуру продукта, а обратная совместимость калечит задумку. Лучше вернуться назад и переделать так, как нужно, чем тащить ошибку от версии к версии, создавая бесконечные костыли. Как только что-то становится уродливым из-за необходимости поддерживать совместимость - посылаем совместимость лесом и всё переписываем. Или делаем другую версию, параллельно поддерживая до определённого момента старую, если невозможно создать правильный конвертер.

Трудно? А кто сказал, что будет легко? Либо мы делаем нормальный продукт, либо пользуемся уже готовыми и заставляем себя поверить в то, что нам всё там нравится, потому что делать такой же продукт не имеет смысла.

[ Продолжение следует ]


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 07 дек 2014, 12:39 
Аватара пользователя

Зарегистрирован: 16 май 2007, 23:46
Сообщения: 1056
Цитата:
Ничего не противоречит. Если работник запустил одну команду на 10 ядер, а у него их 100, то ему можно запустить ещё сколько-нибудь команд

Ну вот теперь работнику надо ещё и знать сколько у него ядер и когда память закончится и перейдёт в своп.

Цитата:
Ничего подобного. В научных исследованиях НИКТО не понимает, сколько будет считать программа.

Ничего подобного. В научных эксперементах есть стадия планирования эксперемента в которой определяются затраты.

Цитата:
вдруг в программе ошибка и она просто банально зациклилась где-то, а мы ждём, не понимая, что происходит? Приём тут пауза? Она не спасает от проблемы.

Да притом что 99% о "паузе" не слышали и даже не пользовадись. Как раз "пауза" и нужна что-бы разобраться.
Нажимаем кнопку "pause" программа останавливает свое выполнение. Вы можете посмотреть на какой строчке она сейчас находится и посмотреть параметры переменные
Да и выгрузку и загрузку на паузе легко сделать.

Цитата:
Потому что нужно, чтобы ОС не фрагментировала память. А в сложных программах лучше выделять себе всю память одним куском и с ней работать, никогда не обращаясь к палёным менеджерам памяти ОС.

Причем тут ОС я говорил про фрагментацию в программах. Для которой собственно в java и стоит код что-бы избавится от неё но при этом всё тормазит.

Цитата:
Причём тут это правило? Здесь речь идёт о том, что если Maple хочет отхапать кусок памяти побольше раз в 10, чем ему нужно, он отхапает и не подавится. И тут как раз получается другое правило для Maple: проигрываешь и в памяти, и в скорость и вообще всё плохо.

Цитата:
Простой пример: записать в массив числа от 1 до 2^20 в Maple 18. Сразу съедает 20 Мб.

Что-бы не тратится на конвертирование надо взять больший класс допустим комплексное число.
Для скорости нам понадоися 4байта и того 8, так как мы работает с длинной арифметикой то надо хранить и размер чисел
И того ещё +8=16 знак числа надо хранить отдельно. И того имеем 18 байт А ещё нам понадобиться ссылка на каждое число
Это ещё + 4 и для комплесных +8 и того имеем что надо 30МБайт.
Цитата:
А если заполнить этот массив полиномами a[k]=1+x^k, то сожрано будет уже 250 Мб.

30+30+4+4+1 плюс на операцию 2*(4+4+1+4)
И того 95 МБайт.

Цитата:
Нет, Вы не правы. Продукт разрабатывается не для секретарш. Меня лично достало постоянно разрабатывать под каждую программу свой способ сброса точек восстановления и тела программы на диск. Должны быть функции, позволяющие это оптимизировать и упростить. Учёный - не программист, он не обязан без косяков кодировать подобные вещи.

Поище про слово dump (полный дамп памяти процесса). Средство универсальное. Можете и свой вариант сделать. А для разбора дампа вам понадобится ещё и отладочная информация из-за чего потребляемый объем памяти вырастит до 2-х раз.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 07 дек 2014, 13:15 
Аватара пользователя

Зарегистрирован: 17 фев 2013, 16:13
Сообщения: 163
pavia писал(а):
Ну вот теперь работнику надо ещё и знать сколько у него ядер и когда память закончится и перейдёт в своп.

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

этот работник должен уметь планировать эксперимент : ) На самом деле ничего подобного, невозможно заранее сказать, сколько будет работать достаточно сложный код. Можно лишь указать некоторый диапазон. Только запуск программы может позволить определить, сколько ей считать. Но главное даже не в этом. Я говорю о том, что нужны средства наблюдения за процессом. Хотя бы отладочный вывод.

Цитата:
Да притом что 99% о "паузе" не слышали и даже не пользовадись. Как раз "пауза" и нужна что-бы разобраться.
Нажимаем кнопку "pause" программа останавливает свое выполнение. Вы можете посмотреть на какой строчке она сейчас находится и посмотреть параметры переменные
Да и выгрузку и загрузку на паузе легко сделать.

Зачем останавливать процесс, если нам не нужна сильно детальная информация? Достаточно, чтобы он хотя бы раз в час выдавал, где находится или хотя бы меняется что-то или он висит.

Цитата:
Что-бы не тратится на конвертирование надо взять больший класс допустим комплексное число.
Для скорости нам понадоися 4байта и того 8, так как мы работает с длинной арифметикой то надо хранить и размер чисел
И того ещё +8=16 знак числа надо хранить отдельно. И того имеем 18 байт А ещё нам понадобиться ссылка на каждое число
Это ещё + 4 и для комплесных +8 и того имеем что надо 30МБайт.
Цитата:
А если заполнить этот массив полиномами a[k]=1+x^k, то сожрано будет уже 250 Мб.

30+30+4+4+1 плюс на операцию 2*(4+4+1+4)
И того 95 МБайт.

Вот-вот, я о том же : ) Чтобы не тратиться на конвертирование, нужно брать не просто комплексное число, а сразу полином из комплексных чисел, причём вещественная и мнимая части взяты как в поле Q, так и в поле R (на всякий случай). Даже нет, это сразу матрицы из таких полиномов! Более того, матрицы могут быть наследниками некоего объемлющего суперкласса, который содержит в себе ещё какую-то информацию. Таким образом, операция 1+1 превращается в сложение двух матриц над полиномами над полем C. А цикл for i from 1 to 10^6 страшно подумать, что из себя представляет : ) Зато удобно : )

Цитата:
Поище про слово dump (полный дамп памяти процесса). Средство универсальное. Можете и свой вариант сделать. А для разбора дампа вам понадобится ещё и отладочная информация из-за чего потребляемый объем памяти вырастит до 2-х раз.

Средство-то универсальное, но было бы неплохо иметь поддержку его прямо в языке. Ведь лучше сохранять образ тогда, когда выполнен определённых этап работы (итерация цикла, например) и все данные синхронизированы, а временные объекты удалены. То есть чтобы можно было прямо в коде программы указывать точки восстановления.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 08 дек 2014, 17:12 
Аватара пользователя

Зарегистрирован: 14 мар 2011, 12:31
Сообщения: 938
Откуда: Дагоба
Zealint писал(а):
Различные функции и команды синхронизации также должны быть частью языка, как и прочие функции управления параллельными процессами и потоками. Представьте себе команды MPI или директивы OpenMP. Вот всё это должно наличествовать в языке не как надстройка, а как часть встроенной системы команд и операторов.

Категорически согласен.

Zealint писал(а):
Любой алгоритм, если он работает долго, выполняет какой-то набор шагов, которые условно можно разделить на ряд блоков, итераций или каких-то ещё структурных элементов. По запросу пользователя система просто обязана выдать позицию, на которой находятся вычисления.

Увы, это нереально. Наилучший выход - вставить в нужные места своей программы вывод информационно-диагностических сообщений типа "выполнено 999 итераций из 1000". А значит и поддержку info_level нужно делать самостоятельно.

Zealint писал(а):
И всё бы ничего, но система эта теплицева...

тЁплицева. Привычка вместо Ё писать Е (особенно в собственных именах) уже привела к массе недоразумений, например, искажению имён: Рёнтген, Депардьё, Рёрих, Чебышёв...

Zealint писал(а):
При всём при этом, указанная функция работает на порядки быстрее аналогичных функций, которые есть (если вообще есть) в других СКА.

Значит другие СКА сделаны ещё хуже! :D

Zealint писал(а):
Такого не должно быть в СКА. Система команд должна быть продумана очень хорошо, а если это невозможно сделать сразу, должен быть продуман стандарт, по которому будет расширяться система команд, чтобы не получилось так, что когда один пакет настолько обрастает ошибками или настолько выходит из-под контроля, что пишут второй (третий, четвёртый), который делает по сути то же самое или чуть больше, а первый оставляют для совместимости со всем мусором, там образованным.

Тут я бы разделил понятия. "Команды" - не совсем удачное определение. Есть синтаксические свойства языка, а есть библиотеки функций. То, о чём вы сейчас пишете, касается качества реализации библиотек, но это не завязано непосредственно на синтаксис. Хотя да, я полностью согласен, что реализации стандартных библиотек (а для СКА это, безусловно, математические библиотеки) необходимо уделать не меньшее внимание, чем самому языку.

Ряд ваших пожеланий (например, безопасность и точки восстановления) касаются не языка, а интерактивной среды. В рамках неё такие механизмы, полагаю, могли бы быть реализованы.

Zealint писал(а):
Цитата:
В моей практике в бинарном коде было. Называется фрагментация памяти.

Потому что нужно, чтобы ОС не фрагментировала память. А в сложных программах лучше выделять себе всю память одним куском и с ней работать, никогда не обращаясь к палёным менеджерам памяти ОС.

В принципе, фрагментация сама по себе не замедляет работу, если мы говорим о непрерывности расположения физических страниц. Но есть другой фактор - частая перезагрузка дескрипторов страниц, которые не помещаются в TLB при использовании большого объёма памяти. Для этого делают поддержку страниц большого размера (4МБ для процессоров Intel/AMD). Это действительно увеличивает скорость работы, причём иногда весьма значительно.

Zealint писал(а):
Огорчает то обстоятельство, что многие языки часто не позволяет спуститься на самый нижний уровень процесса программирования, поскольку язык не даёт возможности явно пользоваться инструкциями процессора или хотя бы косвенно вызывать их. Например, как по мнению читателя нужно сложить два 128-битных целых числа, которые в ЯП, в котором максимальная разрядность переменной составляет 64 бита, реализованы в виде пары таких переменных?

Приведен действительно удачный пример больного места вычислений на ЯВУ - работа с переносами, т.е. часть, имеющая непосредственную аппаратную реализацию, но никак не отражённую в языке. На самом деле почти любой компилятор поддерживает ассемблерные вставки. Казалось бы, их использование - это выход. Но он порождает другие проблемы, такие как усложнение синтаксиса языка, проверка типов и серьёзные сложности с машинно-независимой оптимизацией участков кода, содержащих такие вставки и верификацией их на корректность. Кроме того, такой код, несмотря на формальную принадлежность к языкам ВЫСОКОГО уровня (а значит, претензией на переносимость), автоматически теряют и высоту, и переносимость. Мой подход заключался бы в полном запрете на использование ассемблерных вставок. Машинно-оптимизированный код необходимо создавать в виде функций, полностью реализованных на ассемблере и компилируемых отдельно в объектные файлы.
Как быть с переносами в подобных примерах кода. Я вижу выход в разной размерности операнда и результата. Например, операция умножения может иметь 32-битные операнды и возвращать 64-битный результат (если таковой потребуется). Аналогично и с остальными операциями, кроме деления. Встречаясь с таким использованием, компилятор относительно легко мог бы понять смысл и оптимизировать код до пары ADD/ADC.

Zealint писал(а):
Язык и компилятор должны развиваться согласованно с архитектурой компьютера. То есть: либо архитектура и язык разрабатываются одновременно и друг для друга, либо язык разрабатывается под конкретную архитектуру (пусть даже виртуальную).

Вот тут, пожалуй, не совсем соглашусь, хотя направление мысли мне очень понятно. Действительно, если мы говорим про эффективность работы, то взаимозависимость полная - новая архитектура вряд ли сможет работать эффективно без поддержки со стороны инструментов программирования, а ЯВУ вряд ли смогут создать [значительно] более быстрый быстрый код для старых систем. Но есть одно "но". Если от архитектуры польза может быть оценена только по критерию скорости работы, то ЯВУ имеет и другие приоритетные факторы, такие как эффективность написания кода, защищённость языка от случайных ошибок, удобство его использования для разных задач. В этом смысле язык, обладающий новыми свойствами, мог бы послужить "паровозом" для новой архитектуры. А вот наоборот сделать сложно.


pavia писал(а):
Написание паральльных функций более чем в 5 раз сложнее обычных.

Вы уверены, что "более чем в 5", а не "менее чем в 2" или "примерно около 7"?
Совершенно безосновательное утверждение. Что-то сложней, а что-то, наоборот, проще. И самое главное - использование параллелизма неизбежно, весь вопрос только в том, чтобы сделать его поддержку максимально простой и удобной. Поэтому аргументы, что что-то там сложней, вообще не играют роли. Надо.

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.

<<< OS Boot Tools. >>>


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 08 дек 2014, 17:43 

Зарегистрирован: 21 сен 2007, 17:24
Сообщения: 1025
Откуда: Балаково
Zealint, возможно ваша цель немного ближе, чем кажется.
В GCC есть тип __int128 для целых чисел и long double для реальных (проверил, работает).
Так же есть автоматическая параллелизация при использовании ключа компиляции -fopenmp (не проверял). В общем случае ни каких специальных команд в программу вставлять не требуется, но можно и подкрутить ручками - справка по OpenMP http://gcc.gnu.org/onlinedocs

Можно так
#pragma omp parallel
{
код;
}

Или так
#pragma omp parallel for
for (...) {...}

Но эту конструкцию делать не требуется, по идее всё должно получаться автоматически, без всяких #pragma. Надо пробовать. В Windows MinGW этой библиотеки нету, нужен Unix или Cygwin.

В других компиляторах это тоже наверно есть.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: 08 дек 2014, 18:48 
Аватара пользователя

Зарегистрирован: 16 май 2007, 23:46
Сообщения: 1056
Himik
Если бы всё было просто, то ключа -fopenmp не было бы, а всё работало автоматом.
-fopenmp сильно снижает производительность. По крайней мере так было раньше. А что-бы не снижала надо всю программу усыпать директивами OpenMP.


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 285 ]  На страницу 1, 2, 3, 4, 5 ... 29  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
Создано на основе phpBB® Forum Software © phpBB Group
Русская поддержка phpBB