Ответ на »сообщение 5043« (info21)
___________________________

Речь о простой как репа вещи:

если в лиспе я вынужден моделировать, скажем, моном как список, прицепленный к чему-то, то, работая в Обероне, могу вместо ссылки на список вместе со всем списком просто определить поле-массивчик. Тогда вся эта подструктурка данных хранится в contiguous memory block, и вся работа с ней локализована. (При том, что и экономия памяти немалая.) В зависимости от задачи, конечно.

1. См. »сообщение 5045«.

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

Подкреплять тестами я ничего не буду -- меня мой опыт и так устраивает.


... Зелен виноград. :-)

Ответ на »сообщение 5043« (info21)
___________________________

если в лиспе я вынужден моделировать, скажем, моном как список, прицепленный к чему-то, то, работая в Обероне, могу вместо ссылки на список вместе со всем списком просто определить поле-массивчик. Тогда вся эта подструктурка данных хранится в contiguous memory block, и вся работа с ней локализована. (При том, что и экономия памяти немалая.) В зависимости от задачи, конечно.

Ну вообще-то в Лиспе тоже есть структуры. Вообще, по исследованиям самих же лисперов, в программах на Лиспе в основном используются не списки, а другие типы данных... Массивы, структуры, объекты...

Ответ на »сообщение 5041« (Lisp Hobbyist)
___________________________

... Так что качество реализации машинной арифметики с плавающей точкой рановато списывать со счетов.

К чему бы это...

Ответ на »сообщение 5040« (Lisp Hobbyist)
___________________________

Эк как лисперы с полунамека... 8))

Речь о простой как репа вещи:

если в лиспе я вынужден моделировать, скажем, моном как список, прицепленный к чему-то, то, работая в Обероне, могу вместо ссылки на список вместе со всем списком просто определить поле-массивчик. Тогда вся эта подструктурка данных хранится в contiguous memory block, и вся работа с ней локализована. (При том, что и экономия памяти немалая.) В зависимости от задачи, конечно.

Типа. Подобные вещи не сложны, их много где можно использовать, и в интеграле дают большой, даже огромный эффект, для понимания которого никаких тестов не надо -- один или два порядка -- какая разница, главное, что много.

Подкреплять тестами я ничего не буду -- меня мой опыт и так устраивает.

На странице исследовательской группы проф. Гуткнехта (Programming Languages and Runtime Systems Group) выложена реализация языка Composita с исходными текстами (включая исходники ран-тайма), а также с набором тестов производительности и парой примеров приложений. См. http://www.jg.inf.ethz.ch/wiki/ComponentLanguage/Front

Component System (160kb, 29 June 2007).

The Component language is implemented by two systems:

- First, there is the development system, on which new component programs can be edited and compiled. This is a usual Oberon installation with the component compiler provided in the package above.

- Second, there is a runtime system, on which the the compiled programs can be executed. It is a small operating system which has been specifically designed to support the concepts of the new language very efficiently. As target platform, the runtime system runs on any PC-compatible Intel x86 single or multi-processor machine (with normal ATA disk support).

To use the compiler and runtime system, extract the package above under an Oberon installation (AOS) and follow the instructions in 'ComponentSystem.Tool' file. The source code of the runtime system is here available.

Applications

The following applications have been currently developed in Composita:

- Traffic Simulation Package (144kb, 29 June 2007).

- Typical Concurrent Programs (8kb, 29 June 2007)

The packages also contain analogous implementations in other programming languages to compare the runtime performance.

Ответ на »сообщение 5037« (Борис Рюмшин)
___________________________


Есть численные методы (классика порочная), аналитические методы (символьные, компьютерная алгебра), числено-аналитические методы, а также интервальные численные методы.

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


Известные мне реализации интервальной арифметики большей частью основаны на все тех же машинных вещественных числах, что и "порочная классика" (в остатке имеем реализацию вещей наподобие dotprecision в Pascal XSC, но это не связанно напрямую с интервальностью). Отличие лишь в алгоритмах вычислений (например, использование направленных округлений). Соответственно, если реализовать интервалы поверх вещественного формата одинарной точности, минимальный достижимый диаметр интервала будет хуже, чем для двойной. Так что качество реализации машинной арифметики с плавающей точкой рановато списывать со счетов.

Ответ на »сообщение 5035« (info21)
___________________________

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

Слова знатока лиспа :))


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

1. Лисперы, причем не только знатоки, но и даже многие любители, осведомлены о влиянии различных алгоритмов "сборки мусора" (incremental GC, ephemeral aka generational GC) на локальность обращений к памяти. Более того, они даже в курсе, кто, когда и для какого языка эти алгоритмы первоначально разрабатывал. (Соотв. статьи H. Baker'а и D. (?) Moon'а желающие могут поискать самостоятельно.) Впрочем, лисперы также не отрицают возможности применения этих алгоритмов (со всеми их плюсами и минусами) в реализации других языков.

2. Прагматичные лисперы (коих большинство, например, если я не напутал, R. Fateman, автор статьи "Fast floating point processing in Lisp") не испытывают особых комплексов из-за того, что критичные к быстродействию части системы будут реализованы на иных, более близких к железу, языках и подключены через FFI. Более того, они не преминут воспользоваться изрядным опытом автоматической генерации программ, накопленным в Лиспе, чтобы не писать этот код вручную.

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

А вот мы в Обероне умеем локализовывать данные, так что и со списками кэш L2 работает. Иногда.

Как насчет публично доступных воспроизводимых тестов, показывающих данное достижение, причем подкрепленных показаниями кэш-профайлера?

Ответ на »сообщение 5036« (Geniepro)
___________________________

А каккие же типы вещественных данных используются в "новой" науке? Single?

Речь не шла о новой науке. Наука старая.

Отход не означает новых вещественных данных, а увеличение доли невещественных -- за счет динамических структур данных, коих тем боле, чем умнее алгоритмы.

Ответ на »сообщение 5034« (Lisp Hobbyist)
___________________________

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

Ну может мы доживём до тех славных времён, когда вся память будет работать на одной скорости с процессорами. :):):)

Ответ на »сообщение 5036« (Geniepro)
___________________________

Ответ на »сообщение 5035« (info21)
___________________________

Лучше говорить про "старонаучные" расчеты. В новонаучных от этого отход имеет место. Так что...

А каккие же типы вещественных данных используются в "новой" науке? Single?

Есть численные методы (классика порочная), аналитические методы (символьные, компьютерная алгебра), числено-аналитические методы, а также интервальные численные методы.

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