Вышел релиз СУБД HyperSQL 2.0 (http://hsqldb.org/) (HSQLDB), написанной полностью на языке Java и распространяемой в рамках лицензии BSD. Прошлая версия HSQLDB 1.8 вышла около 5 лет назад и используется в составе многих открытых и коммерческих продуктов, например, используется доя организации работы с базами данных в OpenOffice.org.Основные новшества HyperSQL 2.0 (http://hsqldb.org/web/features200.html):
- Представлено новое ядро БД и полностью переписана большая часть внутренних компонентов. HSQLDB отныне работает многопоточном режиме, поддерживает двухфазовые блокировки (2PL), мультиверсионный контроль параллельного выполнения операций (MVCC) и гибридную модель обработки транзакций (2PL+MVCC). При работе с транзакциями теперь поддерживается их сериализация и выполнение коммитов на чтение, также добавлена поддежка изоляции снапшотов и обеспечения гарантированной целостности при выполнении запросов на чтение;
- Проведена работа по увеличению стабильности и производит...
URL: http://www.h-online.com/open/news/item/HSQLDB-HyperSQL-2-0-r...
Новость: http://www.opennet.me/opennews/art.shtml?num=26943
Если кто-либо использовал: Насколько она быстрая и удобная в работе?
стабильная?
Не флейма ради, образованья для...
А быстрые и маложрущие программы на Java вообще бывают? Мне пока не везло - я таких еще не встречал.
бывают. мало того, программы,написанные на управляемом коде могут быть часто быстрее чем на неуправляемом.
Не бывает при одинаковых алгоритмах
Просто, я представитель античной школы - писал только на Си с ассемблерными вставками и наивно полагал, что это достаточно быстрый и компактный код. Отсюда и мои предпочтения.
В современных языках ориентируюсь слабо - потому и вопросы задаю :)
Для контроллеров и сейчас так пишут, так и есть - самый быстрый и компактный код.
Потому, неудивительно, с распространением нетбуков и иже с ними популярность жабы падает, а plain С растёт
>Для контроллеров и сейчас так пишут, так и есть - самый быстрый
>и компактный код.
>Потому, неудивительно, с распространением нетбуков и иже с ними популярность жабы падает,
>а plain С растётну только не нужно тут разносить преимущества ООП по сравнению со структурным программированием. Вы наверное просто мало программировали, поэтому и пишете такое
Достаточно, особенно для AVR, ARM и им подобных
Преимущества ООП никуда не делись, но они покупаются ценой скорости
>Преимущества ООП никуда не делись, но они покупаются ценой скоростиСкажу банальную вещь. ООП это скорее парадигма дизайна, нежели поддержка языка или компилятора. Поэтому тезис о скорости неуместен. К тому же оверхед обычно мизерный.
Трухин как раз говорил о языках
и естественно (для него это естественно), в контексте платформы.
я каждый день много программирую. на работе проект, за который я отвечаю, выходит на стадию тестирования. часть алгоритма была переписана с явы (часть потому как это расширенная по функционалу программа для тестирования). причем, ява не рассматривалась в начале проекта как платформа ВООБЩЕ ввиду могучих траблов со скоростью при создании логов (обработка тескта) и при коммуникации по tcp протоколу
паралельно веду несколько проектов подобного характера на Qt4, тоже из относительно старых, так у этих проектов мрачных косяков не было. причем, структура программ внутри примерно одинаковая.так что мы делаем не так?
ну и на злобу дня: где видеоредакторы, браузеры, оффисные пакеты, числодробилки и прочее, написанное на яве, или дотнете? ГДЕ?
OpenOffice.. не?? Eclipse...??
Распределенные СУБД типа apache Cassandra? ) примеров море... если вы не знаете, это не означает что этого нет))
на Dot Net'е тоже много всего есть.. но честно говоря не хочу перечислять из-за моего негативного отношения к этой платформе...
OpenOffice на яве? не выдавайте желаемое за действительное! Eclipse - монстроподобноая IDE, которую невозможно развернуть на ЛЮБОМ компе (в том числе и слабом компе).
просто страшно подумать, если все те проги, которые я сейчас пользую, вдруг стали бы написанными на яве! производители железа может быть и обрадовались...
Вы ищете серебряную пулю и Большую Красную Кнопку?
У жабы своя ниша, в которой она предпочтительнее, ИМХО мощность проца для жабы давно не ограничивающий фактор, при наличии озу около гига Еклипс крутился на таблетке с вистой, при этом собирались немаленькие проекты, например собирал гсс. Так что мне страшно подумать, что жабо-программы начнут переписывать на Си только потому, что так кошернее.
> при этом собирались немаленькие проекты, например собирал гссА без eclipse я собирал gcc имея ОЗУ в 32 раза меньше Вашего ;-)
Eclipse вообще-то для разработки, а собирать ты можешь хоть на коленке
А то я не знал!
Глаза-то заплывшие протри, fr0ster-у скажи, это он элипсом собирает.
>У жабы своя ниша, в которой она предпочтительнеетак по этому поводу никто не спорит. речь о том, что ява прожорливее и медленнее.
>например собирал гссEcipse всего лишь IDE, так что самостоятельноЮ как продукт он пересобрать gcc не сможет. вы о чем-то умолчали? :)
>жабо-программы начнут переписывать на Сикривоватое какое-то сравнение... Си не является ООЯ
> О чём это должно нам говорить?А о том, что Eclipse не является быстрой и маложрущей программой на жабе.
Нормальный пример неповоротливого тормозного монстра.
раньше прогу на яве приходилось запускать на сервере для тестирования на нагрузку. какие были проблемы - я уже описал ранее. сейчас переделанную программу на плюсы можно запустить на лептопе 1 GHz, 1 GB RAM (тестировали на самом слабом, что нашли), нагрузка на процессор при максимальном включении колеблется в районе 2.5-3% (CPU Last)
причем, потенциал для внутренней оптимизации еще не исчерпантак что мы сделали не так???
А на серваке какая была загрузка проца (процов)?
достаточно нестабильно: от 50% до 80% вплоть до креша. с выключеным протоколированием нагрузка была была меньше на процентов 20. раньше эта прога устанавливалась на P-IV 2.8MHz 2GB RAM. с потреблением памяти проблем не было, кушала она себе около 400 мегов, но там больше толком ничего не бегало, кроме KDE3
Выигрыш в десятки раз, круто, что ещё сказать
конечно, внутренний дизайн программы тоже объекториентированный, по крайней мере - моя часть, т.к. делал не только я, но еще и коллега. он писал свою часть на си (в силу некоторых причин), с использованием flex и bison.
Хм. Я вполне себе пользуюсь Sun Studio под Солярисом. А его IDE на NetBeans основано. А оно -- Java. Я бы не сказал, что недоволен быстродействием.Хотя, безусловно, да. /export/onnv/usr/src/uts я в него не загружал. ;) Хотя, судя по тому, как у них работает OpenGrok -- вряд ли поперхнётся...
мне в большинстве случаев хватает KDevelop. да и быстродействие на IDE... оно больше зависит от быстродействия перед монитором. а память на компе мне нужна для других целей, для IDE жалко как-то метров пиццот отдавать. и без этого иногда запускается виртуалка на ноуте с двумя гигами.
> Просто, я представитель античной школы - писал только на Си с ассемблерными
> вставкамиТут ведь дело в Goal'ах. Если на C с _ассемблерными вставками_, то есть, когда речь не идёт о переносимости кода (by definition, ибо язык Ассемблера), конечно никакой Яве не угнаться. :)
Но тут надо чётко понимать разницу между программой и программным продуктом. В современном мире _очень_ малая часть именно _программных продуктов_ может быть написана непереносимо.
> В современном мире _очень_ малая часть именно _программных продуктов_ может быть написана непереносимо.С этим утверждением мало кто не согласится.
Но, тем не менее речь была о быстроте и маложручести.
Инлайновый асм в gcc разве не портабелен ????
>Инлайновый асм в gcc разве не портабелен ????если в нем ты использовал какую-то особенность процессора, то нет
то есть опыта написания инлайнового асма у тебя равен нулю. есть конкретный синтаксис для конкретной модели процессора: то, о чем ты пишешь, можно ограничить только на процессоры Intel 32bit (к примеру). но это неприменимо к MIPS, Z80, к любым другим микроконтроллерам...
список продолжить.
могу вас огорчить - конкретного синтаксиса тоже нет )))
есть типа интеловский есть типа АТиТи есть разные асм трансляторы
тот же самый масм или тасм (и между ними большая разница - в плане синтаксиса)пс: а в теории процессоры все одинаковы (те же регистры флаги и набор команд - просто под разными названиями)
может какой нить из процессоров по другому складывает ? значь можно же вывести одну команду сложения
асм это упрощённая оболочку языка команд процессора ну и так далее С оболочка асм ..........
это для меня не открытие. дело в том, что даже в том же gcc вами упомянутые синтаксисы можно просто переключать.
1. никто и не говорит про масм и тасм - это свои проприетарные разработки и стандарты. и они только под одну платформу. под другие их просто нет. в контексте портабильности (опять же - портабельности синтаксиса) можно рассматривать только $ man as
NAME
AS - the portable GNU assembler.
http://www.opennet.me/docs/RUS/gas/ плюс к нему gasp http://www.opennet.me/docs/RUS/gasp/
ну или ещё можно привести nasm
2. если уж говорить про синтаксис между масм и тасм, то ideal спасёт отца русской демократии. но лично я бы предпочел изучить один синтаксис гнушного асма, которой для всех платформ одинаков, и не морочить себе голову.
http://ru.wikibooks.org/wiki/%D0%90%D1%8...
3. все выше перечисленное не отменяет знаний особенностей конкретной архитектуры. асм вообще для тех, кто точно знает, что он делает и зачем.
>>но лично я бы предпочел изучить один синтаксис гнушного асма, которой для всех платформ одинаков, и не морочить себе голову.вполне согласен
> Инлайновый асм в gcc разве не портабелен ????(Кхе-кхе-кхе... Откашлявшись...)
Языки Ассемблера для всех микропроцессоров мира уже унифицировали?-) Не, ну чо, правда, да?-) Можно отдельно для ARM и отдельно для MIPS уже не изучать, достаточно x86?-)
унифицировали, уже давно. :) называется Си :))
>> Инлайновый асм в gcc разве не портабелен ????
>
>(Кхе-кхе-кхе... Откашлявшись...)
>
>Языки Ассемблера для всех микропроцессоров мира уже унифицировали?-) Не, ну чо, правда,
>да?-) Можно отдельно для ARM и отдельно для MIPS уже не
>изучать, достаточно x86?-)а шо твой АРМ настолько круче чем Интеловский проц ???
мне в интеловской архитектуре не хватает битовых операций. приходится применять всякие трюки, чтобы в критических местах увеличить скорость выполнения. а можно было бы сделать вообще одной асм-командой.
ну и т.д. там достаточно много таких концептуальных кривостей.
а шо их там нет ???
есть, но далеко не все.
сравним или будет толсто очень ?
> В современном мире _очень_ малая часть именно _программных продуктов_ может быть написана непереносимо.забавно, но подтверждается это только в опенсорсе. и как ни странно на сях (и очень местами - асм).
даже жаба поддерживает меньше платформ, чем ядро линуха к примеру (а ядро не в пример сложнее всяких xVM).зы:
есть только один плюс (да и плюсом он является только для маркетинга) - это удешевление разработки. серьезное удешевление.
>есть только один плюс (да и плюсом он является только для маркетинга)
>- это удешевление разработки. серьезное удешевление.почему же до сих пор нет такого же простого языка как Java но компилируемого на уровне Си если в одном серьёзное преимущество по скорости разработки а во втором по программ?
это называется диалектика. не может быть простым для каждого то, что сложно по определению.
а кому не сложно, того и С устраивает.
почитайте блоги Джонатана Шварца (бывшего главы сан) и с какой гордостью он говорит о количествах разработчиков на жабе. это ж целая армия! кмб 3-и месяца и новый специалист для ынтырпрайза готов.
у нас в качестве примера можно привести 1С.
чтобы франчайзи было легко писать (а значит и продавать!) должны очень не плохо поработать программисты в самом 1С и на С.
может теперь начнём говорить что одноэесовский язык лучше С? там вот тоже указателей нету. чтоб, ай-яй-яй, "партнеры" не заблудились ненароком.
вы понимаете как глупо звучит подобное сравнение?
из всех подобных решений, лично для меня только llvm интересен и внушает оптимизм. ибо сразу ставилась правильная цель, а не "как сократить себестоимость разработки" и не обсуждается по году-два "как это плохо, когда есть goto"
>почему же до сих пор нет такого же простого языка как Java но компилируемого на уровне Си >если в одном серьёзное преимущество по скорости разработки а во втором по программ?http://ru.wikipedia.org/wiki/D_(язык_программирования)
http://ru.wikipedia.org/wiki/Cyclone_(язык_программирования)
а существует ли проект по JIT-машине для LLVM-кода?
издеваетесь? он для этого и был придуман (в основном).
и на самом деле это и есть его единственный плюс (большой плюс) над другими.вот тут по-русски написано - http://ru.wikipedia.org/wiki/LLVM
>В основе LLVM лежит промежуточное представление кода (Intermediate Representation, IR), над которым можно производить трансформации во время компиляции, компоновки и выполнения. Из этого представления генерируется оптимизированный машинный код для целого ряда платформ, как статически, так и динамически (JIT-компиляция). LLVM поддерживает генерацию кода для x86, x86-64, ARM, PowerPC, SPARC, MIPS, IA-64, Alpha.но в оличае от остальных (где во главу угла ставилось удешевление разработки), он честно хотел выполнять код (не важно на чем писанный) без перекомпиляции на целом ряде платформ.
и интерес яблочников (которые резко переезжали с платформы) был понятен.
извините, я ещё не очень разбираюсь в вопросе
тоесть для LLVM существуют запускаемые аналоги jar в жаве? и есть возможность перед запуском (или при установке программы) собрать нативный код из этих "llvm-jar"?
зы: чтот все разговоры о llvm идут со смыслом "компилер Сей в натив с богатыми возможностями оптимизации на этапе байткода"
вообщето jar - это всего-лишь навсего архив. на основе arj. сам байт-код находится в *.class.
а как именно байт-код приедет к вам на корыто - не важно. по отдельному классу, в подписанном архиве - дело техники.главное это то, что llvm компилит все вначале в байткод (собственно также делает и gcc), а потом уже этот байткод под конкретную платформу либо в файл (также делает и gcc), либо на лету в память и выполняет как обычную программу (вот тут-то он и отличается от gcc). и делает он это максимально быстро (по крайней мере стремится. ведь это и есть цель проекта)
а так да, работа может быть похожа на загрузку jar из сети и его выполнения. но не в песочнице, а полноценно, нативно и т.д., и т.п.
в общем лично я считаю, что llvm - это очень большой конкурент .net может стать.
> вообщето jar - это всего-лишь навсего архив. на основе arj.вообщето jar - это всего-лишь навсего архив. на основе ZIP.
>Если на C с _ассемблерными вставками_, то есть, когда речь не идёт о переносимости кодаДа ну, почитайте код mplayer-а, работает на разных процессорах.
И кроме того есть такие либы как к примеру liboil
ок. привожу выдержки из книжки Джеффри Рихтера "CLR via C#". 2 издание. стр. 14
"вот особенности, которые позволяют управляемому коду опередить неуправляемый:
- JIT-компилятор может обнаруживать факт выполнения приложения на Core i series и сгенерировать машинный код, полностью использующий все преимущества особых комманд этого процессора. Неуправляемые приложения обычно компилируют в рассчете на среднестатистический процессор, избегая специфических комманд, которые заметно повышают производительность приложения на новейших процессорах.
- JIT компилятор может обнаруживать, что определенное выражение на конкретной машине всегда равно false. Например посмотрим на метод с таким кодом:
if (numberOfCPUs >1)
{...}
Здесь numberOfCPUs - число процессоров. Код указывает JIT-компилятору, что для машины с одним процессором не нужно генерировать никаких машинных комманд. В этом случае машинный код оптимизирован для конкретной машины, он короче и выполняется быстрее.
- CLR может проанализировать выполнение кода и перекомпилировать IL-код в команды процессора во время выполнения приложения. Перекомпилированный код может реорганизовываться с учетом обнаруженных некорректных прогнозов ветвления.Это лишь малая часть аргументов в пользу того, что управляемый код зачастую исполняется лучше неуправляемого.
"
> JIT-компилятор может обнаруживать факт выполнения приложения на Core i series и сгенерировать машинный кодJIT-компилятор ещё в памяти нуждается, отсюда жручесть
Опять же, задержка, связанная JIT-компилятцией может и как правило (ИМХО) перекрывает все преимущества возможно более быстрого кода
"с Моцартом я в корне не согласен" :)
С данным "Моцартом" практика не согласуется почему-то.
Не даром вопрос про быстродействие и жручесть возникает вновь и вновь, у людей постоянное недовольство жабой и т.п.
Теоретики такие теоретики.
нет, ну Вы правда считаете всё это аргументом в свою пользу? посмотрели бы чтоли в исходники gcc, правда, вроде взрослый человек, а такое писать. что из этого нет в компиляторах c++?
своих мыслей нет, будем цитатами форум загаживать?
всего этого нет и не может быть в компиляторе C++
можно начать с того, чем компилится сам jit? vm? на каком языке?
зы:
все усовершенствования появлятся вначале в сишном компиляторе, а уже потом идут дальше.
дело в том, что парой-тройкой новых регистров инновации не делаются. уже не делаются.
и чаще вообще есть только спецификации, которые только на асме и изобразишь.
путь до различных vm ой как далёк. не говоря уже о том, что они появляются только в новых версиях этих vm. да чтобы совместимость ещё не нарушить. а как часто это происходит?
ззы:
>JIT-компилятор может обнаруживать факт выполнения приложения на Core i series и сгенерировать машинный код, полностью использующий все преимущества особых комманд этого процессора.может конечно и обнаружить... а прогу можно и пересобрать. особенно в опенсорсе не проблемма.
вон, vp8/webm выпустили, а через день она уже и в фф, и в вебките,...
Рихтер - безусловно величина, но что Вы ожидали увидеть в книге по .NET, ее ведь продавать надо... На практике там где нужна скорость, программа компилируется с оптимизацией на все плюшки, которые есть у железа на которой ей предстоит крутиться, а если это для работы на "среднестатическом" железе то скорости и так с избытком, если алгоритмы не кривые.
>JIT-компилятор может обнаруживать факт выполнения приложения на Core [...] и сгенерировать машинный код, полностью использующийВах-вах, как же это mplayer бедный в рантайме проц детектит и использует соответствующую оптимизацию, без всякого jit-a, ужас-ужас, как страшно жить
Не бывает при одинаковых алгоритмах при реализации всего неуправляемого кода (включая, конечно же, код всей операционной системы) на языке Ассемблера.В остальных случаях -- бывает. Зависит от относительной квалификации программистов, пишущих управляемый и неуправляемый коды, библиотеки для неуправляемого кода, исполняющую систему управляемого и так далее.
> Зависит от относительной квалификации программистовЭто знаете ли вообще не аргумент.
При существенно различной квалификации всё что угодно может быть.
Тем не менее - накладные расходы управляемого кода никуда не денуться
>> Зависит от относительной квалификации программистов
>
>Это знаете ли вообще не аргумент.
>При существенно различной квалификации всё что угодно может быть.
>Тем не менее - накладные расходы управляемого кода никуда не денутьсяможно при установке приложения получить скомпилированный модуль в .NET используя встроенную утилиту NGEN.exe . Этим правда мало кто пользуется, потому что JIT все делает лучше на лету
Из perl тоже можно получить ексешник, только выигрыша почти нет.
Видимо с m$ поделием так же, потому и не пользуются
>делает лучше на летуВы только забыли сказать что стопицот рантайм проверок в тугих циклах гробят скорость в хлам а учтя общий вес рантайма - пока он раскочегарится, пройдет вплоть до нескольких минут. Прямо как на спекки с ленты, блин.
про это принято умалчивать в их кругах... хотя хитрые презентаторы делают свой код для презентации "быстрого кода" константные размеры массивов (например), тогда эти проверки можно и выкинуть. а в жизни используются обычно динамические размеры. и вот тут начинается слив явы и дотнета по полной программе.
или презентируют быстрый вызов функций в работе серверного апплета, когда все находится в памяти, скромно умалчивая о статичной компиляции программ на других языках.
ну и т.д. по списку.
>используя встроенную утилиту NGEN.exeПод wine-ом заведется? И этот человек трындит про кросплатформенность, омг
>> Зависит от относительной квалификации программистов
> Это знаете ли вообще не аргумент.Это, знаете ли, очень даже аргумент.
Меня не интересует сферический программный продукт в вакууме. Меня интересует конкретное время, которое потратит микропроцессор, для решения моей задачи. И вот решать он эту задачу будет вот по вот этой вот программе, которая есть. А не вон той, которую теоретически мог бы мне написать кто-нибудь уровня Эдсгара Дейкстры. :)
> При существенно различной квалификации всё что угодно может быть.
> Тем не менее - накладные расходы управляемого кода никуда не денутьсяДенуТСя. Учем рюскей езыг.
Денутся-денутся, ещё как денутся. Про on-the-fly-анализ кода с оптимизацией Branch Prediction уже сказано. Есть и ещё тонкости, такие, как, скажем, более оптимальная нагрузка на регистры микропроцессора (в C'шном коде сплошь и рядом "register int", и C-компилятор далеко не всегда правильно угадывает, что держать в регистрах, а что нет), ну и так далее.
> Меня интересует конкретное время, которое потратит микропроцессор, для решения моей задачи.Тем не менее сравнивают, как правило, при прочих равных условиях
> ДенуТСя. Учем рюскей езыг.
Не русский, виноват.
> в C'шном коде сплошь и рядом "register int", и C-компилятор далеко не всегда правильно угадывает, что держать в регистрах, а что нет
Ну блииииин... Вы C-компилер видели хотя бы? Много-много лет уже register игнорируется
это про оптимизацию ещё не говорили! :D
зы:
о Кольчугине до этого момента я был ГОРАЗДО лучшего мнения.
ну мало ли по какой причине человек пиарит разные вендор-специфик технологии... а сейчас смотрю - профан.
> о Кольчугине до этого момента я был ГОРАЗДО лучшего мнения.
> ну мало ли по какой причине человек пиарит разные вендор-специфик технологии... а
> сейчас смотрю - профан.Argumentum ad hominem. См. сюда: http://en.wikipedia.org/wiki/Ad_hominem за разъяснениями.
Epic Fail. :)
меня не интересуют аргументы для персоны.
меня интересуют только факты в конкретной технической дисциплине.всё остальное можете засунуть... ну вы знаете куда.
я разочарован.
> меня не интересуют аргументы для персоны.Кгхм. :)
Выучите же, наконец, латинский. :) Перевести "argumentum ad hominem" как "аргументы для персоны" -- это жёстко. ;)
Напоминает рассказ одной уважаемой преподавательницы по английскому языку, которая говорила своим студентам, что при переводе художественных текстов лучше сверяться со словарём, причём с фразеологическим.
Но всё равно студенты её не слушали. В результате чего рождались перлы. Вот один, который по мнению этой преподавательницы, должен украсить стены кожвендиспансера: фразу "like cures like" (что-то вроде "клин клином вышибают") студент перевёл как "любить, лечиться и снова любить!"
Вот перевод "argumentum ad hominem" примерно из этой же серии. ;)
http://ru.wikipedia.org/wiki/Ad_hominem
> Ну блииииин... Вы C-компилер видели хотя бы? Много-много лет уже register игнорируетсяДа полноте вам. Возьмите и дизассемблируйте кусочек чего-нибудь, скомпиленного С, с register и без register. Только кусочек хороший сами сотворите. Ну, функцию с десятком локальных переменных. И одну из них за'register'ьте.
Компилятор _может_ игнорировать квалификатор "register", как, собственно, и "inline". Вот именно поэтому, потому что _может_, и получается, что managed code ведёт себя лучше unmanaged.
много раз делал, когда экспериментировал с оптимизацией. еще с версии gcc 3.3 примерно. в gcc 2.95 и ниже не довелось как-то.
всегда зависило от ситуации, вообще-то. компилятор делает локальные оптимизации, поэтому "register" компилятором определяется как "здесь желательно использовать регистр".
> компилятор делает локальные оптимизации, поэтому "register" компилятором
> определяется как "здесь желательно использовать регистр".Это оно не компилятором так определяется, а стандартом языка. :)
Но сути дела это не меняет. А суть дела в том, что использование managed code позволяет делать динамические оптимизации, в ран-тайме. Вот теперь вот эта вот переменная стала что-то там часто использоваться, давайте мы её в РОН положим. А в C так не получится -- кодогенератор запускается один раз. ;)
Впрочем, нельзя сказать, что использование рантайм-оптимизаций сразу же заткнёт C за пояс. Конечно же, нет. Можно всегда отоптимизировать код на C до безумия.
Но именно этого делать в разработке программных продуктов и нельзя. На OpenNet'е уже, кажется, пролетала ссылка на презентацию OpenBSD'шника по Secure Programming'у. Там чётко сказано -- "оптимизируйте дизайн, а не код". "Весь код -- простой и надоедливый. "Умный" код -- источник ошибок".
И ведь это действительно так. IBM'ер же какой-то писал: "Если для понимания того, как работает ваш код, необходимо понимание тонких различий между ++i и i++, значит, ваш код слишком сложен". А сложный код -- это "странные" паники в самых неожиданных местах.
Впрочем, те, кто написал в своей жизни что-то сложнее, чем "Hello, World!", это и так знают. ;)
>Это оно не компилятором так определяется, а стандартом языка. :)в ранних версиях этого компайлера (до 3) вроде как дела обстояли несколько иначе. это я выяснил, когда находил некоторые несоответствия между прочитанным и генерируемым.
либо там была изменена/доработана/переработана система генерации оптимального кода, в котором "взвешиваются" возможные вариации, поэтому и "register" может в большинстве случаев просто игнорироваться, если его использование уменьшает оценку скорости кода.
но это так, догадки из практики. :)
>Можно всегда отоптимизировать код на C до безумия.это да. но есть слова "целесообразность" и "читабельность кода". что важно при производстве.
> "оптимизируйте дизайн, а не код". "Весь код -- простой и надоедливый. "Умный" код -- источник ошибок".двумя руками за. против безумного копипейстинга - монстры быстро раздуваются и в них потом невозможно проводить какой-то внутренний редизайн. страдает в том числе наглядность кода.
> Конечно же, нет. Можно всегда отоптимизировать код на C до безумия.Ну наконец то. Всё таки register не так уж страшен.
> необходимо понимание тонких различий между ++i и i++
Опять же, от ситуации зависит. Иногда приходится различать *p-- и *--p, а так же *p++ и *++p
Потому как *--p и *p++ транслируются в одну команду, в отличии от...
грип по исходникам плс.
или вы это из опыта с соляркой?
> Возьмите и дизассемблируйте кусочек чего-нибудь, скомпиленного С, с register и без register.Сделал. Ничего не изменилось. ЧЯСНТ?
> Вот именно поэтому, потому что _может_, и получается, что managed code ведёт себя лучше unmanaged.
Откуда такой "глубокий" вывод?
С чего Вы взяли, что register всегда ухудшает быстродействие?
>Есть и ещё тонкости, такие, как, скажем, более оптимальная нагрузка
>на регистры микропроцессора (в C'шном коде сплошь и рядом "register int",
>и C-компилятор далеко не всегда правильно угадывает, что держать в регистрах, а что нет)меня смущает почему до сих пор компиляторы "угадывают" что держать в регистрах, почему это до сих пор не продукт строгого расчёта под конкретную модель процессора?
> меня смущает почему до сих пор компиляторы "угадывают" что держать в регистрах,
> почему это до сих пор не продукт строгого расчёта под конкретную
> модель процессора?Что вам мешает в функции поставить "register"'ов больше, чем есть регистров у микропроцессора? И если вы так сделаете, какую именно переменную компилятор должен проигнорировать?
>> меня смущает почему до сих пор компиляторы "угадывают" что держать в регистрах,
>> почему это до сих пор не продукт строгого расчёта под конкретную
>> модель процессора?
>
>Что вам мешает в функции поставить "register"'ов больше, чем есть регистров у
>микропроцессора? И если вы так сделаете, какую именно переменную компилятор должен
>проигнорировать?ту которая наименее ухудшит быстродействие находясь в памяти :) а определять её уже надо анализируя алгоритм (а то что в сях нет стандартных возможностей указать компилятору вероятностную нагрузку по веткам ветлений и количество возмжных проходов в циклах - это недостаток сей)
> а то что в сях нет стандартных возможностей указать компилятору вероятностную нагрузку по веткам ветленийЕсть такая возможность с самого начала - более вероятные ветки ставят в начале
> и количество возмжных проходов в циклах
А это на что повлияет?
хорошие алгоритмы на Java будут быстрее плохих на C
а молоко белое.
а солнце круглое.
>бывают. мало того, программы,написанные на управляемом коде могут быть часто быстрее чем
>на неуправляемом.Наверное именно поэтому на форумах типа compression.* и прочая советуют выбросить C# нафиг и переписать компрессор на сях или если он навернутый - на плюсах. И да, народ почему-то фигеет с разницы в скорости потом :) ессно не в пользу дотнетов и яв :). Кстати в 2006 году одни чуваки тоже LSE обещали скорости. А в 2009 вылетели с LSE за то что не смогли обеспечить эту самую скорость. Get the facts, типа...
>программы,написанные на управляемом коде могут быть часто быстрее чем на неуправляемом.Может, хватит подобных анекдотов рассказывать?
PS Сам я за золотую середину - за ООП на компилируемых в машинный код языках.
бывают. Рекомендую изучить опции использования запуска программ, где указываются параметры памяти, если вы об этом.
Пример, пример дайте!
Быстрой и маложрущей программы на жабе.
Не надо опций, нужен пример!
маложрущее - оценочное определение.
Нужно сравнить с чем-то. Таки по сравнению с чем мало? С другой программой на Jave или с аналогичной по функционалу и писаной на другом языке?
Выше вопрос уважаемого dalco - "А быстрые и маложрущие программы на Java вообще бывают?"
Т.е. никчему масло масляное, кого интересует сравнение тормозов, другой программы на жабе не нужно.
Lightzone - шустрая, правда не сказал бы что очень мало памяти ест, но оно и с равами работает.
Не видел )
PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND
83865 openfire 90 44 0 503M 147M ucond 0 0:00 103.03% java
жесть дня :)
>Не видел )Энтерпрайзненько...
Всё ясно, закрывайте тред.
СУБД же должна быть быстрой? Секс ради девственности? А давайте станем писать драйвера для устройств на жаве? Это же удобно и быстро и может каждый!
> А давайте станем писать драйвера для устройств на жаве?Смех смехом, но находятся умники, которые пишут прошывки целиком на Java для ARM-ов с поддержкой Jazelle...
они наверное больные на голову, тем более что спеки на Jazelle не являются общедоступными, а потому сие означает большой гемор с NDA и прочей левой мутью. Ради чего?!
А что недостаточно быстрая? Может для начала стоит узнать где и как применяется а потом хаять? Или слово Java вызывает аллергию?
линукс на жабе уже выпустили? как, еще нет? непорядок. он же будет в разы быстрее чем на C! трухин, возьми на заметку.
hsqldb неплохая база. НО для разработки. :) Поэтому вопрос о скорости вообще неуместен. А по поводу исполнения кода, про оптимизацию под среднестатистический процессор - мило, очень мило. Ну естественно это относится только к среднестатистическим операционным системам. Может кто и игры пишет серьёзные на управляемом коде, под jit? Г-н Трухин наверно ток в них играет, ибо оч производительно. :) Это уже не опеннет, это башорг. :)
Типичное мнение человека, который не понимает назначение Java. Господа, ругающую якобы тормознутую Яву, обратите внимание, я объясню кое что.
Представьте себе игру (в принципе любое десктопное приложение). Особенностью таких программ является большое количество циклов выделения-освобождения памяти. Среда выполнения с автоматическим управлением памяти имеет в такой ситуации недостатки, исходящие из непредсказуемости начала работы сборщик мусора. Попадание на цикл сборки мусора во время динамичного эпизода игры испортит все впечатление, конечно же. Пожалуй, только по этому до сих пор игры пишут с ручным управлением памяти.
На серверах все иначе. Когда запускают серверное приложение, ему выделяют довольно большой кусок памяти, рассчитанный из нагрузки. Пул организован, дальше все крутится в нем, сборщик включается очень редко. Таки да, это те самые "серьезные системы", о которых вы все спрашиваете.
Java используется на серверах с гигабайтами ОЗУ и во встроенных устройствах с парой сотен КБ. И там и там прекрасно справляется, все дело в стратегии работы приложений. На десктопе обычно другие сценарии. Нужна отзывчивость и кооперативность с другими приложениями. А исполнение байткода в Java очень быстрое, и JIT это действительно мощная вещь. Тормоза не из-за них.
Я не ругаю джаву за тормоза. Вы видимо не правильно интерпретировали мою мысль. Джава по моему мнению одна из мощнейших технологий. сам на ней пишу уже много лет. Второй мой язык. Но hsqldb, действительно подходит только на начальном этапе разработки со всякими там ORM. Дальше все по моему опыту уходит в сторону постгре (это конечно мой выбор, спорить не буду).
>hsqldb неплохая база. НО для разработки. :) Поэтому вопрос о скорости вообще
>неуместен. А по поводу исполнения кода, про оптимизацию под среднестатистический процессор
>- мило, очень мило. Ну естественно это относится только к среднестатистическим
>операционным системам. Может кто и игры пишет серьёзные на управляемом коде,
>под jit?Несколько лет назад попадалась игра(вестимо под Виндовз) так при установке требовала наличия дотнету. Зачем ей дотнет не знаю, но вот что было.
>>hsqldb неплохая база. НО для разработки. :) Поэтому вопрос о скорости вообще
>>неуместен. А по поводу исполнения кода, про оптимизацию под среднестатистический процессор
>>- мило, очень мило. Ну естественно это относится только к среднестатистическим
>>операционным системам. Может кто и игры пишет серьёзные на управляемом коде,
>>под jit?Для XBOX на XNA написано очень много игр на управляемом коде на языке C#
И почти все - простые двухмерные игры, в которых не нужно беспокоиться о быстродействии
http://www.youtube.com/watch?v=TgChURF5fQE
можешь скачать, поиграть http://exdream.com/XnaRacingGame/
Без винды?
Постыдился бы такую муть показывать.
На первый взгляд отстой, графика 5-7 летней давности. чтд
>Постыдился бы такую муть показывать.
>На первый взгляд отстой, графика 5-7 летней давности. чтдВообще-то в описании ролика написано, что это только заготовка для игры, притом, похоже, сделанная в одиночку.
>XNA Racing Game Starter Kit I wrote for http://creators.xna.com
Отличная новость. База идеальна для быстрого выполнения интеграционных тестов DAO слоя, когда применяются ORM фреймворки(Hibernate, JPA). Особенно она эффективна при размещении в оперативной памяти.
а ты не в курсе, как у нее с масштабируемостью?