Здравствуйте Znow, Вы писали:
Z>Здравствуйте Ursus, Вы писали:
IO>>>Всем: машин много разных, но тем не менее у всех стоит двигатель внутреннего сгорания (и на легковых и на грузовых и т.д.).
U>>Не обязательно, еще ставится дизель.
Z>А что, двигатель Дизеля теперь стал двигателем внешнего сгорания?
Турбина тоже не внешного, давай те для общности и ее назовем двигателем внутренного сгорания
Да пребудет с тобой Великий Джа
Re[7]: Проэктируем новый язык программирования
От:
Аноним
Дата:
21.10.02 05:47
Оценка:
Здравствуйте Ursus, Вы писали:
IO>>>>Всем: машин много разных, но тем не менее у всех стоит двигатель внутреннего сгорания (и на легковых и на грузовых и т.д.).
U>>>Не обязательно, еще ставится дизель.
Z>>А что, двигатель Дизеля теперь стал двигателем внешнего сгорания?
U>Турбина тоже не внешного, давай те для общности и ее назовем двигателем внутренного сгорания
Дык, дизельный двигатель наряду с карбюраторным являются двигателями внутреннего сгорания.
Здравствуйте VladD2, Вы писали:
VD>Здравствуйте Hacker_Delphi, Вы писали:
HD>>Когда нужно написать программу под Intel x86, которая будет ОЧЕНЬ быстро искать прямым перебором (ну данные так устроены) данные в массиве int'ов — лучший выход — ассемблер
VD>Бред натуральный. Моежт данные отсорировать и хоть бинарным поиском воспользоваться? А там глядишь и VBScript в 100 раз шустрее асм-а окажетя.
Ешшо раз внимательно прочитай предположение — ДАННЫЕ ТАК УСТРОЕНЫ. Есть такие задачи... есть...
когда тебе нужно искать в ЧУЖОЙ памяти некоторые данные, причем память достаточно часто изменяется — единственный выход — это
LOCK REP SCASD
И никакой Ц тебе не даст такой возможности А работать это будет гораздо быстрее, чем реализация перебора на Ц++ с использованием циклов (ибо начиная с 5х86 перебор одного элемента цепочки занимает не больше одного такта процессора/памяти (зависит от того, влезли ли данные в кэш). VD>Переборы и циклы уже сто раз оптимизировалис компиляторами. Серьезного выигрыша (в разы) получить нельзя. Сегданя даже базовые алгоритмы на асм-е не пишут (бесполезно), а уж кусти прикладной логики на асм-е могут писать только его истенные ценители и в нерабочее время.
Начет бесполезно — ты не прав. Есть задачи, которые на АСМ решаются элегантнее и быстрее (выполнение). Вот если бы процессор сам исполнял и оптимизировал Ц код — вполне возможно, что он был бы быстрее, а так — не понятно . Хорошая реализация на ассемблере никогда не будет медленнее, чем реализация на Ц/Паскале и прочих языках программирования.
Если при компиляции и исполнении вашей программы не происходит ни одной ошибки — это ошибка компилятора :)))
Здравствуйте Аноним, Вы писали:
Z>>>А что, двигатель Дизеля теперь стал двигателем внешнего сгорания?
U>>Турбина тоже не внешного, давай те для общности и ее назовем двигателем внутренного сгорания
А>Дык, дизельный двигатель наряду с карбюраторным являются двигателями внутреннего сгорания.
Для общности определим так: ДВС — это тепловой двигатель, у которого рабочее тело и нагреватель суть одно, а рабочий объем ограничен.
Сюда включаются двигатели Дизеля и Отто (в первом поджиг — от адиабатического нагрева, во втором — от воспламенителя — искровой или калильной свечи), газотурбинные.
Реактивные двигатели (в том числе газотурбинные) отличаются способом отбора мощности.
Для подобных операций или существуют стандартные функции оптимизированные на асм-е или пишутся свои. Причем все это не означает, что всю логику програмы нужно писать на ассемблере. Если же ищется цепочка, то есть куда более эффективные алгоритмы поиска. При этом грамотно написанная С-шная функция будет в разы быстрее тупого перебора.
HD>А работать это будет гораздо быстрее
Ой ли? И часто ли встречаются столь маштабные и тупые переборы?
VD>>Переборы и циклы уже сто раз оптимизировалис компиляторами. Серьезного выигрыша (в разы) получить нельзя. Сегданя даже базовые алгоритмы на асм-е не пишут (бесполезно), а уж кусти прикладной логики на асм-е могут писать только его истенные ценители и в нерабочее время.
HD>Начет бесполезно — ты не прав. Есть задачи, которые на АСМ решаются элегантнее и быстрее (выполнение). Вот если бы процессор сам исполнял и оптимизировал Ц код — вполне возможно, что он был бы быстрее, а так — не понятно . Хорошая реализация на ассемблере никогда не будет медленнее, чем реализация на Ц/Паскале и прочих языках программирования.
Здравствуйте Anatolix, Вы писали:
VD>>Если что есть ансэйф-код. Там ты можешь хоть по памяти кувалдой. Так что Шарп из любого положения может.
A>Объясни мне pls подробнее про unsafe код в C# что это вообще такое и как это согласуется с IL. Или линк кинь.
IL — это ассемблер для вымышленного процессора который не имеет регистров и все операции выполняет над операндами помещенными в стек (тоже вымышленный). Перед исполнением этот вымышленный код компилируется в код совместимых с имеющимся процессором.
IL по своим возможностям не отличается от ассемблера. Ну разве что нельзя вызывать прерываний и писать в порты.
Ансэйф код в Шарпе — это возможность наплевать на GC с безопастностью и взять управление на себя (скатившись до уровня С). В Шустрике
Здравствуйте VladD2, Вы писали:
VD>Ансэйф код в Шарпе — это возможность наплевать на GC с безопастностью и взять управление на себя (скатившись до уровня С). В Шустрике
продемонстрирован вариант применения ансэйфа в Шарпе (ищи по словам unsafe и fixed).
А ну понятно, здесь кстати было невооруженным взглядом видно что все находится в пределах массива, цикл то по нему. Более интересно было бы с нетривиальным алгоритмом, например qsort-ом там оптимизатор вряд ли сможет сделать предположения.
Любая проблема дизайна может быть решена введением дополнительного абстрактного слоя, за исключением проблемы слишком большого количества дополнительных абстрактных слоев
Здравствуйте Anatolix, Вы писали:
VD>>Ансэйф код в Шарпе — это возможность наплевать на GC с безопастностью и взять управление на себя (скатившись до уровня С). В Шустрике
продемонстрирован вариант применения ансэйфа в Шарпе (ищи по словам unsafe и fixed).
A>А ну понятно, здесь кстати было невооруженным взглядом видно что все находится в пределах массива, цикл то по нему. Более интересно было бы с нетривиальным алгоритмом, например qsort-ом там оптимизатор вряд ли сможет сделать предположения.
Ну если вниательно посмотреть тесты, то можно обнаружить там тот самый алгоритс быстрой сортировки (qsort). На моей машине (Атлон 2100+) в ансэйф-режиме (при работе с указателями, т.е. без контроля границ массивов) 7.51 сек. и в обычном режиме (с контролем выхода за границу) 7.63 сек. В общем в реальных приложениях можно смело плевать на контроль границ массивов. Правда VC7 на том же тесте показывает 6.30 сек. Но это похоже из-за лучшей оптимизации.
Здравствуйте VladD2, Вы писали:
VD>Ну если вниательно посмотреть тесты, то можно обнаружить там тот самый алгоритс быстрой сортировки (qsort). На моей машине (Атлон 2100+) в ансэйф-режиме (при работе с указателями, т.е. без контроля границ массивов) 7.51 сек. и в обычном режиме (с контролем выхода за границу) 7.63 сек. В общем в реальных приложениях можно смело плевать на контроль границ массивов. Правда VC7 на том же тесте показывает 6.30 сек. Но это похоже из-за лучшей оптимизации.
Хм. Тогда я решительно не понимаю как это было сделано. Единственный вариант что intel процессор выполняет сравнение границ гораздо быстрее чем обращение к памяти(кстати вполне вероятно, т.к. в одном случае работа с памятью а в другом с регистрами). Надо попробовать просто на плюсах написать массив с проверкой границ и посмотреть что будет.
Любая проблема дизайна может быть решена введением дополнительного абстрактного слоя, за исключением проблемы слишком большого количества дополнительных абстрактных слоев
P>Конечно же, программируя на C++ я могу гордиться, мол моя программа будет даже на Sparc работать. Только будет это слишком самонадеяно, а самое главное: кто из нас Спарк хотя бы раз видел и трогал в живую?
Я. Скажу больше: "Программа на C++ && STL без проблемм работает и на WinIntel и на SunSparc"
Прошу прощения, что не уделял некоторое время внимание ветке.
Вы так много всего понаписывали, что аж лень читать.
Поэтому просмотрел только бегло.
Давайте так: сейчас речь не идет о компиляторах, платформах, быстроте, универсальности, синтаксисе и т.д. языков, которые уже существуют. Возьмем только концепции (парадигмы). И на их основе сформируем новую.
Можно законспектировать самые мощные и наиболее отличающиеся друг от друга языки.
Причем в какой-то отдельной части — поддержка отдельной парадигмы.
Так мы, для начала, имеем шанс свести воедино их концепции. И создать язык, для которого все существующие были бы подмножествами. Но это только половина дела. Вторая состоит в том, что-бы обеспечить механизмы наращивания (а не только синтаксиса, а самой концепции языка). Звучит неправдоподобно, ведь всегда должно оставаться что-то незыблимое в ядре компилятора. Так вот это "незыблимое" мы и минимизируем.
И еще: существует же псевдокод, который используется в книгах по программимрованию. И он реализуем на любом алгоритмическом языке.
Я не говорю, что это будет легко, или что это вообще 100% возможно, но попробовать стоит (в свободное время)
Здравствуйте IO, Вы писали:
IO>Цель в том, что-бы новый язык во-первых учитывал недостатки уже существующих. Во-вторых был бы универсальным для разных областей (сколько можно плодить эти языки). В-третьих имел бы заложенные мощные механизмы по наращиванию и расширению. Т.е. основная концепция должна быть достаточно универсальна (микро-ядро)?
IO>Цель в том, что-бы новый язык во-первых учитывал недостатки уже существующих. Во-вторых был бы универсальным для разных областей (сколько можно плодить эти языки). В-третьих имел бы заложенные мощные механизмы по наращиванию и расширению. Т.е. основная концепция должна быть достаточно универсальна (микро-ядро)? IO>Ваши мнения?
Моё мнение таково, что вы знаете слишком мало языков, чтобы осознать всю бессмысленность вашей идеи.
Неужели вы думете слелать язык с простым синтаксисом (бейсик), полной поддержкой ООП(Си++), возможности низкоуровневых операций (асм), с мощными регулярными выражениями (Перл), переносимый (Java) и прочее прочее (Пролог, Лисп и пр.).
Тут языки приведены примерно.
Это была бы кофеварка совмещённая с профессиональной звуковой студией и унитазом.
Если без эмоций, то просто есть разные задачи и есть языки, заточенные для их решения. Если вы имели в виду одну задачу (скажем написать под винду и с рюшечками), то это и надо было упоминать.
Здравствуйте Reinhard, Вы писали: R>Моё мнение таково, что вы знаете слишком мало языков, чтобы осознать всю бессмысленность вашей идеи.
Вполне возможно (даже скорее всего).
R>Неужели вы думете слелать язык с простым синтаксисом (бейсик), полной поддержкой ООП(Си++), возможности низкоуровневых операций (асм), с мощными регулярными выражениями (Перл), переносимый (Java) и прочее прочее (Пролог, Лисп и пр.).
А как вам язык с неопределенным синтаксисом? Т.е. сам синтаксис для компилятора неизвестен. Синтаксические модули просто подключаются и вы можете пользоваться удобной Вам формой (ведь в конечном итоге получиться все равно машинный код). Идея в том, что не надо ничего учить. Хотите свой диалект — пишите синтаксис, подключайте и вперед. И любой другой прочитает ваш код в своем диалекте.
Здравствуйте IO, Вы писали:
IO>А как вам язык с неопределенным синтаксисом? Т.е. сам синтаксис для компилятора неизвестен. Синтаксические модули просто подключаются и вы можете пользоваться удобной Вам формой (ведь в конечном итоге получиться все равно машинный код). Идея в том, что не надо ничего учить. Хотите свой диалект — пишите синтаксис, подключайте и вперед. И любой другой прочитает ваш код в своем диалекте.
Есть такая буква! Можно посмотреть здесь. Раздел 3.2. Правда там говорится, что сложность компилятора возрастает настотько, что язык общего назначения не представляется возможным построить... Плюс надо вооружиться нетривиальной теорией. А так — дело благое, так что флаг в руки.
IO>А как вам язык с неопределенным синтаксисом? Т.е. сам синтаксис для компилятора неизвестен. Синтаксические модули просто подключаются и вы можете пользоваться удобной Вам формой (ведь в конечном итоге получиться все равно машинный код). Идея в том, что не надо ничего учить. Хотите свой диалект — пишите синтаксис, подключайте и вперед. И любой другой прочитает ваш код в своем диалекте.
Эдакий XML для программера.
Тогда получается как бы язык для создания языков. Только это скорее другая задача.
Да и наверняка на этом нельзя будет написать ни одной программы, а надо будет сначала
синтаксис задать, а потом на этом субъязыке уже писать.
Это автоматически породит бесчисленное множество синтаксисов, по определению не совместимых
друг с другом. Один похож на Си++, другой — ПОЧТИ такой же, но бесплатный проект, третий
— тоже Си++, но мощный и глючной. Это только в одном напроавлении. Вокруг каждого создадутся
группки последователей, а синтаксис станет как бы новым языком, возможно со
специализированными компилерами.
В жизни уже есть пример — XML. На его основе можно делать синтаксисы. Только это порождает
новые языки, а не делает один универсальный.
А> Вот например сборка мусора в памяти, она позволяет уменьшить время потраченное на поиск разных утечек в памяти. Это реальный эффект. Что еще можно вспомнить на эту тему? Из вот таких нюансов и можно получить быстрое и надежное программирование.
Только спорный даже этот вопрос, потому как компилятор умеющий делать
только debug-программы — неоптимальный инструмент.
Я имею в виду язык без данной фичи (Си++ MS Visual), но с довесой
для этапа разработки типа NuMega BoundChecker.
Здравствуйте Аноним, Вы писали:
А>Здравствуйте IO, Вы писали:
IO>>Ваши мнения?
А>Чесно говоря я бы хотел иметь такой язык програмирования где пишешь что хочешь (на русском например) и он это выполняет.
А>(С) Ленивый програмист Петька А>ICQ: 70064374
Ой, Петька, не надо! А то если он выполнит то, что ты пишешь, очень беда может большая быть. Потому, что упомянутый русский например значительно сложнее, чем любой из существующих языков программирования. Вона, в форуме, столько программеров толковых, а москальску мову не розумеют ни черта. И в твоей этой фразе ошибок -[ правила форума запрещают обсуждение грамотности участников ]. Так что не надо такого языка программирования.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
А работать это будет гораздо быстрее, чем реализация перебора на Ц++ с использованием циклов (ибо начиная с 5х86 перебор одного элемента цепочки занимает не больше одного такта процессора/памяти (зависит от того, влезли ли данные в кэш).
Перекуём баги на фичи!
Только спорный даже этот вопрос, потому как компилятор умеющий делать
