Здравствуйте, kuj, Вы писали:

kuj>Да, ты пишешь, что фраза "lisp, ML, haskell — чисто академические, тормозные и не имеющие практического применения языки" — корректна. Что в действительности не так.
Учимся читать.

Здравствуйте, yumi, Вы писали:

Y>Чушь какая-то. Хаскель вообще очень хорошо поддается оптимизации, особенно после десахаризации, когда у нас остался промежуточный язык называемый "Core", который в свою очередь основывается на System F (типизированное лямбда-исчисление). Т.к. она полностью формализована, то тут как ты надеюсь понимаешь, огромный простор для оптимизаций, я даже все не буду перечислять, которые там используются. Далее, "Core" трансформируется в низкоуровневый промежуточный язык STG (Spineless Tagless G-machine), на этом этапе тоже есть простор для оптимизаций.
На словах.
А на практике мы имеем тормозной язык жрущий непредсказуемое колличество памяти.
И чтобы он хоть както шевелился народ ручками подавляет ленивость.

Y>С Лиспом (я про CL, про Схему вообще без понятия), ситуация похуже, это такой же грязный язык как С++, оптимизации тут конечно тоже есть, но принципиально, крутых оптимизаций тут быть не может. В то же время SBCL генерирует очень эффективный и быстрый код.
Грязь фигня.
Она почти не мешает.
Оптимизатор убивает динамическая типизация.

WolfHound пишет:
> Y>С Лиспом (я про CL, про Схему вообще без понятия), ситуация похуже,
> это такой же грязный язык как С++, оптимизации тут конечно тоже есть, но
> принципиально, крутых оптимизаций тут быть не может. В то же время SBCL
> генерирует очень эффективный и быстрый код.

> Оптимизатор убивает динамическая типизация.
А Dializer в Erlang?

--
ISO/IEC 8652:1995/Amd 1:2007

Здравствуйте, kuj, Вы писали:

К>>>Корректно ли моё последнее рассуждение в этой цепочке или нет? Я так понял, что да, но тогда совершенно неясно, какой смысл был Ночному Смотрящему говорить про 3.5… Разве что подсластить пилюлю, что, мол, в каких-то там далёких будущих версиях программ, если авторы соизволят портировать свои творения под 3.5, этих проблем не будет.

S>>Если приложение написано для фреймвока 2.0 то изменения сделанные для 3.5 должны примениться для этого приложения, потому что фремворки 3.0 и 3.5 — это фреймворк 2.0 + дополнительные библиотеки ...

kuj>Не следует путать Framework и CLR.

чего?

Здравствуйте, WolfHound, Вы писали:

WH>А на практике мы имеем тормозной язык жрущий непредсказуемое колличество памяти.
WH>И чтобы он хоть както шевелился народ ручками подавляет ленивость.

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

WH>Грязь фигня.
WH>Она почти не мешает.
WH>Оптимизатор убивает динамическая типизация.

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

Здравствуйте, yumi, Вы писали:

Y>Смотря кто, лично я на практике имею очень гибкую и красивую библиотеку работы с фин. вычислениями основанную на комбинаторах. Кстати как раз потребление памяти, вполне таки предсказуемое. Хаскель вообще очень предсказуемый язык
И ленивость не подавлял?
Строгие языки предсказуемые.
А вот ленивые...

Y>С последним отчасти согласен. А вот первое на корню убивает возможность мат. анализа в общем смысле, а в частности возможность оптимизации, стат. анализа кода на корректность. Причем оптимизировать изменяя даже сам алгоритм, т.к. в случае формальной системы, мы сможем доказать эквивалентность замены алгоритма.
Опять же хорошо в теории, а на реальном железе рулят хештаблици которые в доску грязные.
Ну и еще несколько вхлам грязных алгоритмов и структур данных.
Просто по тому что чистую структуру данных с тойже асимптотикой не сделать.
А если впомнить про пляски вокруг SMP...

Здравствуйте, WolfHound, Вы писали:

WH>И ленивость не подавлял?

Нет, в моем случает это наоборот плюс.

WH>Опять же хорошо в теории, а на реальном железе рулят хештаблици которые в доску грязные.
WH>Ну и еще несколько вхлам грязных алгоритмов и структур данных.

Действительно, а я и не заметил, заглянул в исходники, там поиск по ключу O(log n).

WH>Просто по тому что чистую структуру данных с тойже асимптотикой не сделать.

Интересно почему, не подскажете ссылок, почитать. Мне интуитивно кажется, что чисто теоретически это возможно или нет?

Здравствуйте, yumi, Вы писали:

Y>Нет, в моем случает это наоборот плюс.
Значит повезло. Пока.

Y>Действительно, а я и не заметил, заглянул в исходники, там поиск по ключу O(log n).
А хештаблица в среднем O(1).

Y>Интересно почему, не подскажете ссылок, почитать. Мне интуитивно кажется, что чисто теоретически это возможно или нет?
Чистую хештаблицу сделай.
Ну или хотябы ссылку в студию.

Здравствуйте, kuj, Вы писали:

kuj>Здравствуйте, _d_m_, Вы писали:

kuj>>>Я не знаю что значит "совместимость фреймворков". У меня все версии прекрасно уживаются, не мешая друг другу.

___>>А знать бы пора. Тем более раз раздаешь в конфе советы. RTFM — раз, пример — два, в третьих я собирал проект в VS 2003 для 1.1, там подключал сборку собраную вручную для 2.0 и все это успешно запускал в 2.0.

kuj>Открою тебе страшную тайну — запускалось оно в 1.1, а не в 2.0.

Ну, собственно, это... Бу-га-га
Ну что, опять упорствовать будем?

Ну тогда как работал объект класса SerialPort в 1.1? Открой мне еще более страшную тайну.

Здравствуйте, kuj, Вы писали:

К>>>>И все приложения, написанные на .NET 1.0, 1.1, 2.0, 3.0, автоматом станут подхватывать 3.5? Вроде бы, краем уха слышал, что там даже при переходе от 1.x к 2.0 какие-то жуткие несовместимости были…

___>>>Ага, а в америке негров линчуют.

К>>Получается, линчуют. Либо на RSDN'е врут

Автор: Jenyay
Дата: 28.05.05

. Кому верить?

kuj>Скорее эффект "испорченного телефона". Если на компьютере не установлен .NET FW 1.1, но установлен — 2.0, то приложения собранные под 1.1 выполняться не будут. Никто никогда совместимости не обещал.

куй, заканчивай в очередной раз с умным видом пукать в лужу.

Здравствуйте, WolfHound, Вы писали:

Y>>Действительно, а я и не заметил, заглянул в исходники, там поиск по ключу O(log n).
WH>А хештаблица в среднем O(1).

Я в курсе.

Y>>Интересно почему, не подскажете ссылок, почитать. Мне интуитивно кажется, что чисто теоретически это возможно или нет?
WH>Чистую хештаблицу сделай.
WH>Ну или хотябы ссылку в студию.

Вот Shootout.
А вот интересная статья Криса Окасаки Purely Functional Data Structures.

Здравствуйте, Sergey, Вы писали:

S>У MS есть как компилятор, работающий под x64 и генерирующий x64 код

Ссылочку можно?

Здравствуйте, Константин, Вы писали:

К>Если не так (что утверждает Ночной Смотрящий

Автор: Ночной Смотрящий
Дата: 29.05.08

), то а) зачем в таком случае хранить все версии фреймворка на компе

Я ж говорю, если не в теме, то либо разберись, либо не делай таких далеко идущих выводов. Ситуация с версиями FW довольно путанная. Маркетологи наплодили. Вот табличка, чтобы проще было разобраться:

Фреймворк	CLR	C#	BCL	WxF
1.0	1.0	1.0	1.0	-
1.1	1.1	1.0	1.1	-
2.0	2.0	2.0	2.0	-
3.0	2.0	2.0	2.0	3.0
3.5	2.0	3.0	2.0 SP1	3.0 SP1
3.5 SP1	2.0 SP2	3.0	2.0 SP2	3.0 SP2
4.0	4.0	4.0	???	???

Последние две строчки — информация недостоверная.
Кроме того, были несколько сервиспаков к 1.0 и 1.1, но это были исключительно исправленные ошибки, на совместимость они никак не влияют. 3.5 (точнее 2.0 SP1) тоже кое что патчит в CLR, но, опять же, на совместимость это не влияет.

Теперь по совместимости. Есть два момента — бинарная совместимость кода и совместимость библиотек.
Бинарную совместимость имеет 100% в направлении от младших версий к старшим, в обратную сторону совместимы 1.0 и 1.1, 2.0-3.5 SP1.
По BCL в общем и целом имеем совместимость в обе стороны. если не используются новые возможности. Небольшие ломающие изменения были между 1.1 и 2.0, в основном в ASP.NET и COM interop.

Как видишь, вопрос весьма непростой, и однозначного ответа на него нет.

Ночной Смотрящий пишет:


> S>У MS есть как компилятор, работающий под x64 и генерирующий x64 код
>
> Ссылочку можно?

Все 3 компилятора (С++) есть в составе МS VS 2005. Официальную ссылочку,
которая бы это подтверждала, лень искать. Неофициальные легко найти,
погуглив по словам VC\bin\amd64\cl.exe или VC\bin\x86_amd64\cl.exe. А
можете просто поставить студию на x64 ОС и сами убедиться. Только
внимательно смотрите на галки, по дефолту ставится лишь 32-битный
компилятор.

Sinclair однажды (29 мая 2008 [Четверг] 07:47) писал:

> Вкратце: новые платформы и технологии позволяют получать лучшее быстродействие, чем старые. Байки про "тормозной фреймворк", про "медленный GC", и про "оптимизированные
> вставки на ассемблере" лучше рассказывать на слетах неудачников. Вон возьмите Шеридана, бутылку немировки и будет тема для беседы на ночь. Взрослые люди над этим уже даже не
> смеются.
Что шеридан?
Синклер, что делать будеш, когда камни упрутся в потолок, а твой код, выводящий на экран картинку, будет занимать полтора гига оперативки?
Или ты так и будеш утверждать, что код на дотнете исполняется быстрее кода на с++ и занимает меньше памяти?

--
...belive in the matrix...

Здравствуйте, Sheridan, Вы писали:
S>Синклер, что делать будеш, когда камни упрутся в потолок, а твой код, выводящий на экран картинку, будет занимать полтора гига оперативки?
S>Или ты так и будеш утверждать, что код на дотнете исполняется быстрее кода на с++ и занимает меньше памяти?
Смотря какой код. Например, веб-приложения на дотнете запросто могут исполняться быстрее таковых на C++. А уж про занимание памяти я вообще молчу: микроскопическая утечка в сервере сожрет всю память. С чего бы коду по выводу картинки занять полтора гига я не знаю. Разве что речь идет про картинку в полгигапиксела.

Здравствуйте, Sinclair, Вы писали:

S>Ничего это не даст. Компетентные разработчики и на фреймворках пишут быстрые программы. А некомпетентный разработчик никаких разов от переписывания на плюсы не получит — получит только повышенную багливость. Учите матчасть.

А в ATI по вашему компетентные разработчики ? По мне, если они там и были, то уволились ровно в тот момент, когда фирменная утилита настройки видеокарт стала писаться на фреймворке. Имхо, очень яркий пример как и какой тип программ НЕ НАДО писать с применением фреймворка. Оно прописывается в автозапуск (очень интересно — зачем , если в 99.99% случаев видеокарта 1 раз настраивается и потом ничего не меняется, а если надо перенастроить — не влом и руками утилиту запустить), создаёт 3 процесса CLI.EXE и ещё 2 процесса ati2evxx.exe (сервисы), честно говоря я очень сомневаюсь в целесообразности такого количества процессов. Папочка %Program Files%\ATI Technologies весит 200+ метров. Надо ли говорить что на P4 3.0Ghz, 2Gb RAM под WinXP SP2 с настроенным автовходом пользователя происходит презабавнейшая вещь — мелькает окошко "Загрузка личных параметров", затем курсор меняется на песочные часики и можно секунд 20-25 курить, пока эти монструозные процессы прохрустят винтом, затем появляются иконки и таскбар, наконец ещё секунд через 15 в трее появляется логотип ATI и дисковая активность наконец, прекращается. Всё вышеописанное происходит на голой системе, установлены только все драйверы. После переустановки драйвера со снятой галочкой ATI Control Center'а тормоза при загрузке профиля пользователя исчезли. А для настройки теперь использую ATI Tray Tools. Пользователи видеокарт ATI, как говорится сравните и почувствуйте разницу. В данном случае использование фреймворка — явное забивание гвоздей микроскопом, скорее всего по причине "модности". Тут С++ников обвиняют в фанатизме и нежелании видеть плюсы фреймворка, как оказывается подобная участь ждёт и .netчиков, сейчас это утилита настройки драйвера видеокарты, а завтра они и драйвер заодно на нём напишут (а к этому идёт). Тогда уже никакие 4х ядерники не помогут. А чем вызвана такая архитектура в 5 процессов для меня остаётся загадкой...

И напоследок где-то в треде видел фразу про утечку памяти в сервере на плюсах. Не поверите, но у CLI.exe она тоже течёт, достаточно не перезагружаться недели две, а уводить комп в спячку. Пожираемая процессами CLI.EXE память постепенно увеличивается до 200-300 мб на процесс. Где уж там утечка — в самом фреймворке или в их поделке — , но она есть.

Здравствуйте, FirstStep, Вы писали:

Вот про ATI согласен полностью. Я не понимаю, чего там такого грузится постоянно. Даже если без фреймворка — 5 процессов это очень и очень много. Причем их убивание никак не отражается на работе системы, кроме освобожденной памяти.

Здравствуйте, FirstStep, Вы писали:

FS>А в ATI по вашему компетентные разработчики ? По мне, если они там и были, то уволились ровно в тот момент, когда фирменная утилита настройки видеокарт стала писаться на фреймворке. Имхо, очень яркий пример как и какой тип программ НЕ НАДО писать с применением фреймворка.

Тут виноват не .Net, а кривые руки разработчиков ATI. C++ от кривых рук тоже не спасет.

Здравствуйте, FirstStep, Вы писали:

FS>И напоследок где-то в треде видел фразу про утечку памяти в сервере на плюсах. Не поверите, но у CLI.exe она тоже течёт, достаточно не перезагружаться недели две, а уводить комп в спячку. Пожираемая процессами CLI.EXE память постепенно увеличивается до 200-300 мб на процесс. Где уж там утечка — в самом фреймворке или в их поделке — , но она есть.

Моя плакать...
Изучите разницу между Workset и реально используемой памятью.