powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Программирование [игнор отключен] [закрыт для гостей] / Жирные программы - факторы скорости
25 сообщений из 92, страница 2 из 4
Жирные программы - факторы скорости
    #39440872
Фотография S.G.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
сначала спрашивают "как мне бросить Дельфи", потом после успешного бросания начинается "а как мне проапгрейдить комп, чтобы на новом языке компилилось бьстрее".
...
Рейтинг: 0 / 0
Жирные программы - факторы скорости
    #39440897
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SiemarglИ программы получатся компактнее и быстрее.

Что значит «компактнее и быстрее»? Вот есть задача, вот есть требования, если задача выполнена и требования соблюдены, о чём вообще речь?

Нет такого требования «компактнее и быстрее».
Компактнее, чем что?
Быстрее, чем кто?
Насколько быстрее?
Насколько компактнее?

Лозунги из разряда «мы хотим более лучше одеваться».

SiemarglА удовольствие от качественно и красиво выполненной работы - не критерий?

Какая корреляция качественной и красиво выполненной работы с компактностью и скоростью? Я всегда стараюсь пользоваться существующими фреймворками и библиотеками, вместо того, чтобы писать всё с нуля. И обычно они практически всегда содержат больше функционала, чем мне сейчас надо.

Что теперь? Где тот волшебник, который генерирует библиотеки сразу с тем и только тем функционалом, который лично мне сейчас нужен? Или что? С нуля всё писать?

Замечательная перспектива
...
Рейтинг: 0 / 0
Жирные программы - факторы скорости
    #39440909
dbpatch
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dima TИ еще не рассмотрен такой аспект как трудоемкость разработки. Например на чистом Си надо написать 100500 букав , а то же самое на С++ или C# потребует намного меньше кода, как следствие меньше отладки и ошибок, т.е. быстрее разработка с тем же качеством результата.

Ты хоть одну программу написал на чистом C?

Для тебя наверное будет секретом, что там в Linux/FreeBSD огромное количество библиотек, по фукнционалу - вполне себе сопоставимых и с C++ и даже с C# и Delphi?

GUI - GTK+
XML - expat, faxpp
Web - curl, apache
DB - UnixODBC, OCILIB, ... тысячи их

списки библиотек можно продолжить до бесконечности, велосипеды писать - не нужно
...
Рейтинг: 0 / 0
Жирные программы - факторы скорости
    #39440921
dbpatch
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttSiemarglИ программы получатся компактнее и быстрее.

Что значит «компактнее и быстрее»? Вот есть задача, вот есть требования, если задача выполнена и требования соблюдены, о чём вообще речь?

Нет такого требования «компактнее и быстрее».
Компактнее, чем что?
Быстрее, чем кто?
Насколько быстрее?
Насколько компактнее?


Если написать простейший web сервер приложений, который будет выдавать hello world, на "современном" стеке - PHP, JSP, ASP.NET, и такой-же на "чистом" C, то количество ответов в секунду может отличаться на два порядка и даже больше (т.е. более, чем в 100 раз).

Если копнуть дальше, пойти в базы данных - то можно и до трех порядков добраться.


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


Весь гугл обрабатывает всего лишь 59к запросов поиска в секунду, никому реально не нужны сотни тысяч rps.
...
Рейтинг: 0 / 0
Жирные программы - факторы скорости
    #39440924
Dima T
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dbpatchDima TИ еще не рассмотрен такой аспект как трудоемкость разработки. Например на чистом Си надо написать 100500 букав , а то же самое на С++ или C# потребует намного меньше кода, как следствие меньше отладки и ошибок, т.е. быстрее разработка с тем же качеством результата.

Ты хоть одну программу написал на чистом C?

Для тебя наверное будет секретом, что там в Linux/FreeBSD огромное количество библиотек, по фукнционалу - вполне себе сопоставимых и с C++ и даже с C# и Delphi?

GUI - GTK+
XML - expat, faxpp
Web - curl, apache
DB - UnixODBC, OCILIB, ... тысячи их

списки библиотек можно продолжить до бесконечности, велосипеды писать - не нужно
Написал и потом долго и упорно мучался пересадкой с виндовс-велосипеда на линукс-велосипед.
В С++11 немного порешали проблемы, добавили хотя бы связанное с многопоточностью.
А на том же C# просто копируешь EXE из виндовса в линукс даже без перекомпиляции и он запускается и работает.
...
Рейтинг: 0 / 0
Жирные программы - факторы скорости
    #39440941
Dima T
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dbpatchсписки библиотек можно продолжить до бесконечности, велосипеды писать - не нужно
Собственно это и есть тот "жир", про который Siemargl пишет 20412898
...
Рейтинг: 0 / 0
Жирные программы - факторы скорости
    #39440944
schi
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
"Успех системы MULTICS был весьма неоднозначен. Эта система разрабатывалась
для того, чтобы обеспечить сотни пользователей машиной, немногим более
мощной, чем персональный компьютер с процессором Intel 386, хотя при этом имеющей
возможность работы со значительно большим количеством устройств ввода-вывода.
Это было не так уж безумно, как может показаться, потому что в те дни люди
знали, как создавать маленькие, эффективные программы -- навык, который впоследствии был утерян."

Эндрю Таненбаум, "Современные операционные системы"
...
Рейтинг: 0 / 0
Жирные программы - факторы скорости
    #39440948
dbpatch
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dima Tdbpatchсписки библиотек можно продолжить до бесконечности, велосипеды писать - не нужно
Собственно это и есть тот "жир", про который Siemargl пишет 20412898

я не знаю, про что он там пишет.

по факту как раз в библиотеках C все относительно хорошо, отцы основатели были не дураки и довольно все четко огранизовали, в т.ч. решив грамотно вопрос подкачки кешей (юзается из разделяемых библиотек только то, что реально нужно, функции как правило плотно сидят в своих плотно расположенных блоках кода).

а вот в мире ООП это, мягко говоря, не так, даже прыжки по виртуальным функциям в две три строки кода приводят к промахам в кеш процессора, а возведенная в абсолют копипаста темплейтов на C++ - приводит к разбуханию кода и опять-же - вымыванию кеша процессора.

плюс вопрос разделяемых библиотек на C++ практически не решен в виду отсуствия стандартов по ABI - и кодер вынужден статически линковать чужой код себе в бинарик, без всяких там .so/.dll

вот последнее и есть жир.

а разделяемые библиотеки это как раз благо, если их, конечно, правильно огранизовывать (ужас WinSxS мы не берем в расчет)
...
Рейтинг: 0 / 0
Жирные программы - факторы скорости
    #39440949
dbpatch
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dima Tdbpatchпропущено...


Ты хоть одну программу написал на чистом C?

Для тебя наверное будет секретом, что там в Linux/FreeBSD огромное количество библиотек, по фукнционалу - вполне себе сопоставимых и с C++ и даже с C# и Delphi?

GUI - GTK+
XML - expat, faxpp
Web - curl, apache
DB - UnixODBC, OCILIB, ... тысячи их

списки библиотек можно продолжить до бесконечности, велосипеды писать - не нужно
Написал и потом долго и упорно мучался пересадкой с виндовс-велосипеда на линукс-велосипед.
В С++11 немного порешали проблемы, добавили хотя бы связанное с многопоточностью.
А на том же C# просто копируешь EXE из виндовса в линукс даже без перекомпиляции и он запускается и работает.

писать на чистом С под Windows? ой да ладно заливать-то

или ты не понимаешь разницы между C и C++?
...
Рейтинг: 0 / 0
Жирные программы - факторы скорости
    #39440950
Dima T
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVostt14Мб тянет, и что? Что тут такого? Я не вижу никакого криминала. Если была бы задача, сделать маленькую утилиту, например, для запуска на мобилках, или на микро-компьютерах, то она бы и решалась. Если нет такой задачи, а есть другая -- посчитать бенчи, и под рукой есть питонбенч, да плевать на эти 14 Мб.
14Мб не криминал, но есть виртуалки и там место на диске не резиновое и стоит вполне ощутимые 15 р/мес за 1 Гб.
Например начал .Net core ставить в Debian и место на диске кончилось. 1+ Gb потребовалось, а у меня там всего 8 Гб.
...
Рейтинг: 0 / 0
Жирные программы - факторы скорости
    #39440967
Dima T
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dbpatchписать на чистом С под Windows? ой да ладно заливать-то

или ты не понимаешь разницы между C и C++?
Разницу понимаю. На С писал DLL. Потом STD освоил, на C++ перебрался, точнее на С с классами и STD. До С++11 был большой гимор с многопоточностью. Например как переписать Event в линукс?
...
Рейтинг: 0 / 0
Жирные программы - факторы скорости
    #39440987
dbpatch
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dima Tdbpatchписать на чистом С под Windows? ой да ладно заливать-то

или ты не понимаешь разницы между C и C++?
Разницу понимаю. На С писал DLL. Потом STD освоил, на C++ перебрался, точнее на С с классами и STD. До С++11 был большой гимор с многопоточностью. Например как переписать Event в линукс?

ок, как я и предполагал - у тебя каша в голове, и нет понимания разницы между Pure ANSI C (C89/C99/C11) и C++.

С с классами это вообще жесть.

в принципе, для человека, который сидит на MSVC и только - это нормально, ибо там ничего кроме С++, по сути, и нет (clang/c2 в расчет не берем, а про навсегда заброшенный C компилятор даже заикаться странно).
...
Рейтинг: 0 / 0
Жирные программы - факторы скорости
    #39440992
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dbpatchЕсли написать простейший web сервер приложений, который будет выдавать hello world, на "современном" стеке - PHP, JSP, ASP.NET, и такой-же на "чистом" C, то количество ответов в секунду может отличаться на два порядка и даже больше (т.е. более, чем в 100 раз).

Если копнуть дальше, пойти в базы данных - то можно и до трех порядков добраться.

На два порядка? Seriously? А чего так мало? Для убедительности можно и больше порядков добавить, например, 100 порядков, не надо мелочиться.

Конечно, насчёт порядков, это бред.

dbpatchЕсли копнуть дальше, пойти в базы данных - то можно и до трех порядков добраться.

Обычно, оптимизируются критические места, и если надо пишутся на Си. Обычно, большое приложение, полностью написанное на Си, нифига не быстрее, а даже медленнее. И ошибок в нём больше на порядки, и по безопасности проблемы. А уж про банальное сопровождение говорить не приходится. Безумно дорого. Несравнимо с парой мнимых процентов потенциального повышения производительности.


dbpatchПросто это никого не парит - современные веб серверы отрабатывают до двух запросов в секунду, типо норма , клиент доволен,
если нужно больше - ставят дополнительные ноды в кластер, и все счастливы.

Угу, расскажи это ребятам из StackOverflow, у которых основной стек технологий построен на ASP.NET. Обрабатывает миллионы запросов в минуту со всех точек земли.
...
Рейтинг: 0 / 0
Жирные программы - факторы скорости
    #39440993
Dima T
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dbpatchв принципе, для человека, который сидит на MSVC и только - это нормально, ибо там ничего кроме С++, по сути, и нет (clang/c2 в расчет не берем, а про навсегда заброшенный C компилятор даже заикаться странно).
Мой код не стал С++ от того что я писал в стиле С (структуры и функции), но компилировал С++ компилятором.

Может по мелочи использовал что-то что выходит за рамки Pure ANSI C, но количество букав кода это не убавило, о чем и написал 20411800 . Полностью С++ до сих пор не освоил, поэтому называю "С с классами" то подмножество С++, которое изучил.
...
Рейтинг: 0 / 0
Жирные программы - факторы скорости
    #39440999
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dima T14Мб не криминал, но есть виртуалки и там место на диске не резиновое и стоит вполне ощутимые 15 р/мес за 1 Гб.
Например начал .Net core ставить в Debian и место на диске кончилось. 1+ Gb потребовалось, а у меня там всего 8 Гб.

Рантайм нет коры на дебиан весит 30 мб в архиве. Я не понимать про какие гб ты говоришь. Ребята на моих глазах его на Rasperry Pie поднимали и запускали веб-сайт под управлением asp.net core mvc.
...
Рейтинг: 0 / 0
Жирные программы - факторы скорости
    #39441001
Roman Mejtes
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVostt,

на счет оптимизации, вот у меня сейчас под рукой 2 проекта (проекты делал не я и даже не та контора в которой я сейчас работаю).
Но требования заказчика именно performance, так как программы люто тормозят.
=) так что тут больше от заказчика зависит, чем от начальника :)
...
Рейтинг: 0 / 0
Жирные программы - факторы скорости
    #39441003
Dima T
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttDima T14Мб не криминал, но есть виртуалки и там место на диске не резиновое и стоит вполне ощутимые 15 р/мес за 1 Гб.
Например начал .Net core ставить в Debian и место на диске кончилось. 1+ Gb потребовалось, а у меня там всего 8 Гб.

Рантайм нет коры на дебиан весит 30 мб в архиве. Я не понимать про какие гб ты говоришь. Ребята на моих глазах его на Rasperry Pie поднимали и запускали веб-сайт под управлением asp.net core mvc.
Я рантайма не нашел, SDK ставил.
...
Рейтинг: 0 / 0
Жирные программы - факторы скорости
    #39441004
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Roman Mejtes,

Я согласен. Но если бы мне какой-нибудь «профессионал» ляпнул на вопрос «почему так тормозит», что это типа потому что проект на C# или Java или <выбрать по вкусу>, я бы сильно засомневался в его адекватности.

Бывают затыки, их надо искать и устранять. И это надо делать независимо от выбранных технологий, вероисповедания, цвета кожи, любимого цвета и фазы луны. Отмазки не годятся. Ты либо способен на это, либо нет.
...
Рейтинг: 0 / 0
Жирные программы - факторы скорости
    #39441005
Фотография hVostt
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dima T,

Ну вот и ответ. SDK жирный, это понятно.

https://www.microsoft.com/net/download/linux
...
Рейтинг: 0 / 0
Жирные программы - факторы скорости
    #39441016
Dima T
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttDima T,

Ну вот и ответ. SDK жирный, это понятно.

https://www.microsoft.com/net/download/linux
Спасибо. Поразбираюсь как поставить рантайм. Там по ссылке Instructions уводит на установку SDK.
...
Рейтинг: 0 / 0
Жирные программы - факторы скорости
    #39441043
dbpatch
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hVosttdbpatchЕсли написать простейший web сервер приложений, который будет выдавать hello world, на "современном" стеке - PHP, JSP, ASP.NET, и такой-же на "чистом" C, то количество ответов в секунду может отличаться на два порядка и даже больше (т.е. более, чем в 100 раз).

Если копнуть дальше, пойти в базы данных - то можно и до трех порядков добраться.

На два порядка? Seriously? А чего так мало? Для убедительности можно и больше порядков добавить, например, 100 порядков, не надо мелочиться.

Конечно, насчёт порядков, это бред.
и в чем бред? там 800к rps vs 6к., два порядка - это 10 на 10? 100 раз

или ты не знаешь, что такое порядок? ну да, тогда для тебя все это бред, согласен

hVosttdbpatchЕсли копнуть дальше, пойти в базы данных - то можно и до трех порядков добраться.

Обычно, оптимизируются критические места, и если надо пишутся на Си. Обычно, большое приложение, полностью написанное на Си, нифига не быстрее, а даже медленнее. И ошибок в нём больше на порядки, и по безопасности проблемы. А уж про банальное сопровождение говорить не приходится. Безумно дорого. Несравнимо с парой мнимых процентов потенциального повышения производительности.
1) И ты всерьез считаешь, что тут никто не знает про эту истину, которую ...
2) Откуда трава, что медленнее? Вчера во сне увидел?
3) Про безумно дорого - опять какие-то фантазии ...
Модератор: Просьба не переходить на личности

hVosttdbpatchПросто это никого не парит - современные веб серверы отрабатывают до двух запросов в секунду, типо норма , клиент доволен,
если нужно больше - ставят дополнительные ноды в кластер, и все счастливы.

Угу, расскажи это ребятам из StackOverflow, у которых основной стек технологий построен на ASP.NET. Обрабатывает миллионы запросов в минуту со всех точек земли.

а) сколько нод стоит на StackOverflow
б) про миллионы в минуту - откуда трава?
...
Рейтинг: 0 / 0
Жирные программы - факторы скорости
    #39441051
Dima T
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dbpatchВесь гугл обрабатывает всего лишь 59к запросов поиска в секунду , никому реально не нужны сотни тысяч rps.
59 000 * 60 = 3 540 000
hVosttУгу, расскажи это ребятам из StackOverflow, у которых основной стек технологий построен на ASP.NET. Обрабатывает миллионы запросов в минуту со всех точек земли.
Прежде чем спорить цифры к общему знаменателю приводите. Порядок один и тот же, миллионы в минуту.
...
Рейтинг: 0 / 0
Жирные программы - факторы скорости
    #39441060
dbpatch
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dima TdbpatchВесь гугл обрабатывает всего лишь 59к запросов поиска в секунду , никому реально не нужны сотни тысяч rps.
59 000 * 60 = 3 540 000
hVosttУгу, расскажи это ребятам из StackOverflow, у которых основной стек технологий построен на ASP.NET. Обрабатывает миллионы запросов в минуту со всех точек земли.
Прежде чем спорить цифры к общему знаменателю приводите. Порядок один и тот же, миллионы в минуту.

1) гугл это не stackoverflow, это раз, ибо
2) соотношение обычных людей к программистам - это примерно 100 к 1, не более
3) гугл для своих 59к rps держит сотни тысяч нод - спрашивается, зачем, если якобы один сервак на ASP.NET сдюжит больше?

при этом 1 секунды в гугле дают ответ про реальные цифры

https://nickcraver.com/blog/2016/02/17/stack-overflow-the-architecture-2016-edition/

209,420,973 (+61,336,090) HTTP requests to our load balancer per day

делим 209м на 86400 - получаем несчастные 2423 rps, 145к в минуту, где миллионы?

и это обрабатывает 11 IIS серверов, т.е. каждый из них до может 200 rps, реально меньше, потому что всю статику обрабатывает не IIS

66,294,789 (+30,199,477) of those were page loads

т.е. реально IIS может примерно 60 rps - что вполне приближается к пиковой возможности типового ASP.NET/MSSQL стека
...
Рейтинг: 0 / 0
Жирные программы - факторы скорости
    #39441070
Dima T
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dbpatchделим 209м на 86400 - получаем несчастные 2423 rps, 145к в минуту, где миллионы?
Некорректно на 86400 делить, так ты предполагаешь что круглосуточно запросы идут равномерным потоком. Думаю пиковые нагрузки в 3-4 раза выше среднего и заложен резерв мощности на их обслуживание, т.е. 435-580к в минуту. Не гугл с миллионами, но и не на порядок, а в 6-8 раз.
...
Рейтинг: 0 / 0
Жирные программы - факторы скорости
    #39441090
Dima T
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dbpatch3) гугл для своих 59к rps держит сотни тысяч нод - спрашивается, зачем, если якобы один сервак на ASP.NET сдюжит больше?
Задачи несравнимые: StackOverflow это форум, запросы конкретных ссылок это и есть вся его основная нагрузка, а гуглу чтобы ответы на запросы давать надо еще весь инет качать постоянно, хранить как-то и индексировать для быстрого поиска. И на поиске гугл не заканчивается. Есть ютуб и т.д.
...
Рейтинг: 0 / 0
25 сообщений из 92, страница 2 из 4
Форумы / Программирование [игнор отключен] [закрыт для гостей] / Жирные программы - факторы скорости
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]