Forth
http://fforum.winglion.ru/

RFS, замечания от Ethereal
http://fforum.winglion.ru/viewtopic.php?f=36&t=2764
Страница 6 из 8

Автор:  вопрос [ Пн окт 03, 2011 22:39 ]
Заголовок сообщения:  Re: RFS, замечания от Ethereal

chess писал(а):
В результате без вершины стека в регистре не обошлись. Оптимальность как всегда достигается комплексно, и каждая деталь вносит свой вклад в конечный результат, причем вносит именно в комплексе с другими деталями, а не по отдельности.

Хищник может отстаивать любую точку зрения, но наш долг напомнить ему, что большинство точек зрения несовершенны. И его т.з. может тоже поменяться: почему большинство программ написано на С ?
Ведь множество языков,создаваемых под самые разные программы, разве они не показывают пути решения разных задач? Ответ содержится в факте, что "сложные и концептуальные языки" имеют ретрансляторы ... на С :? Почему на С? Почему есть форт2С, пролог2С, Эйфория2С ? Не нужно гадать - ответ даётся прямым текстом : (приблизительная цитата) "перенеся ваши программы на С, вы сможете добиться большей производительности"

и это преимущество транслятоора концептуального языка - наличие "язык2с" - это сильно поднимает его

Потому является, я думаю, либо ошибкой либо шуткой утверждение Хищника о том, что для повышения производительности нужно "купить новый процессор" или разогнать этот или написать кусок кода на ассемблере :D ... судя по тенденции создания "язык2с" в мировом сообществе мало кто так считает

Автор:  Hishnik [ Пн окт 03, 2011 22:44 ]
Заголовок сообщения:  Re: RFS, замечания от Ethereal

Alexander писал(а):
Возможен выход из этой ситуации введением дополнительных словарей с именами ARITHMETIC и LOGIC и после ваша система будет генерировать правильные последовательности машинных команд в зависимости от того какой словарь сейчас активен и каким образом оптимизировать 2 / в 2/ ,- в арифметический сдвиг или операцию деления.

Ой, если еще и это помнить... Нет, я все же склоняюсь к тому, чтобы 2/ было быстрым сдвигом, при наличии разъяснения, что же это такое на самом деле. Неужели трудно поправить программу при необходимости?

Автор:  Alexander [ Пн окт 03, 2011 22:56 ]
Заголовок сообщения:  Re: RFS, замечания от Ethereal

Хищник писал(а):
Ой, если еще и это помнить... Нет, я все же склоняюсь к тому, чтобы 2/ было быстрым сдвигом, при наличии разъяснения, что же это такое на самом деле. Неужели трудно поправить программу при необходимости?


)) Тогда проще не употребялть никаких слов с неодноозначным пониманием...
а то наберется вагон исключений и чот тогда смотреть в него всякий раз в этот вагон?
Давайте проще - коментировать некотрые действия где используются такие слова - вообще супер метод без затрат. Ведь комментарий написать в коде нетрудно.
Это шутовство - зачем нам AND заменим его звездочкой *,
а лучше словом /\, потму что так как в книге будет

Автор:  Hishnik [ Вт окт 04, 2011 01:11 ]
Заголовок сообщения:  Re: RFS, замечания от Ethereal

вопрос писал(а):
Ответ содержится в факте, что "сложные и концептуальные языки" имеют ретрансляторы ... на С Почему на С? Почему есть форт2С, пролог2С, Эйфория2С ? Не нужно гадать - ответ даётся прямым текстом : (приблизительная цитата) "перенеся ваши программы на С, вы сможете добиться большей производительности"

и это преимущество транслятоора концептуального языка - наличие "язык2с" - это сильно поднимает его

Ох, да не столько поднимает, сколько вообще дает возможность существовать. Си есть на подавляющем большинстве платформ, преобразовав текст в Си, можно воспользоваться его компилятором, библиотеками, оптимизатором и т.д. Ну зачем бы, имея концепцию, заниматься повторением вещей, переработка которых в исходные планы не входила? Пусть их сделает мейнстримовый продукт.
вопрос писал(а):
Потому является, я думаю, либо ошибкой либо шуткой утверждение Хищника о том, что для повышения производительности нужно "купить новый процессор" или разогнать этот или написать кусок кода на ассемблере ... судя по тенденции создания "язык2с" в мировом сообществе мало кто так считает

Вот уж искаженная интерпретация! Мировое сообщество еще слушает Интел. Который давно не использует тактовую частоту в качестве обозначения марки процессора. А еще на последнем IDF указал на субъективное ощущение в 0,2 секунды как на "быструю реакцию" компьютера. То есть за это время после нажатия клавиши или кнопки мыши должно начать что-то происходить. Все! Никакие кривые, показывающие все большую привлекательность программы при дальнейшем уменьшении времени реакции, показаны не были. Еще можно привести такие критерии, как проигрывание HD video и более 50 fps в игрушке. Дальнейшее повышение производительности в этих задачах не улучшает потребительских качеств программы, а там, где производительность действительно важна, ее достигают никак не оптимизацией перекладок значений в регистрах. Мы уже не в конце 90-х живем - графика во многом определяется видеокартой. А еще есть разница между DDR1066 и DDR1333. А еще - между оборотами шпинделя HDD в 5400 и 7200. А еще есть мультипроцессорные системы, CUDA и FPGA. А оптимальный код - это как раз из 90-х :) Сейчас в силу высокой сложности многих программ выбор может стоять как "или на том, на чем есть возможность, или вообще ничего". Просто потому, что программисты с нужными навыками откажутся себя загонять в жесткие рамки эффективного кодогенератора и справедливо заметят, что тут вообще бы написать хоть на чем-нибудь. Пусть с меньшей производительностью, но иначе эту задачу не осмыслить.

Автор:  chess [ Вт окт 04, 2011 08:08 ]
Заголовок сообщения:  Re: RFS, замечания от Ethereal

Хищник писал(а):
А что значит "поддерживать"? Языки программирования специфицируют типы данных. Перенос имеет утилитарное значение - увеличение разрядности обрабатываемых чисел по сравнению с разрядностью процессора.

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

Автор:  вопрос [ Вт окт 04, 2011 11:02 ]
Заголовок сообщения:  Re: RFS, замечания от Ethereal

Хищник писал(а):
Ох, да не столько поднимает, сколько вообще дает возможность существовать.

это ещё более сильная характеристика
Хищник писал(а):
А оптимальный код - это как раз из 90-х

Это самовнушение??? 2 или 4 ядра - это 2 или 4 ядра - это производительность большая менее чем в 2 или 4 раза, а трудоёмкость по согласованию потоков большая на порядок, тогда как оптимальный код - оптимальный код и отличаться может как-раз на порядок

Цитата:
А еще на последнем IDF указал на субъективное ощущение в 0,2 секунды как на "быструю реакцию" компьютера. То есть за это время после нажатия клавиши или кнопки мыши должно начать что-то происходить. Все! Никакие кривые, показывающие все большую привлекательность программы при дальнейшем уменьшении времени реакции, показаны не были.
Субьективно, ощущение "летает" последний раз было от 450 мегагерцевого ... как же его ... не помню, кажется Mendocino
затем просто "работает" или "тормозит"

Нужно говорить что-то одно
или "35 проходов - оптимизация - наука, для которой ..." или то, что выше

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

Автор:  chess [ Вт окт 04, 2011 12:05 ]
Заголовок сообщения:  Re: RFS, замечания от Ethereal

вопрос писал(а):
Субьективно, ощущение "летает" последний раз было от 450 мегагерцевого ... как же его ... не помню, кажется Mendocino
затем просто "работает" или "тормозит"

Нужно говорить что-то одно
или "35 проходов - оптимизация - наука, для которой ..." или то, что выше

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

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

Автор:  mOleg [ Вт окт 04, 2011 14:57 ]
Заголовок сообщения:  Re: RFS, замечания от Ethereal

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

S>D SD* SD/ UM* M* UM/MOD /MOD */ и другие

Автор:  вопрос [ Вт окт 04, 2011 16:29 ]
Заголовок сообщения:  Re: RFS, замечания от Ethereal

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

Вообще (почему Хищник шутит) такого быть не может, но нужно ли кого-то переубеждать?
Разве что я могу предположить что
- запутывание кода с целью недопущения пиратства даёт дополнительное преимущество тем, кто ускоряет процессоры, поскольку код при этом замедляется
- код специально замедляется

На самом деле, идёт постоянное приращение скорости кода с освоением новых возможностей, сравнить только прологи

какое-то время назад считался самым быстрым BIN
теперь самый медленный SWI его обходит, а более медленный GNU теперь в 4 раз быстрее, чем был и чем SWI

Автор:  вопрос [ Вт окт 04, 2011 16:35 ]
Заголовок сообщения:  Re: RFS, замечания от Ethereal

mOleg писал(а):
S>D SD* SD/ UM* M* UM/MOD /MOD */

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

Автор:  mOleg [ Вт окт 04, 2011 17:31 ]
Заголовок сообщения:  Re: RFS, замечания от Ethereal

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

А к чему это вы?
Я ответил на странное утверждение (а может и не утверждение, но странное) в том смысле, что да, есть, во всех стандартах есть. К чему разговор о двойной арифметике-то?

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

Автор:  chess [ Вт окт 04, 2011 18:47 ]
Заголовок сообщения:  Re: RFS, замечания от Ethereal

mOleg писал(а):
S>D SD* SD/ UM* M* UM/MOD /MOD */ и другие

О чем это вы? Я говорил не о поддержке двойной разрядности, а о поддержке наращивания разрядности. Разницу не видите?

Автор:  mOleg [ Вт окт 04, 2011 19:00 ]
Заголовок сообщения:  Re: RFS, замечания от Ethereal

chess писал(а):
а о поддержке наращивания разрядности. Разницу не видите?

BIGMATH 64 Bit Math with Rational Approximations

Автор:  Hishnik [ Вт окт 04, 2011 23:24 ]
Заголовок сообщения:  Re: RFS, замечания от Ethereal

Мне вот интересно, если все с кодом так замечательно, откуда берутся новые компиляторы, новые языки? Новые процессоры, наконец? И зачем какие-то графические ускорители, если главное - оптимизировать код?

Автор:  Hishnik [ Вт окт 04, 2011 23:26 ]
Заголовок сообщения:  Re: RFS, замечания от Ethereal

chess писал(а):
О чем это вы? Я говорил не о поддержке двойной разрядности, а о поддержке наращивания разрядности. Разницу не видите?

Ее надо именно наращивать? Просто доработать ядро при необходимости нельзя?

Страница 6 из 8 Часовой пояс: UTC + 3 часа [ Летнее время ]
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
http://www.phpbb.com/