In April 1981, after a DARPA-sponsored meeting concerning the splintered Lisp community, Symbolics, the SPICE project, the NIL project, and the S-1 Lisp project joined together to define Common Lisp. Initially spearheaded by White and Gabriel, the driving force behind this grassroots effort was provided by Fahlman, Daniel Weinreb, David Moon, Steele, and Gabriel. Common Lisp was designed as a description of a family of languages. The primary influences on Common Lisp were Lisp Machine Lisp, MacLisp, NIL, S-1 Lisp, Spice Lisp, and Scheme. Common Lisp: The Language is a description of that design. Its semantics were intentionally underspecified in places where it was felt that a tight specification would overly constrain Common Lisp research and use.
ГВ>In 1986 X3J13 was formed as a technical working group to produce a draft for an ANSI Common Lisp standard. Because of the acceptance of Common Lisp, the goals of this group differed from those of the original designers. These new goals included stricter standardization for portability, an object-oriented programming system, a condition system, iteration facilities, and a way to handle large character sets. To accommodate those goals, a new language specification, this document, was developed.
ГВ>Как видишь, горячим финским парням было что описывать в 1986-м.
Как раз не вижу. Это все равно, что описывать С++ в 1979-ом.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Источник?
Отбой. Нашёл, на что ты ссылался:
The major contributions of Scheme were lexical scoping, lexical closures, first-class continuations, and simplified syntax (no separation of value cells and function cells). Some of these contributions made a large impact on the design of Common Lisp.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, VladD2, Вы писали:
ГВ>>Как видишь, горячим финским парням было что описывать в 1986-м.
VD>Как раз не вижу. Это все равно, что описывать С++ в 1979-ом.
ты б хотя бы повикипедил бы, вот тебе такая книга (1984-й) http://en.wikipedia.org/wiki/Common_Lisp_the_Language
по последним постам видно что не в теме как раз таки ты, и, как ты там говорил, "пытаешься выйти сухим из воды".
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Отбой. Нашёл, на что ты ссылался:
ГВ>
The major contributions of Scheme were lexical scoping, lexical closures, first-class continuations, and simplified syntax (no separation of value cells and function cells). Some of these contributions made a large impact on the design of Common Lisp.
В общем, бессмысленный исторический экскурс.
Даже если какие-то там фины умудрились написать книжку про промежуточную версию CL в которой и правда замыкания не были реализованы до конца — это никак не говорит в пользу того, что это правильный подход.
Сейчас ты не найдешь ни одной реализации CL где были бы неполноценные замыкания. Решение принятое в С++ (точнее пока не принятое) как раз свидетельствует о курсе его авторов — плевать на концептуальную целостность и удобство, если это может повредить скорости. Лучше все будет работать с тучей оговорок и вызовет тучу проблем у программистов, но не будет влиять на производительность.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Даже если какие-то там фины умудрились написать книжку про промежуточную версию CL в которой и правда замыкания не были реализованы до конца — это никак не говорит в пользу того, что это правильный подход.
Да меня не волнует, правильный это подход или нет. Я за что купил, за то продаю — вот такие сведения у меня есть, ты их можешь принять во внимание или послать подальше — твоё право. Более надёжных источников, относящихся к тому периоду у меня нет.
Здесь два соображения. Первое — что какими бы "какими-то" эти финны ни были, но их книга издана и в Финляндии, и в СССР. Второе — что описанный подход вполне соответствует идее об устранении побочных эффектов (чистоты) в функциональных программах. По-моему, вполне достаточные основания считать, что подобная реализация замыканий имела место быть в определённом историческом периоде и можно даже допустить, что серьёзно обсуждалась в качестве "правильной".
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, VladD2, Вы писали:
ГВ>>Как видишь, горячим финским парням было что описывать в 1986-м. VD>Как раз не вижу. Это все равно, что описывать С++ в 1979-ом.
Бедняга Страуструп, он и не знает, что ARM в первом издании (тоже 1986, как и Мир Лиспа) описывала несуществующий язык.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Lloyd, Вы писали:
ГВ>>Может быть. Языков без спецификаций не бывает. L>Из чего с необходимостью следует, что Nemerle не язык.
У Nemerle есть ещё один недостаток, не позволяющий считать его языком — полное отсутствие стандарта ANSI.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>>>Как видишь, горячим финским парням было что описывать в 1986-м. VD>>Как раз не вижу. Это все равно, что описывать С++ в 1979-ом. ГВ>Бедняга Страуструп, он и не знает, что ARM в первом издании (тоже 1986, как и Мир Лиспа) описывала несуществующий язык.
Ой, опять я поторопился: ARM вышла в 90-м (всё равно — до появления C++ ).
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, gandjustas, Вы писали:
G>>>Приведи парочку компиляторов С++ промышленного качества, в которых аллокация по кардинально другом алгоритму делается. ГВ>>При чём тут компиляторы? Управление памятью — это библиотеки. G>new и delete — часть языка. Неважно через что они реализуются.
Именно. А реализуются они библиотечными функциями. new/delete — конструкции языка, а то, что под ними лежит на самом деле — вопрос библиотек.
G>А по сущству есть что сказать? Или ты честно считаешь что в своем проекте будешь вмеесто стандартных new, delete и всего что с ними связано применять тот код, который привел CreatorCray?
Если мне приспичит подменить реализацию всех new/delete я просто заменю RTL-ные malloc/realloc/free. Это первый вариант. Второй вариант — переопределю глобальные new/delete. Третий вариант — определю нужные new/delete для необходимых классов. И ты знаешь, во всех этих случаях даже shared_ptr останутся работоспособными. Непосредственно ThreadPoolAlloc::Alloc/Free само собой, я везде писать не буду.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, VladD2, Вы писали:
VD>Даже если какие-то там фины умудрились написать книжку [...]
Я решил немного покопаться на предмет персоналий авторов. Нашлась страничка, посвящённая Эро Хювенену, там есть библиография. С Юко Сеппяненом вышло сложнее — мелькает на разных симпозиумах по искусственному интеллекту, да кое-что в ACM (искать по автору Jouko J. Seppänen, считанные публикации за 1970-1982 г). Оба, как я понял, из Технологического университета Хельсинки.
Ну разве это серьёзные лисперы? Да это ж курам на смех! Мальчонки, погулять вышли.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Х>>>какие оверхеды? концепция с++: не плати за то что не используешь, G>>Да ну, а O(n) при выделении и освобождении памяти? Х>здесь поподробней пожалуйста, что имеется ввиду?
Подробнее — в Красной Книжке приснопамятного Александреску, глава 4. И в Зелёной Книжке Рихтера, глава 20.
Здравствуйте, gandjustas, Вы писали:
CC>>>>Ну так какого ты ляда утверждаешь что "Стандартные аллокаторы в С++ требуют прохода блаблабла"? G>>>Еще раз: все известные мне реализации так работают. CC>>Мы о С++ либо об известных тебе реализациях? G>Думаешь я мало компиляторов видел?
Ты с темы не съезжай.
G>>>Твой наколенный непотокобезопасен. CC>>Можно узнать с какого перепугу ты так решил? CC>>Там Per-thread pool с lock-free deferred алгоритмом на случай освобождения памяти из не-родного-потока. G>Значит уже забыл. Пулы интересуют еще меньше, так как они требуют подгонки размеров блоков и пулов.
Ясно. Как работают пулы ты тоже не в курсе.
Известно ли тебе что HeapAlloc в LFH режиме тоже на пулах?
G>Как аллокатор общего назначения использовать смысла нету.
Расскажи это разработчикам Hoard, TBB и того же Windows Heap
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, gandjustas, Вы писали:
CC>>Там Per-thread pool с lock-free deferred алгоритмом на случай освобождения памяти из не-родного-потока. G>Кстати с явным Free тоже бльшая попа. Все это придется оборачивать в очередные умные указатели чтобы не было утечек.
А вот ты никак не можешь прожить без того, чтоб за тобой кто нить не прибирал твои выделения.
Никакой попы там нет. Работает простой жизненный принцип: убирай за собой. Это нормально.
G>Заметь что код на C#, такой как в тесте, не требует никаких усилий чтобы работать быстро. Чтобы работал быстро аналогичный код на С++ требуется немало усилий.
Каких усилий?
Все потери на твоем С++ тесте исключительно в системной функции HeapAlloc.
Это многопоточный аллокатор общего назначения. Синхронизация в нем через критическую секцию, что медленно.
Пул в моем аллокаторе постольку поскольку, меня больше интересовало насколько будет быстрее если убрать тормоза критической секции.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, gandjustas, Вы писали:
CC>>>>>Ну так какого ты ляда утверждаешь что "Стандартные аллокаторы в С++ требуют прохода блаблабла"? G>>>>Еще раз: все известные мне реализации так работают. CC>>>Мы о С++ либо об известных тебе реализациях? G>>Думаешь я мало компиляторов видел? CC>Ты с темы не съезжай.
Это ты не съезжай. Кивать на стандарт в случае С++ не стоит. Его мало кто реализует.
G>>>>Твой наколенный непотокобезопасен. CC>>>Можно узнать с какого перепугу ты так решил? CC>>>Там Per-thread pool с lock-free deferred алгоритмом на случай освобождения памяти из не-родного-потока. G>>Значит уже забыл. Пулы интересуют еще меньше, так как они требуют подгонки размеров блоков и пулов. CC>Ясно. Как работают пулы ты тоже не в курсе. CC>Известно ли тебе что HeapAlloc в LFH режиме тоже на пулах?
Еще раз: меня это вообще не интересует.
G>>Как аллокатор общего назначения использовать смысла нету. CC>Расскажи это разработчикам Hoard, TBB и того же Windows Heap
А это тут причем? Ты будешь на задумываясь использовать свой аллокатор в продакш коде?
Кстати, получилось что GC порвал в 5 раз виндовый аллокатор, который на пулах, так?
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, gandjustas, Вы писали:
CC>>>Там Per-thread pool с lock-free deferred алгоритмом на случай освобождения памяти из не-родного-потока. G>>Кстати с явным Free тоже бльшая попа. Все это придется оборачивать в очередные умные указатели чтобы не было утечек. CC>А вот ты никак не можешь прожить без того, чтоб за тобой кто нить не прибирал твои выделения. CC>Никакой попы там нет. Работает простой жизненный принцип: убирай за собой. Это нормально.
Не смеши. Если это нормально, то почему сейчас такое засилие "умных указателей"? Как раз для того чтобы програамист не думал что и когда ему надо убирать.
G>>Заметь что код на C#, такой как в тесте, не требует никаких усилий чтобы работать быстро. Чтобы работал быстро аналогичный код на С++ требуется немало усилий. CC>Каких усилий? CC>Все потери на твоем С++ тесте исключительно в системной функции HeapAlloc. CC>Это многопоточный аллокатор общего назначения. Синхронизация в нем через критическую секцию, что медленно. CC>Пул в моем аллокаторе постольку поскольку, меня больше интересовало насколько будет быстрее если убрать тормоза критической секции.
Ты до сих пор не понял что создание таких аллокаторов — нетривиальная задача. Далеко не каждый программист сможет справиться. В тоже время GC работает достаточно быстро, а программисту при этом даже не требуется заботиться об освобождении памяти.
Здравствуйте, gandjustas, Вы писали:
G>1)HeapAlloc работает медленнее, чем GC
HeapAlloc это Windows Heap а не С++
С++ CRT от MS использует HeapAlloc. Полагаю, так им было проще: раньше то они свой аллокатор пытались писать.
С# runtime от MS использует свой GC.
Вы, господа, сравниваете два решения от МС.
По своей сути С++ позволяет реализовать какой угодно аллокатор.
Сравнение в таком случае С++ аллокатора (который может быть вообще любым) с конкретной реализацией GC не имеет смысла по определению.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, gandjustas, Вы писали:
G>>>Думаешь я мало компиляторов видел? CC>>Ты с темы не съезжай. G>Это ты не съезжай. Кивать на стандарт в случае С++ не стоит. Его мало кто реализует.
Паня-атна.
CC>>Ясно. Как работают пулы ты тоже не в курсе. CC>>Известно ли тебе что HeapAlloc в LFH режиме тоже на пулах? G>Еще раз: меня это вообще не интересует.
Аха.
G>>>Как аллокатор общего назначения использовать смысла нету. CC>>Расскажи это разработчикам Hoard, TBB и того же Windows Heap G>А это тут причем? Ты будешь на задумываясь использовать свой аллокатор в продакш коде?
А почему нет? Я его интереса ради стресс тестами гонял в многопоточном режиме на 4хядернике.
G>Кстати, получилось что GC порвал в 5 раз виндовый аллокатор, который на пулах, так?
Ох блин. Как же трудно иногда объяснять элементарные вещи человеку с синдромом бакалавра.
В HeapAlloc самые большие тормоза дает Critical Section.
HeapAlloc имеет режим под названием Low fragmentation heap. Реализован на пулах и дает прирост скорости аллокации в некоторых случаях (у меня был ~2х для std::map. Отдельного тестирования не проводил, так что за вообще все случаи говорить не буду). По умолчанию выключен.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, gandjustas, Вы писали:
G>Не смеши. Если это нормально, то почему сейчас такое засилие "умных указателей"? Как раз для того чтобы програамист не думал что и когда ему надо убирать.
Засилье? Где?
Я его в С++ проектах не наблюдаю.
У нас они в основном там, где проект был портирован на С++ с managed языков, чтоб не надо было сильно много переделывать.
G>Ты до сих пор не понял что создание таких аллокаторов — нетривиальная задача. Далеко не каждый программист сможет справиться.
Не можешь написать свой — пользуй готовые. Тот же Hoard например. Если реально надо.
G> В тоже время GC работает достаточно быстро, а программисту при этом даже не требуется заботиться об освобождении памяти.
Для некоторых случаев GC-памперс, который "даже не требуется заботиться об освобождении" может стать проблемой.
Особенно если программист недостаточной квалификации.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
G>> В тоже время GC работает достаточно быстро, а программисту при этом даже не требуется заботиться об освобождении памяти. CC>Для некоторых случаев GC-памперс, который "даже не требуется заботиться об освобождении" может стать проблемой. CC>Особенно если программист недостаточной квалификации.
Если программист недостаточной квалификации, то само использование unmanaged становится большой проблемой (видел такое на Delphi), не говоря уже о С++ с его примудростями.
Я за что купил, за то продаю — вот такие сведения у меня есть, ты их можешь принять во внимание или послать подальше — твоё право. Более надёжных источников, относящихся к тому периоду у меня нет.
