Здравствуйте, thesz, Вы писали:
T>Последний из них http://thesz.mskhug.ru/svn/hhdl и он же самый интересный. Это не шутаут, это много прикольней. Это то, чего C++ никогда не сможет.
Что он не сможет то?
С++ не может только одного. Позволить написать большой объем кода без ошибок. Все остальное он позволяет. Всегда можно скатиться на уровень Си и писать практически на высокоуровневом ассемблере используя все преимущества железа.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
T>>Последний из них http://thesz.mskhug.ru/svn/hhdl и он же самый интересный. Это не шутаут, это много прикольней. Это то, чего C++ никогда не сможет.
VD>Что он не сможет то?
VD>С++ не может только одного. Позволить написать большой объем кода без ошибок. Все остальное он позволяет. Всегда можно скатиться на уровень Си и писать практически на высокоуровневом ассемблере используя все преимущества железа.
Как сказал, по-моему, Страуструп (к сожалению никак не могу найти эту цитату):
Любая фича, будучи реализованной в каком-то специальном языке, становится тривиальной для повторения в языке общего назначения.
Вопрос, конечно, в том, что её надо реализовывать. Но с другой стороны всё действительно полезное и нужное уже реализовано в каких-то библиотеках. А дальше какая разница — будь то дядя реализовал это в каком-то языке или в какой-то библиотеке. Вот даже сборщик мусора промышленный для С/С++ есть, чего уж там говорить о персистентных структурах и агентно-ориентированном программировании.
Здравствуйте, VladD2, Вы писали:
T>>Последний из них http://thesz.mskhug.ru/svn/hhdl и он же самый интересный. Это не шутаут, это много прикольней. Это то, чего C++ никогда не сможет.
VD>Что он не сможет то? VD>С++ не может только одного. Позволить написать большой объем кода без ошибок.
Так там оно и есть.
Большой объем хитрого кода.
На С++ без ошибок хрен напишешь.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, remark, Вы писали:
R>Вопрос, конечно, в том, что её надо реализовывать. Но с другой стороны всё действительно полезное и нужное уже реализовано в каких-то библиотеках. А дальше какая разница — будь то дядя реализовал это в каком-то языке или в какой-то библиотеке. Вот даже сборщик мусора промышленный для С/С++ есть, чего уж там говорить о персистентных структурах и агентно-ориентированном программировании.
Это огромное заблуждение. Есть множество вещей которые нельзя качественно реализовать в библиотеках.
Тот же ЖЦ отличный пример. Просто ЖЦ реализовать можно. Хороший — никогда. Основание элементарно. Хороший ЖЦ должен заниматься оптимизацией хипа. Это поразумевает перемещение блоков памяти. А это подразумевает исправление всех ссылко на них. Если язык не предоставляет возмонсти следить за ссылками. А С и С++ это принципиально сделать не позволяют, то и реализация универсального ЖЦ тоже невозможно.
Эта тема обсуждалась уже сто раз и мне она не интересна.
Я говорил о другом. Об оптимизации. Ежу понятно, что для конкретных условий языки вроде С++ позволяют создать решение максимально близкое к оптимальному. Вопрос только в том — чего это стоит?
Когда кода становится много, то оптимизировать его весь становится просто не реально, а стоимость ручной оптимизации становится слишком дорогой. Посему в реальных приложениях оптимизируются только критические места.
Когда кто-то пишет большое приложение на С++, то он старается применять набор практик позволяющих избежать ошибок и упростить разработку. Именно такие практики встраиваются в более высокоуровневые языки. Так что ординарный С++-код обычно мало отличается по скорости от ординарного кода на более высокоуровенвом языке.
С другой стороны в С++ больше простора для оптимизаций. Еще больше простора в ассемблере. Но тут разница в уровне языка и зависимость от конкретной аппаратуры становится настолько очевидной, что не многие решатся на использования ассемблера. Хотя уверен, что ту же задачу хамелеонов решить на ассемблере можно и эффективнее если делать это со знанием дела и провести много времени за тестированием.
В прочем, С тем и хорош, что позволяет оптимизировать не только программы на С.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>В Хамелионах то? Акстись. Это приципиально мелкая задачка со своими подводными камнями (неплохо описанными автором темы).
А давай ты еще раз посмотришь на что ты отвечал.
Процитирую чтобы далеко не ходить
T>>Конкретно этот эксперимент мне неинтересен, поскольку у меня своих покрупней и повыгодней есть штуки три. CC>О да!
Здравствуйте, VladD2, Вы писали:
VD>Это огромное заблуждение. Есть множество вещей которые нельзя качественно реализовать в библиотеках. VD>Тот же ЖЦ отличный пример. Просто ЖЦ реализовать можно. Хороший — никогда. Основание элементарно. Хороший ЖЦ должен заниматься оптимизацией хипа. Это поразумевает перемещение блоков памяти. А это подразумевает исправление всех ссылко на них. Если язык не предоставляет возмонсти следить за ссылками. А С и С++ это принципиально сделать не позволяют, то и реализация универсального ЖЦ тоже невозможно. VD>Эта тема обсуждалась уже сто раз и мне она не интересна. VD>Я говорил о другом. Об оптимизации. Ежу понятно, что для конкретных условий языки вроде С++ позволяют создать решение максимально близкое к оптимальному. Вопрос только в том — чего это стоит? VD>Когда кода становится много, то оптимизировать его весь становится просто не реально, а стоимость ручной оптимизации становится слишком дорогой. Посему в реальных приложениях оптимизируются только критические места. VD>Когда кто-то пишет большое приложение на С++, то он старается применять набор практик позволяющих избежать ошибок и упростить разработку. Именно такие практики встраиваются в более высокоуровневые языки. Так что ординарный С++-код обычно мало отличается по скорости от ординарного кода на более высокоуровенвом языке. VD>С другой стороны в С++ больше простора для оптимизаций. Еще больше простора в ассемблере. Но тут разница в уровне языка и зависимость от конкретной аппаратуры становится настолько очевидной, что не многие решатся на использования ассемблера. Хотя уверен, что ту же задачу хамелеонов решить на ассемблере можно и эффективнее если делать это со знанием дела и провести много времени за тестированием. VD>В прочем, С тем и хорош, что позволяет оптимизировать не только программы на С.
Реализовать некоторые вещи на 100% в библиотеке не получится. Согласен. Но я думаю, что можно их реализовать так скажем хотя бы на 80%, т.е. получить основную суть фичи, получить основные преимущества.
ГЦ наверное одна из самых сложных вещей в этом плане, а вот если взять например что-нибудь типа персистентных структур данных и операций над списками в стиле Лисп, то вообще никаких проблем не видится. Конечно если у человека в голове "я хочу программировать на необычном математическом языке", то тут это не поможет; а если задача просто получить преимущества персистентных структур данных, то тут никакой принципиальной разницы между встроенной поддержкой и С++ библиотекой я не вижу.
Вещь посложнее — агентно-ориентированное программирование в стиле Эрланг. Практически всё можно реализовать не хуже, чем в Эрланг. Единственная проблема — очень долго выполняющиеся обработчики сообщений, т.к. они едят стек. В целом это решается, возможно с какими дополнительными практически выполнимыми ограничениями.
Что касается ГЦ. Ну Boehm GC обеспечивает основную гарантию — безопасность (объект не будет удалён пока используется). В качестве оптимизации, например, можно указывать при аллокации блока памяти, что в этом блоке нет указателей (строки, мыссивы чисел). Сложно ли это указывать в некоторых местах на практике? Не особо. Это даже можно встроить в библиотечные классы строк и массивов.
Другой момент — в ГЦ языке просто нет выбора как использовать ГЦ для всех объектов. В программе на С/С++ это может быть совсем не необходимо. ГЦ может быть целесообразно использовать только для каких-то объектов, для которых проблемно управлять временем жизни другими средствами. В такой ситуации можно использовать умные указатели, которые будут говорить ГЦ библиотеке, где управляемые объекты, и где в них сидят ссылки на другие управляемые объекты.
Другой пример — я сейчас делаю библиотеку по управлению временем жизни, она использует поколения для оптимизации. Автоматическое определение и продвижение объектов по поколениям реализуемо, но достаточно проблематично. Поэтому пользователь при создании объекта просто указывает поколение для объекты (обычный, долго живущий, совсем долго живущий). Сложно ли это задавать на практике? По-моему, не особо. В конце-концов пользователь должен понимать, что за объект он создаёт. Ну и опять же это исключительно оптимизация.
Или вот взять например SQL. В чём проблема его реализовать? Разве что синтаксис будет немного другой. Тем более скорее всего не нужно будет его реализовывать в полном объёме, плюс можно реализовать что-то чего нет в SQL.
В общем, мой тезис такой, что получить полную копию фичи, включая синтаксис, в некоторых случаях не получится. Но всегда можно получить основную суть фичи, основные её преимущества. Поэтому говорить, что что-то *принципиально* не доступно в языке общего назначения, я считаю, не правильно. Что касается принципиальной недоступности, так это как раз и относится к специальным языкам. Я думаю, что примеры для таких языков как Erlang, SQL, Lisp каждый может придумать сам. А в языке общего назначения никакие фичи не недоступны, вопрос только в цене реализации, синтаксисе, несколько меньшем контроле со стороны компилятора и т.д. Это я и считаю одним из основных преимуществ языков общего назначения.
Кстати, такие вещи не обязательно реализовывать в библиотеках. Пара примеров.
Intel реализовал в своём компиляторе С++ поддержку STM (Software Transactional Memory). Фича, не уступающая по сложности ГЦ.
Cilk Arts реализовала в компиляторе GCC, поддержку пары новых ключевых слов для своей системы параллельного программирования Cilk++. Они сводятся в основном к созданию замыканий.
С++/CLI практически С++ со сборкой мусора.
Собственно "чистым С++" никто никогда особо и не пользовался, все пользуются "реализациями с расширениями". А что там может быть — да что угодно, если это нужно и важно и в библиотеке не реализовать.
з.ы. Ты написал "Есть множество вещей которые нельзя качественно реализовать в библиотеках", что ещё кроме ГЦ?
Здравствуйте, remark, Вы писали:
R>Интересно было бы сделать реализацию на С с использованием fibers. На Windows их переключение примерно раз в 40 быстрее переключения ядерных потоков, т.к. там всего пара десятков инструкций. Насколько я понимаю такую реализацию не примут, т.к. там запрещено использование кооперативного планирования (хотя не понятно, языки с легковесными потоками её используют; а фиберы предоставляет ОС, что практически тоже самое для С). Но будет интересно сравнить "легковесность" с процессами Эрланг.
Насколько я знаю, fibers как раз не предоставляются ОС, а реализуются полностью в пространстве пользователя (наподобие setjmp/longjmp)? Там может не быть ни одного системного вызова (хотя glibc вызывает sigprocmask(2) внутри swapcontext(3)). В POSIX-системах есть <ucontext.h> с getcontext/setcontext/makecontext/swapcontext и обертка над ними GNU Pth, можно попробовать поиграться с ними.
И можно ссылку на место, где запрещается кооперативное планирование?
Programs may use kernel threads, lightweight threads; but coroutines, cooperative threads and other programs with custom schedulers will be listed as interesting alternative implementations. Briefly say what concurrency technique is used in the program header comment.
Здравствуйте, remark, Вы писали:
R>Здравствуйте, thesz, Вы писали:
R>>>Если ты говоришь, о том, что можно сделать эффективную реализацию на Haskell, образно выражаясь, "скопировав" реализацию на С, то привязки потоков к ядрам не достаточно. Очень сильно не достаточно. Необходимы все 4 момента, которые я описал, включая определение топологии системы. Отсутствие любого из них увеличит время выполнения в разы.
T>>У тебя четыре пункта, отставание у Хаскеля в пять раз. Если каждый пункт обеспечивает ускорение в разы (в два раза), то твоя программа должна опережать Хаскельную в 16 раз. Чего мы не наблюдаем.
R>Зависимость не линейная.
Иными словами, ты сам толком не знаешь, что же в твоём подходе самое важное.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, thesz, Вы писали:
T>>Последний из них http://thesz.mskhug.ru/svn/hhdl и он же самый интересный. Это не шутаут, это много прикольней. Это то, чего C++ никогда не сможет.
VD>Что он не сможет то?
VD>С++ не может только одного. Позволить написать большой объем кода без ошибок. Все остальное он позволяет. Всегда можно скатиться на уровень Си и писать практически на высокоуровневом ассемблере используя все преимущества железа.
Думая ответить на твой предыдущий ответ мне, я хотел попросить тебя читать сообщения перед тем, как на них отвечать.
Поскольку я решил не отвечать на тот твой ответ мне, прошу тебя в этом ответе: Влад, читай, пожалуйста, сообщения, на которые собираешься отвечать.
Ведь если бы ты прочитал моё сообщение, ты бы понял, что речь идёт о языке описания аппаратуры, встроенном в Хаскель, и позволяющем использовать некоторые полезные возможности Хаскеля. Например, алгебраические типы данных.
Вот алгебраические типы данных C++ не сможет внести в SystemC никогда.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
R>>Зависимость не линейная. T>Иными словами, ты сам толком не знаешь, что же в твоём подходе самое важное.
Жжошь!
Иди, перечитай заметку еще раз. Потому как ты нифига не понял смысла того, что там написано.
Здравствуйте, CreatorCray, Вы писали:
CC>Ошибки ловятся и исправляются. Это не total show-stopper.
Пожалуйста перелови все переполнения буфера в линуксе.
Да и мне нужно строгое доказательство что их там не осталось.
И это весьма примитивные ошибки...
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Пожалуйста перелови все переполнения буфера в линуксе. WH>Да и мне нужно строгое доказательство что их там не осталось. WH>И это весьма примитивные ошибки...
Гы. Аргументы пошли сильные.
Пожалуйста, перепиши Линукс на языке, который не допустит ни одного переполнения буфера.
Флейм это всё, флейм.
Здравствуйте, Nuzhny, Вы писали:
WH>>Пожалуйста перелови все переполнения буфера в линуксе. WH>>Да и мне нужно строгое доказательство что их там не осталось. WH>>И это весьма примитивные ошибки... N>Гы. Аргументы пошли сильные.
Я просто предельно наглядно показал что переловить даже примитивные ошибки в большой программе на С/С++ задача не решаемая.
Как следствие бравада что типа "мы тут ща все ошибки исправим" мягко говоря не уместна.
N>Пожалуйста, перепиши Линукс на языке, который не допустит ни одного переполнения буфера.
Если я и буду писать ОСь на правильном языке то она будет очень сильно отличаться от линукса.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
.
