|
|
|
О применимость языков
|
|||
|---|---|---|---|
|
#18+
Иной раз читая topics вижу буйную фантазию и фейерверк непоколебимо "истинных" суждений ... Иногда правда бывает желание "обсудить" их, но часто осаждаю себя мыслью типа - "Ты разве не знаешь чем все это закончится? Займись ка лучше Владимир текущей работой - больше толку будет" ... PS: Нет ну действительно иногда парни так настойчивы в своих "истинных" суждениях, что лучше к ним и "не подходить" ... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.09.2015, 20:54 |
|
||
|
О применимость языков
|
|||
|---|---|---|---|
|
#18+
AdxЗимаргл, Сравнивать визуальные оболочки, написанные на разных системах/языках, абсурдно. Я под С++ и C# напишу десяток разных интерфейсов с разными характеристиками. Сравнивать нужно одинаковый код, насколько это возможно, конечно. И уж визуальные библиотеки подходят для этого меньше всего. А то давайте тогда сравним MS Paint и Adobe Photoshop по памяти и скорости загрузки. Т.е ты не в состоянии написать одинаковое окошко на разных языках. Я понял. Балаболы не нужны. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.09.2015, 20:57 |
|
||
|
О применимость языков
|
|||
|---|---|---|---|
|
#18+
Владимир2012PS: Нет ну действительно иногда парни так настойчивы в своих "истинных" суждениях, что лучше к ним и "не подходить" ... Да. Мы такие бро. Мы пережили Луговского с его С++срачем. Переварили Дедала с Базистом. Что-уж нам. А прикинь что Зимаргл и Adx - это один и тот-же человек. И спорит сам с собой... Мдя... И такое бывает. А ты думал тут фе. А тут Ооооо! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.09.2015, 21:58 |
|
||
|
О применимость языков
|
|||
|---|---|---|---|
|
#18+
ЗимарглТы не тот скорее всего параметр смотришь. Минимальный футпринт дНет приложения занимает примерно 10Мб в памяти. Я писал выше, что смотреть в диспетчере задач. Большинство управляемых сред сразу выделяют пул памяти для приложения. За счёт этого дальшейшее выделение памяти под объекты происходит очень быстро. Именно по скорости выделения памяти дотнет рвёт нативный код как Тузик тряпку. И пока в системе достаточно свободной памяти, дотнет не будет её отдавать. Но как только память кончится, ОС пнёт CLR, та станет пинать сборщик мусора, он проснётся и удалит мусор, и неиспользуемую память отдаст. Так что минимальный футпринт будет много меньше мегабайта. Если позарез необходимо, футпринт можно уменьшить вручную: Код: c# 1. 2. 3. 4. 5. 6. 7. 8. 9. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.09.2015, 00:13 |
|
||
|
О применимость языков
|
|||
|---|---|---|---|
|
#18+
petalvikБольшинство управляемых сред сразу выделяют пул памяти для приложения. За счёт этого дальшейшее выделение памяти под объекты происходит очень быстро. Именно по скорости выделения памяти дотнет рвёт нативный код как Тузик тряпку. Вы имеете в виду, что нативный код отдельно дёргает системный вызов ради каждых шестнадцати байт? Не секрет ли, где Вы такой нативный код видели? :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.09.2015, 00:40 |
|
||
|
О применимость языков
|
|||
|---|---|---|---|
|
#18+
petalvikИменно по скорости выделения памяти дотнет рвёт нативный код как Тузик тряпку. И пока в системе достаточно свободной памяти, дотнет не будет её отдавать. [/src] А толку то? :) В нативном коде можно написать менеджер памяти, который порвет как тузик грелку этот дотнет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.09.2015, 02:02 |
|
||
|
О применимость языков
|
|||
|---|---|---|---|
|
#18+
Верно ли то, что на Java программист не может писать иначе как в ОО стиле ? Вот что BS пишет о С++: BS Язык программирования С++C++ создавался с целью добавления поддержки абстракции данных, объектно-ориентированного и обобщенного программирования к традиционному языку С с учётом указанных ограничений. Не подразумевалось принуждение всех пользователей к какому-либо конкретному стилю программирования. И если первое утверждение верно, и с учётом второй цитаты(в целом достаточно очевидной с точки зрения информативности, но от этого не менее важной), даже если бы программы на Java работали со скоростью аналогичной с С++(кто-то выше говорил, что 2, 2,5 раза ерунда, однако представьте если бы время отклика на каждую операцию на вашем домашнем компьютере увеличилось бы хотя бы в два раза), даже несмотря на это, С++ был бы предпочтительней. Я может быть что-то пропустил, а что создатели Java говорят о своём языке, если можно, процитируйте пожалуйста. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.09.2015, 02:35 |
|
||
|
О применимость языков
|
|||
|---|---|---|---|
|
#18+
SashaMercuryВерно ли то, что на Java программист не может писать иначе как в ОО стиле ? Выучишь Java - узнаешь. SashaMercuryИ если первое утверждение верно, и с учётом второй цитаты(в целом достаточно очевидной с точки зрения информативности, но от этого не менее важной), даже если бы программы на Java работали со скоростью аналогичной с С++(кто-то выше говорил, что 2, 2,5 раза ерунда, однако представьте если бы время отклика на каждую операцию на вашем домашнем компьютере увеличилось бы хотя бы в два раза), даже несмотря на это, С++ был бы предпочтительней.А зачем нам это представлять? Мы программами на Java пользуемся практически постоянно. Например все утилиты управления базами данных написаны на Java, ну кроме MSSQL для которой пишут на .Нет. Так проще делать кросс-платформенный код. Все телфоны и планшеты с Android внутри - java. Предпочтительней? Кому? Пользователям пофиг. Разработчикам - Java проще. Выиграем мы (пользователи) если все это будет переписано на С++? Ну да, пару-тройку микросекунд выиграем. А толку? SashaMercuryЯ может быть что-то пропустил, а что создатели Java говорят о своём языке, если можно, процитируйте пожалуйста.Открываешь учебник по Java и читаешь. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.09.2015, 06:01 |
|
||
|
О применимость языков
|
|||
|---|---|---|---|
|
#18+
1. Если Java поддерживает только программирование с ОО стиле, то в этом плане этот язык однобок. Или у нас 99 % задач должны решаться в объектно-ориентированном стиле ? 2. Смотря какая операция, где-то мы проиграем пару микросекунд, а где-то несколько секунд. От этого факт не изменится, какое-то время мы потеряем практически на любых задачах. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.09.2015, 06:20 |
|
||
|
О применимость языков
|
|||
|---|---|---|---|
|
#18+
SashaMercury1. Если Java поддерживает только программирование с ОО стиле, то в этом плане этот язык однобок. Или у нас 99 % задач должны решаться в объектно-ориентированном стиле ? Писать в процедурном стиле можно и на ОО языках. SashaMercury2. Смотря какая операция, где-то мы проиграем пару микросекунд, а где-то несколько секунд. От этого факт не изменится, какое-то время мы потеряем практически на любых задачах. Таких операций очень мало когда критично время. Если пишешь клиентскую часть - их всего 0,1%, зато куча кода типа "если нажали эту кнопочку - показать эту форму" и не критично покажется она за 50 мс или за 150 мс. Также не критично займет форма 1 Мб или 3 в памяти. А те критичные к времени и/или памяти 0,1% можно написать на чем-нибудь другом. Я пишу на С, делаю DLL и ее использую. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.09.2015, 07:22 |
|
||
|
О применимость языков
|
|||
|---|---|---|---|
|
#18+
[quot Dima T]SashaMercury1. Если Java поддерживает только программирование с ОО стиле, то в этом плане этот язык однобок. Или у нас 99 % задач должны решаться в объектно-ориентированном стиле ? Писать в процедурном стиле можно и на ОО языках. [quot] И Си в какой-то мере позволяет писать программы в ООС. Однако, BS, например, говорит: Язык поддерживает определенный стиль программирования в том случае, если он представляет средства которые делают использование данного стиля удобным. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.09.2015, 07:27 |
|
||
|
О применимость языков
|
|||
|---|---|---|---|
|
#18+
SashaMercuryDima TПисать в процедурном стиле можно и на ОО языках. И Си в какой-то мере позволяет писать программы в ООС. Однако, BS, например, говорит: Язык поддерживает определенный стиль программирования в том случае, если он представляет средства которые делают использование данного стиля удобным. Это не противоречит тому что я написал. Там не утверждается что в ОО языках неудобно писать в не ОО стиле. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.09.2015, 07:39 |
|
||
|
О применимость языков
|
|||
|---|---|---|---|
|
#18+
FactorizepetalvikИменно по скорости выделения памяти дотнет рвёт нативный код как Тузик тряпку. И пока в системе достаточно свободной памяти, дотнет не будет её отдавать. [/src] А толку то? :) В нативном коде можно написать менеджер памяти, который порвет как тузик грелку этот дотнет. Можно ускорить аллокации к примеру. При деаллокациях вам придётся выбрирать между расходом памяти и скоростью особождения и дефрагментации. Вобщем на любой аллокатор можно написать контр-пример его использования. Кстати вопрос написания умного аллокатора неизбежно приводит к появлению различного рода т.н. "умных указателей" и концепции GC. Круг обсуждения снова замкнётся на эффективных алгоритмах мусоросборки. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.09.2015, 08:25 |
|
||
|
О применимость языков
|
|||
|---|---|---|---|
|
#18+
ЗимарглAdxЗимаргл, Сравнивать визуальные оболочки, написанные на разных системах/языках, абсурдно. Я под С++ и C# напишу десяток разных интерфейсов с разными характеристиками. Сравнивать нужно одинаковый код, насколько это возможно, конечно. И уж визуальные библиотеки подходят для этого меньше всего. А то давайте тогда сравним MS Paint и Adobe Photoshop по памяти и скорости загрузки. Т.е ты не в состоянии написать одинаковое окошко на разных языках. Я понял. Балаболы не нужны. На WinApi? Без проблем. Вы не понимаете разницу между библиотекой, языком и платформой. Увы. Любителям сравнивать по скорости и цене автомобили Мерседес А класс и Ладу Калину - читать книжки. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.09.2015, 10:42 |
|
||
|
О применимость языков
|
|||
|---|---|---|---|
|
#18+
softwarerВы имеете в виду, что нативный код отдельно дёргает системный вызов ради каждых шестнадцати байт? Не секрет ли, где Вы такой нативный код видели? :) Вижу в каждом первом приложении. FactorizeА толку то? :) В нативном коде можно написать менеджер памяти, который порвет как тузик грелку этот дотнет. В дотнете как раз и используется такой менеджер памяти. Да, его можно написать в неуправляемых языках, но это будет по сути то, что уже есть в управляемых средах. Где этот менеджер будет брать память? Из пула. Память под этот пул запрашивается у операционной системы на старте приложения. Оп-па! То есть футпринт приложения стал большим. Именно к большому футпринту дотнета были претензии. Так что либо расход памяти под пул (большой футпринт) и быстрое её выделение, либо медленное выделение и малый футпринт. К тому же по выделению памяти этот менеджер не порвёт дотнет. По освобождения - да, запросто. Там, где GC будет долго пыхтеть, в рукописном менеджере можно одним махом отдать весь этот пул обратно системе. А теперь главное: покажите мне менеджер памяти, который отдаст неиспользуемую в данный момент память по запросу ОС. Между тем CLR/JVM это сделают. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.09.2015, 17:18 |
|
||
|
О применимость языков
|
|||
|---|---|---|---|
|
#18+
Я прошу понять меня правильно. Я не пытаюсь оспорить тот факт, что нативный код быстрей управляемого. Это очевидно. Я не считаю, что управляемые среды лучше нативного кода. Я считаю, что они являются тупиковой ветвью развития в своём нынешнем виде и со временем должны умереть. Так же как интерпретаторы и динамически-типизированные языки. Однако, дотнет движется в правильную сторону. Не так давно появился .NET Native - компиляция в нативный код при развёртывании приложения. Ускоряет загрузку, улучшает быстродействие. При этом остаётся удобство управляемого кода во время разработки. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.09.2015, 17:23 |
|
||
|
О применимость языков
|
|||
|---|---|---|---|
|
#18+
petalviksoftwarerВы имеете в виду, что нативный код отдельно дёргает системный вызов ради каждых шестнадцати байт? Не секрет ли, где Вы такой нативный код видели? :) Вижу в каждом первом приложении. Ну попробуйте посмотреть во второе, что ли. petalvikДа, его можно написать в неуправляемых языках, но это будет по сути то, что уже есть в управляемых средах. Уважаемый, как бы Вам сказать деликатно.... его не "можно написать в неуправляемых языках". Его "написали в них", причём задолго до того, как кому-то пришло в голову сделать "управляемые среды", если не считать такой Пи-систему . ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.09.2015, 17:23 |
|
||
|
О применимость языков
|
|||
|---|---|---|---|
|
#18+
maytonВладимир2012PS: Нет ну действительно иногда парни так настойчивы в своих "истинных" суждениях, что лучше к ним и "не подходить" ... Да. Мы такие бро. Мы пережили Луговского с его С++срачем. Переварили Дедала с Базистом. Что-уж нам. А прикинь что Зимаргл и Adx - это один и тот-же человек. И спорит сам с собой... Мдя... И такое бывает. А ты думал тут фе. А тут Ооооо! Данный пост найден средствами всемогущего Стебелька . Бойтесь, бойтесь бородатые Оракловоды ! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.09.2015, 19:27 |
|
||
|
О применимость языков
|
|||
|---|---|---|---|
|
#18+
Вот как раз по *выделению* памяти языки с GC однозначно рвут С++. Управляемый хип позволяет относительно перемещать данные в памяти, что сильно упрощает аллокацию. На каждый поток приложения выделяется свой буфер под аллокации и вперед. Никакой синхронизации не надо, искать подходящего размера "дырки" в выделенной памяти не надо. Просто увеличиваешь текущий указатель на нужный тебе размер и вперед. Когда буфер заканчивается, просто аллоцируется новый. А получившееся мессиво из аллоцированных и свободных кусков уплотняется дефрагментатором параллельно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.09.2015, 19:40 |
|
||
|
О применимость языков
|
|||
|---|---|---|---|
|
#18+
softwarerего не "можно написать в неуправляемых языках". Его "написали в них", причём задолго до того, как кому-то пришло в голову сделать "управляемые среды" В неуправляемом коде по умолчанию память как будет выделяться? Может, всё-таки, нужно дополнительно менеджер памяти писать/брать откуда-то, для быстрой аллокации? LISP считаем управляемой средой? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.09.2015, 20:48 |
|
||
|
О применимость языков
|
|||
|---|---|---|---|
|
#18+
petalvikВ неуправляемом коде по умолчанию память как будет выделяться? Ответ ровно тот же, что и для управляемого. Так, как по умолчанию работает менеджер памяти соответствующей RTL библиотеки. petalvikМожет, всё-таки, нужно дополнительно менеджер памяти писать/брать откуда-то, для быстрой аллокации? Сомневаюсь. Я ровно один раз в жизни видел менеджер памяти, который выделял память описанным Вами способом - через системные вызовы - и как раз его требовалось "откуда-то брать и специально подключать". В принципе, я допускаю, что где-то сохранились компиляторы, чьи RTL работают таким способом, но сомневаюсь в их распространённости. Впрочем, даже если так - не вижу смысла пол-дня ломать копья из-за "проблемы", которая решается за тридцать секунд. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.09.2015, 21:11 |
|
||
|
О применимость языков
|
|||
|---|---|---|---|
|
#18+
petalvikЗимарглТы не тот скорее всего параметр смотришь. Минимальный футпринт дНет приложения занимает примерно 10Мб в памяти. Я писал выше, что смотреть в диспетчере задач. Большинство управляемых сред сразу выделяют пул памяти для приложения. За счёт этого дальшейшее выделение памяти под объекты происходит очень быстро. Именно по скорости выделения памяти дотнет рвёт нативный код как Тузик тряпку. И пока в системе достаточно свободной памяти, дотнет не будет её отдавать. Но как только память кончится, ОС пнёт CLR, та станет пинать сборщик мусора, он проснётся и удалит мусор, и неиспользуемую память отдаст. Так что минимальный футпринт будет много меньше мегабайта. Это не совсем так. В WindowsXP и выше С++ CRT использует родной ОС менеджер хипа (::HeapAlloc() etc) . Не особо вижу, как надстройка CLR над этим же менеджером может что то ускорить ) Подтверждение этого можно увидеть, открыв исходники CRT. Далее, если верить Руссиновичу, по дефолту хип 1Мб. Соответственно, футпринт меньше можно сделать только в нативном коде, вмешиваясь в исходник CRT, и никак иначе. AdxЗимарглпропущено... Т.е ты не в состоянии написать одинаковое окошко на разных языках. Я понял. Балаболы не нужны. На WinApi? Без проблем. Вы не понимаете разницу между библиотекой, языком и платформой. Увы. Любителям сравнивать по скорости и цене автомобили Мерседес А класс и Ладу Калину - читать книжки. Если ты не понял, то мы и сравниваем Формулу1 в виде С++ и дНет как что то типа Ларгуса с прицепом на все случаи жизни. Первый результат я уже получил. Одинаковые приложения: на компилируемом языке имеет при загрузке 3х кратный выигрыш по ошибкам страниц по сравнению с JVM. Окошки SWT и там и там Допишу какие нибудь циклы и таймеры и посмотрю как прогрессирует. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.09.2015, 21:36 |
|
||
|
О применимость языков
|
|||
|---|---|---|---|
|
#18+
petalvikLISP считаем управляемой средой? Лисп вообще-то был пионером в области управляемых куч (сред?). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.09.2015, 23:09 |
|
||
|
О применимость языков
|
|||
|---|---|---|---|
|
#18+
ЗимарглНе особо вижу, как надстройка CLR над этим же менеджером может что то ускорить это не надстройка ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2015, 00:35 |
|
||
|
О применимость языков
|
|||
|---|---|---|---|
|
#18+
ЗимарглПервый результат я уже получил. Одинаковые приложения: на компилируемом языке имеет при загрузке 3х кратный выигрыш по ошибкам страниц по сравнению с JVM. Окошки SWT и там и там Допишу какие нибудь циклы и таймеры и посмотрю как прогрессирует. Тест для медитации Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. Принцип следующий: делается проекция файла в память и считается контрольная сумма. По сути загрузка фрэймворка технически тоже самое. Первый запуск Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. Ошибок страниц 459291 Второй запуск Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. Ошибок страниц 459290 Для тестов взял файл 895 Mb. Как видишь в первом случае первый расчет шел 8 сек, во втором 0,7 сек. Т.е. 7,3 сек в первый раз это чтение файла с диска, во второй - файл уже был в кэше виндовса. Ну и по расходу памяти: один процесс занимает ожидаемые 920 Мб. Запускаем одновременно 4 копии, каждая занимает по 920, у каждой по 459 тыс. ошибок страниц. Но памяти у меня всего 2,4 Гб свободно. При одновременно работающих 4 копиях размер свободной памяти падает с 2,4 Гб до 1,5 Гб. Т.е. физически в памяти одна копия, которая по очереди подсовывается в каждый процесс. Все тоже самое касается фрэймворка .Net/Java: если он уже в памяти, то расходы на его подсовывание в конкретный процесс незначительны. В нативном коде при вызове WinAPI происходит тоже самое. Это я все к тому что показатель "Ошибок страниц" ничего полезного не показывает. Есть такой параметр как "Ошибок страниц/сек", т.е. сколько было за последнюю секунду. Вот он более реально показывает насколько интенсивно используется подкачка с диска в конкретный момент. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2015, 09:00 |
|
||
|
|

start [/forum/topic.php?fid=16&msg=39042010&tid=1340912]: |
0ms |
get settings: |
8ms |
get forum list: |
13ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
182ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
74ms |
get tp. blocked users: |
1ms |
| others: | 238ms |
| total: | 534ms |

| 0 / 0 |
