131 ответов в теме

[euroUK]

 

VM питона в плане памяти компактнее дНета (примерно вдвое на маленьких програх) и уж тем более Явы (это ппц). В связи с этим UI на нем отзывчивее (и программа запускается быстрее).

 

Как раз-таки более компактный по теории приложений = менее быстрый. Всегда есть баланс между скоростью и размером. У меня не было ни разу проблем с UI на .Net и скоростью запуска.

 

 

Очень зря, развиваться нужно же. Я вот на днях Elixir изучил (+Phoenix, Ecto, Mix и прочие приблуды).

 

Опять же, вкусовщина. Я вот ненавижу c#. Несколько раз приходилось писать на нём и каждый раз был болью, потому что много костыльных решений для проблем, которых просто нету в нормальных языках, и часто ни одного нормального. (Из дзена Python: должен быть один и, желательно, только один способ сделать что-то.)

 

После C++ костыли C# - это не костыли, а просто Тесла какая-то. Если учесть, что в C++ я 80% времени занимался выделением памяти, а еще 20% компиляцией всего этого добра. На питонах я не писал никогда, но вот по сравнению с Java, .Net просто великолепен. Из последнего. TimeSpan (или как он там в Яве), у меня выводил 3 часа 25 секунд, например, он с какого-то хера считал GMT+3. Ну а работа с Датой в Яве вообще шедевральна. 

 

Еврук тоже не может. Не различает выделенную память от виртуальной.

 

Мне как пользователю, например на машине с 4 ГБ памяти, видно, что процесс отжирает 600 МБ. То, что это виртуальная машина, а сам код занимает 30, какая мне разница? 

[unti1x]

Как раз-таки более компактный по теории приложений = менее быстрый.

С чего бы это? Ты хочешь сказать, что мой полукилобайтный интерпретатор брейнфака будет грузить хеллоуворлд медленнее шарпа?

 

А есть ещё такая штука, как PyPy. Это интерпретатор питона, написанный на питоне. ИЧСХ, он в общем случае работает быстрее.

[Xiemargl]

Как раз-таки более компактный по теории приложений = менее быстрый. Всегда есть баланс между скоростью и размером. У меня не было ни разу проблем с UI на .Net и скоростью запуска.

 
Экий бред. Маленький код быстрее при прочих равных.
Проблем с нетом у тебя нет, потому что на современных машинах ты этого не видишь.
Когда интерфейс Студии переписали на Нет (2010), вою на форумах было.

Мне как пользователю, например на машине с 4 ГБ памяти, видно, что процесс отжирает 600 МБ. То, что это виртуальная машина, а сам код занимает 30, какая мне разница?

Ты даже не понял что я сказал.
Гугли committed memory vs working set

[Droopstone]

Как раз-таки более компактный по теории приложений = менее быстрый. Всегда есть баланс между скоростью и размером.

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

 

Если учесть, что в C++ я 80% времени занимался выделением памяти.

Это всего-лишь говорит о том, что ты писал на C с классами, а не на C++

Сообщение отредактировал Droopstone: 14 October 2016 - 13:14

[euroUK]

С чего бы это? Ты хочешь сказать, что мой полукилобайтный интерпретатор брейнфака будет грузить хеллоуворлд медленнее шарпа?

 

А есть ещё такая штука, как PyPy. Это интерпретатор питона, написанный на питоне. ИЧСХ, он в общем случае работает быстрее.

 

Хеллоу ворд не пример. Речь идет про структуры данных, например. Тот же HashMap и LinkedHashMap. Первый меньше памяти, второй хранит больше информации, поэтому если предполагается использовать этот Хэш разными способами, то сохранение порядка может быть полезным и сократить процессорное время? Кучу вещей вообще можно хранить в сжатом виде, но платить за это придется процессорным временем.

Более того,  компилятор C++ разворачивает мелкие циклы. Программа занимает памяти больше, но работает быстрее.

 

 
Экий бред. Маленький код быстрее при прочих равных.
Проблем с нетом у тебя нет, потому что на современных машинах ты этого не видишь.
Когда интерфейс Студии переписали на Нет (2010), вою на форумах было.

 

Ты не путай маленький код и маленькую оснастку. Если ты тащишь с собой кучу ненужных библиотек, то понятно, что загружается медленнее. А так, чем больше избыточности ты хранишь (OLAP например), тем быстрее работает код. 

Моя практика говорит о том, что это не так. В частности, компактность может достигаться порождением компилятором макаронного кода с кучей переходов.

Это всего-лишь говорит о том, что ты писал на C с классами, а не на C++

 

Да шаблонами я не очень пользовался, тут согласен. 

[Midael]

Ой ли? Для меня в Пифе есть один существенный недостаток - UI выглядит вырвиглазно и работает также. Скорость работы оставляет желать лучшего, хотя чему там тормозить - не ясно.

.Net, в объеме данного приложения, отлично работает на Mono.

Mono не вариант для десктопной проги, потому что gtksharp помер (да и гтк в винде (про мак не знаю) это то еще говнецо, фактически линукс онли тулкит), а их версия винформс...ну лучше не надо. 

Компилируемых кроссплатформенных вариантов для гуя ровно два - жаба (fx/swing) или кресты (qt). Есть еще модный хипстерский вариант с электроном.

 

Идея запилить свой интерфейс шоб работало быстро и как в ефт на эосе (движок пифы) выглядит заманчиво, но есть подозрение, что тормоза интерфейса все же не от WXWidgets, а от движка. Надо будет попрофилировать на досуге что-ли.

 

Хотя сильно погружаться в питон (тут должна быть известная картинка) не хочется

Сообщение отредактировал Midael: 14 October 2016 - 13:58

[unti1x]

Программа занимает памяти больше, но работает быстрее.

Это совсем не то быстрее, про которое мы говорим. Разворачиваются далеко не все циклы, а только те, по которым всё понятно. В результате вместо одного запуска получается 2*n (в зависимости от процессора) запусков на проход. Прирост там исключительно за счёт уменьшения издержек на обрабоку кода, он минимальный и значительно влияет только на большой объём данных.

 

 

Хеллоу ворд не пример.

Окей, давай сравнивать с тем, что может брейнфак, например, вычисление чисел Фибоначчи. На тех объёмах, на которых просто работать с брейнфаком он будет чуть быстрее потому, что интерпретатор будет быстрее запускаться, а не потому, что код хороший.

Идея запилить свой интерфейс шоб работало быстро и как в ефт на эосе (движок пифы) выглядит заманчиво, но есть подозрение, что тормоза интерфейса все же не от WXWidgets, а от движка. Надо будет попрофилировать на досуге что-ли.

У ДаркФеникса есть реп с переписанным с нуля движком. Он там что-то начинал мутить для интерфейса, не знаю, как сейчас дела.

[euroUK]

 

Окей, давай сравнивать с тем, что может брейнфак, например, вычисление чисел Фибоначчи. На тех объёмах, на которых просто работать с брейнфаком он будет чуть быстрее потому, что интерпретатор будет быстрее запускаться, а не потому, что код хороший.

 

Я говорю о приложениях реальных. Самый простой пример говнокода.

 

Ты десериализуешь данные. Если данные меняться не должны - ты пишешь просто array, памяти-то он жрет меньше, правилно? Потом Вася, получает его по ссылке, и, неожиданно, ему нужно будет туда что-то добавить, фиг знает почему. Что сделает Вася, будучи Васей?

Ясен пень, создаст копию ToList() и добавит туда. В результате, работать это быстрее уже не будет. Понятно, что это говнорешения, но в жизни - 90% именно таких программ.

Сообщение отредактировал euroUK: 14 October 2016 - 13:31

[unti1x]

Я говорю о приложениях реальных. Самый простой пример говнокода.

 

Ты десериализуешь данные. Если данные меняться не должны - ты пишешь просто array, памяти-то он жрет меньше, правилно? Потом Вася, получает его по ссылке, и, неожиданно, ему нужно будет туда что-то добавить, фиг знает почему. Что сделает Вася, будучи Васей?

Ясен пень, создаст копию ToList() и добавит туда. В результате, работать это быстрее уже не будет. Понятно, что это говнорешения, но в жизни - 90% именно таких программ.

При чём тут говнорешения? Мы говорим о корреляции размеров виртуальных машин и скорости запуска программ в них, а ты о чём-то левом.

 

А сейчас ещё и сам себе начинаешь противоречить.

 

Я это к чему всё? В общем случае зависимости нет.

Сообщение отредактировал unti1x: 14 October 2016 - 13:41

[euroUK]

Я говорю о том, что далеко не всегда компактность кода увеличивает реальное быстродействие этого кода. Хотя загрузка компактного кода, кончено же, происходит быстрее. Именно поэтому в копиляторе С++ есть разные варианты компиляции.

[Xiemargl]

Да, Еврук съехал на неэффективную работу с данными, которая вообще тут не при чем.

Но от размера фреймворка время запуска очень даже зависит. Просто JVM и прочие делают это заметнее,
т.к. это VM со своими накладными расходами.

Как пример - программы с "девками" (DevExpress)

[unti1x]

Я говорю о том, что далеко не всегда компактность кода увеличивает реальное быстродействие этого кода. Хотя загрузка компактного кода, кончено же, происходит быстрее. Именно поэтому в копиляторе С++ есть разные варианты компиляции.

Всё начиналось именно с того, что ты сказал, что чем меньше программа, тем медленнее

[Xiemargl]

Я говорю о том, что далеко не всегда компактность кода увеличивает реальное быстродействие этого кода. Хотя загрузка компактного кода, кончено же, происходит быстрее. Именно поэтому в копиляторе С++ есть разные варианты компиляции.

Да до опций оптимизации С++ от VM как до Луны. Не приплетай, ты бы еще атомы вспомнил.

[euroUK]

Как пример - программы с "девками" (DevExpress)

 

DevExpress разве есть под Java?

 

Всё начиналось именно с того, что ты сказал, что чем меньше программа, тем медленнее

 

При одинаковом уровне технологий и качества кода, так оно и есть.

Загрузка != скорости работы, от слова никак.

[Midael]

А есть ещё такая штука, как PyPy. Это интерпретатор питона, написанный на питоне. ИЧСХ, он в общем случае работает быстрее.

PyPy это реализация питона с JIT-компилятором. Поэтому и работает он быстрее основной реализации. Кстати интересно было бы попробовать запустить пифу через него (правда у ПИПИ есть проблемы с обращением к нативным библиотекам, так что скорее всего не взлетит)

[advena]

Здравствуйте, это канал про аниме?

 

 

Давайте куда-нибудь переместимся ибо уже оффтоп пошёл

[unti1x]

При одинаковом уровне технологий и качества кода, так оно и есть.

Абсолютно нет. Если в двух программах код идеален и суперсовременен, то из них двух быстрее будет работать та, которая меньше, при условии аналогичных условий для виртуальных машин (+считаем, что у них одинаковая архитектура). На практике так не бывает и быстрее работает то, что лучше оптимизировано, а это совсем не значит увеличение или уменьшение размера.

PyPy это реализация питона с JIT-компилятором. Поэтому и работает он быстрее основной реализации. Кстати интересно было бы попробовать запустить пифу через него (правда у ПИПИ есть проблемы с обращением к нативным библиотекам, так что скорее всего не взлетит)

Обычный питон тоже с житом.

Здравствуйте, это канал про аниме?

 

Давайте куда-нибудь переместимся ибо уже оффтоп пошёл

Ничего не оффтоп. Нам тут пытаются доказать, что пифа хуже потому, что питон плохой.

[Midael]

Обычный питон тоже с житом.

Ммм, нет, там обычный интерпретатор  байткода (я о JIT который компилирует в машкод с оптимизациями, навроде того что есть в jvm и clr)

Сообщение отредактировал Midael: 14 October 2016 - 14:05

[unti1x]

Ммм, нет, там обычный интерпретатор  байткода (я о JIT который компилирует в машкод с оптимизациями, навроде того что есть в jvm и clr)

В обычном питоне тоже. .py файлы компилятся в .pyc и иже с ними, и уже это дело интерпретируется.

[Alkarian]

Ничего не оффтоп. Нам тут пытаются доказать, что пифа хуже потому, что питон плохой.

питон - хороший. а вот пифа тормозит. а еще ефт удобнее субъективно