Здравствуйте, Sinclair, Вы писали:
S>Неужели возможно еще смешнее?
Можно можно, особенно если это из уст взрослых людей а не малолеток (у них хоть шанс есть еще).
S>То есть основная проблема — не в насильственности (всё внедряется вполне добровольно), не в тормозах (их нет, современные платформы позволяют писать более быстрый код), не в невозможности использовать ассемблер (неудачники не знают ассемблера), а просто в том, что кого-то не взяли в "корпорации и разработчики", в угоду которым и происходит вот это "насильственное насаждение". Вон AVK потирает руки в ожидании следующей вижуал студии, а неудачники поди набрали полные рты говна, чтобы ее как следует оплевать, даже не разбираясь, че там происходит и для чего.
То же самое со взрослыми дядями, которые готовы оплевать Haskell, Lisp, *ML и прочие очень красивые языки, даже не разбираясь в них. И проблема тут не в том, что они действительно плохие, а кому-то либо религия не позволяет, либо лень разбираться или банально не осилили.
S>Да и зачем затруднять себя изучением фактов? Говно во рту с успехом заменит ясность в сознании. Так что можно смело писать про то, что "под Венду уже проблематично найти компилятор, создающий машинный код", про то что "Enterprise, но они являются не более чем от JITиным кодом, который все-равно запускается под VM", "Функциональное и линейное программирование отомрут как класс" и прочую бредятину. Потому что все равно найдутся и другие неудачники, которые не могут просто "восхищаться простотой архитектуры", им надо непременно постонать про то, как "настоящих программистов выкинут на помойку".
Да действительно, зачем затруднять себя изучением новых языков, ведь нам C++, .Net, Java хватает за глаза, будем колоться, но продолжать жрать кактус. А когда кактус жрешь, начинаешь говорить такие вещи как "Common Lisp, Haskell академические языки, в жизни не применимы, они тормозные по определению". Брызгая слюнами начинают доказывать, как C++ подходит для абсолютно всех задач.
S>Вот тут автор попал в точку — таких "настоящих программистов", как он, на помойку все выкинут с радостью. Потому как простая некомпетентность, заинтересованная в обучении, еще может кому-то пригодиться, а воинствующее невежество — нет.
Таких, про которых я описал, тоже могут запросто выкинуть на помойку, история это доказывает...
Lisp is not dead. It’s just the URL that has changed: http://clojure.org
Здравствуйте, Sergey, Вы писали:
S>Зато 64-битные приложения потенциально могут работать значительно S>быстрее 32-битных аналогов.
Далеко не всегда. Только где можно применить бОльший размер регистров и т.п.
Тупая перекомпиляция эффекта как правило не дает.
S>Не знаю, правда, компиляторы уже подтянулись или все еще тупят.
Intel давно уже есть.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
CC>Далеко не всегда. Только где можно применить бОльший размер регистров и т.п. CC>Тупая перекомпиляция эффекта как правило не дает.
На x64 ещё и больше регистров стало, кстати. Так что только за счёт этого можно что-то получить.
Здравствуйте, Sinclair, Вы писали:
S>Вкратце: новые платформы и технологии позволяют получать лучшее быстродействие, чем старые. Байки про "тормозной фреймворк", про "медленный GC", и про "оптимизированные вставки на ассемблере" лучше рассказывать на слетах неудачников. Вон возьмите Шеридана, бутылку немировки и будет тема для беседы на ночь. Взрослые люди над этим уже даже не смеются.
Если это про .Net & Java, то надо еще добавить, что тут возможность анализа потребления памяти и быстродействия гораздо шире. Проще написать без преждевременных оптимизаций, дальше смотреть профайлером и устранить узкие места.
Просто буквально месяц назад, свою программу оперирующую большими объемами данных оптимизировал. При некоторых операциях, она задумывалась на минут 5-6. Потратив пару часов на профилирование, я уже нашел те места и через день оптимизаций тех участков, время сократилось до 20-30 сек. Без профайлера, я бы узкие места искал бы гораздо дольше.
Lisp is not dead. It’s just the URL that has changed: http://clojure.org
Здравствуйте, Sergey, Вы писали:
S>Зато 64-битные приложения потенциально могут работать значительно S>быстрее 32-битных аналогов.
Я плохо выразился? Меня, как пользователя, совершенно не волнуют потенциальные измышления, мне нужнознать конкретные существующие в природе бенефиты. Таковых я пока что не увидел.
S> Не знаю, правда, компиляторы уже подтянулись или все еще тупят.
Если говорить о МС, то у них ни одного 64хбитного компилятора нет. Да и нафик компиляторам 64 бита не нужно — типов данных там таких нет и жрать одномоментно гигабаты оперативки им тоже без особой надобности.
Здравствуйте, Константин, Вы писали:
kuj>>Я не знаю что у тебя там за проблемы с загрузкой... У меня штук пять мелких самописных тулзовин (консольные и GUI) после 2-3 запусков загружаются уже мгновенно.
К>После 2-3 запусков у меня-то тоже почти мгновенно. Я об этом писал чуть выше по ветке
… Проблема в недолговечности подобного "ускорения".
Не понял на счет недолговечности...
kuj>>Еще есть "толстый" клиент с довольно "навороченным" интерфейсом (на SQL Server 2005) — загружающий более 20 разных сборок, грузится по профайлеру ~2-3 секунды, остальные ~4-5 уходят на подключение и выборку данных из БД. Жалоб о производительности от пользователей пока не поступало, хотя крутится на довольно слабых компьютерах.
К>И об этом тоже уже говорил (например, тут
), что, если время загрузки фреймворка по сравнению с временем других старт-ап действий невелико, а особенности платформы на производительности основных операций сказываются не сильно, то можно и забить в угоду удобству разработки.
Ты думаешь что runtime фреймворка грузится при каждой загрузке программы? oO
… Проблема в недолговечности подобного "ускорения".
НС>Эта проблема решена в FW 3.5 SP1. Выходит летом, бета уже доступна.
И все приложения, написанные на .NET 1.0, 1.1, 2.0, 3.0, автоматом станут подхватывать 3.5? Вроде бы, краем уха слышал, что там даже при переходе от 1.x к 2.0 какие-то жуткие несовместимости были…
… Проблема в недолговечности подобного "ускорения".
kuj>Не понял на счет недолговечности...
Ну я же ссылку дал, там в сообщении всё написано. Недолговечность в том, что загрузка быстрая, пока DLL-ки из памяти не улетят. Перезагрузил машину — запуск .NET-приложения снова тормозной. Загрузил память другими программами — неиспользуемые DLL-ки выгрузились, в следующий раз снова грузиться будут.
kuj>Ты думаешь что runtime фреймворка грузится при каждой загрузке программы? oO
А что, не так? Чем его загрузка отличается от обычных механизмов работы с DLL? Понадобился фреймворк — DLL-ки загрузились в память (если уже там не сидят). Приложение закрылось — остаются сидят в памяти. Потребовалась память другим приложениям — лишние DLL-ки выкинуты, будь то .NET или любые другие библиотеки. Или я неправ? Конечно, если на компе круглосуточно крутятся .NET-прожки, то выгрузки не будет, разве что своп, но у меня .NET-приложения используются раз в неделю, а то и реже.
Здравствуйте, yumi, Вы писали:
Y>"Common Lisp, Haskell академические языки, в жизни не применимы, они тормозные по определению".
А это кстати правда.
Лисп динамически типизируемый.
Хаскель ленивый.
И то и другое оптимизации не поддается.
ЗЫ На С++ и жабке писать не призываю.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Я плохо выразился? Меня, как пользователя, совершенно не волнуют потенциальные измышления, мне нужнознать конкретные существующие в природе бенефиты. Таковых я пока что не увидел.
Ну, для меня 64битные регистры к примеру несколько ускорили бы вычисления с BigInt (ECC и RSA).
Весьма такой практический бенефит.
Но увы, алгоритмов, которые бы реально получили бы бонус от 64бит на самом деле мало.
НС>Если говорить о МС, то у них ни одного 64хбитного компилятора нет. Да и нафик компиляторам 64 бита не нужно — типов данных там таких нет и жрать одномоментно гигабаты оперативки им тоже без особой надобности.
Все у них есть. И компилер и типы. Вон тип __int64 еще с vc6 имеется.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
НС>>Я плохо выразился? Меня, как пользователя, совершенно не волнуют потенциальные измышления, мне нужнознать конкретные существующие в природе бенефиты. Таковых я пока что не увидел. CC>Ну, для меня 64битные регистры к примеру несколько ускорили бы вычисления с BigInt (ECC и RSA).
Такое ощущение, что ты читаешь только последнюю мою фразу. Еще раз — мне как пользователю пофиг, что и кто там внутри. Меня совершенно не колышит скорость работы RSA, потому что даже если я онный использую в каком нибудь SSL, то объемы данных таковы, что в микроспкоп этого твоего ускорения не видно.
CC>Весьма такой практический бенефит.
Как мне его увидеть?
CC>Но увы, алгоритмов, которые бы реально получили бы бонус от 64бит на самом деле мало.
А реального софта еще меньше.
НС>>Если говорить о МС, то у них ни одного 64хбитного компилятора нет. Да и нафик компиляторам 64 бита не нужно — типов данных там таких нет и жрать одномоментно гигабаты оперативки им тоже без особой надобности. CC>Все у них есть. И компилер и типы. Вон тип __int64 еще с vc6 имеется.
Ты не путай компилятор под x64, и компилятор работающий на x64.
Здравствуйте, yumi, Вы писали:
S>>То есть основная проблема — не в насильственности (всё внедряется вполне добровольно), не в тормозах (их нет, современные платформы позволяют писать более быстрый код), не в невозможности использовать ассемблер (неудачники не знают ассемблера), а просто в том, что кого-то не взяли в "корпорации и разработчики", в угоду которым и происходит вот это "насильственное насаждение". Вон AVK потирает руки в ожидании следующей вижуал студии, а неудачники поди набрали полные рты говна, чтобы ее как следует оплевать, даже не разбираясь, че там происходит и для чего.
Y>То же самое со взрослыми дядями, которые готовы оплевать Haskell, Lisp, *ML и прочие очень красивые языки, даже не разбираясь в них. И проблема тут не в том, что они действительно плохие, а кому-то либо религия не позволяет, либо лень разбираться или банально не осилили.
Здравствуйте, WolfHound, Вы писали:
Y>>"Common Lisp, Haskell академические языки, в жизни не применимы, они тормозные по определению". WH>А это кстати правда. WH>Лисп динамически типизируемый.
Python и Rubi тоже. Однако, имеют реальное применение в удачных и крупных проектах.
Ночной Смотрящий пишет:
> НС>>Если говорить о МС, то у них ни одного 64хбитного компилятора нет. > Да и нафик компиляторам 64 бита не нужно — типов данных там таких нет и > жрать одномоментно гигабаты оперативки им тоже без особой надобности. > CC>Все у них есть. И компилер и типы. Вон тип __int64 еще с vc6 имеется. > > Ты не путай компилятор под x64, и компилятор работающий на x64.
У MS есть как компилятор, работающий под x64 и генерирующий x64 код, так
и кросс-компилятор, работающий на 32-битных системах и генерирующий x64
код. Тока в плане оптимизации они все довольно тупые, по моим ощущениям.
Posted via RSDN NNTP Server 2.1 beta
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
CreatorCray пишет:
> S>Зато 64-битные приложения потенциально могут работать значительно > S>быстрее 32-битных аналогов. > Далеко не всегда. Только где можно применить бОльший размер регистров и т.п.
Там регистров в два раза больше. Это часто важно.
> Тупая перекомпиляция эффекта как правило не дает.
О том и речь. Хотя, на мой взгляд, должна. Потому что написанные на
ассемблере куски кода иногда с полпинка разгоняются в 2-3 раза, просто
за счет большего числа регистров.
> S>Не знаю, правда, компиляторы уже подтянулись или все еще тупят. > Intel давно уже есть.
MS тоже. Только толку от них не много, потому что, как правильно было
замечено выше — "тупая перекомпиляция эффекта как правило не дает".
Posted via RSDN NNTP Server 2.1 beta
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
