PHP vs. C/C++

mr.GOD писал:

1.Да ты прав,зачем тебе указатели ? это гимор ,в яве это дает возможность сосредоточится самой структуре классов, а не искать указатели указвающие в некуда , и дырки в памяти которые возможно может оставить твоя программа. 2.Да, согласен , но ты нечего не теряешь , просто реализовано иначе . 3.Сервлетная технология дает курить cgi без проблем . 4.Там система автоматической сборки мусора , фактически нет смысла им делать упор на деструкторы когда работа с указателями напрямую отсутствует. 5.Возможно, не спорю. 6.Сам не профессионал по яве , но занялся изучением этой темы ,поэтому о размерах кода спорить не буду , но это и не существенно в данном случае. сейчас JSP , JDBC , Java Servlet дают тебе все чтобы програмировать для веб-все это дает огромную производительносить и безопасность намного облегчая наш нелегкий труд , в отличии от си .

1. это не проблема языка, заметь ничто не мешает мне состредоточиться на структуре в C++
2. теряю, если хочу наследовать не только интерфейс, но и реализацию.
3. как сервлеты связаны с garbage collection ?
4. в деструкторах можно работать не только с указателями

похоже разговор ушел от темы и его надо переносить в приваты

lega_cobra писал:

Спасибо за совет. Но замечу, что asm - это специализированный язык для програмиррования процессоров. Как и php - специализированный язык для веба. А вот язык C - это язык общего назначения, и как следсвие, он хорошо подходит как для написания операционок, так и для приложений, включая web.

Кто-то блещет на всю борду пробелами в знаниях :-)
1) asm - это низкоуровневый язык программирования. Процессоры на нем не программируют.
2) язык для программирования процессоров называется microcode
3) C - не язык общего назначения. С разрабатывался изначально для написания UNIX, и более ни для чего.
4) C назвали так, потому, что это первый слог от слова system.
5) Basic кстати и паскаль тоже универсальные языки.

Xrenoder писал:

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

а почему ты решил, что если написать программу на пхп, то вероятность полного пересмотра структуры исчезает? это опять же не проблема C++, а проблема кривых рук.

Xrenoder писал:

Далее, есть такой фактор, как надежность. Ты можешь написать замечательную программу, которая будет работать быстрее и лучше, чем связка apache+php+daemon, но это будет в 99% случаев непрофессионально, поскольку количество багов в этой программе будет на порядок (как минимум) выше, чем в упомянутой связке. Просто по причине сложности программы.

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

Xrenoder писал:

Когда на чем - определяется задачами.

ключевая фраза, это должен был бы быть единственный ответ в топике имхо

Последний раз редактировалось: AnToXa (14/04/04 в 00:32), всего редактировалось 1 раз

rst писал:

3) C - не язык общего назначения. С разрабатывался изначально для написания UNIX, и более ни для чего. 5) Basic кстати и паскаль тоже универсальные языки.

3. общего общего, а какого же еще тогда? стандарт, насколько я помню, именно это и утверждает.
5. замечательно.

AnToXa писал:

3. общего общего, а какого же еще тогда? стандарт, насколько я помню, именно это и утверждает. 5. замечательно.

Это была подъебка.
Любой язык может позиционироваться как язык общего назначения.
Мои орлы GUI на чистом ассемблере пишут под винду.

AnToXa писал:

1. это не проблема языка, заметь ничто не мешает мне состредоточиться на структуре в C++ 2. теряю, если хочу наследовать не только интерфейс, но и реализацию. 3. как сервлеты связаны с garbage collection ? 4. в деструкторах можно работать не только с указателями похоже разговор ушел от темы и его надо переносить в приваты

1.Да это не проблема , но в вебе , это не кому не нужный гимор (мы про веб сейчас )
2.Согласен , но по большому счету не принципиально.
3.Я скажем так привел пример и сравнил производительность , и она выше при любом расскладе чем у cgi (мы про веб напоминаю ).
4.Я в курсе , но мы сейчас не о том что лучше Java или С , а о том что лучше для програмирования в веб .

P.S.
Ладно рассходимся а то и вправду от темы отошли , не отвечай мне

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

Xrenoder писал:

Блин. Да, на PHP можно писать не правильно. Более того, на С тоже можно писать неправильно. И на asm тоже можно писать неправильно. И на русском тоже.

Естественно можно писать на всем не правильно. С моей стороны это было скорее замечание, нежели аргумент. Одна из основных проблем студентов, изучающих C - программа не собирается. Но никто не мешает запустить глючный PHP скрип, который поставит сервер раком. В любом случае, это не довод с моей стороны, а лишь небольшое замечание.

Цитата:

Но - на PHP ведь можно писать и правильно.

Как заметил один начинающий программист сегодня в моем оффисе - "Правильно написанный скрип на PHP по сложности кода становиться не легче того-же C. А в больших проектах может быть даже сложнее и запутанее". Я не стал с ним спорить. Задание, которое я ему дал, подразумевало свободный выбор средств с его стороны. И он, действительно фанат PHP, в конце концов потратил две недели дополнительно, но переписал его на C.

Так-что заметим базис один - "Если пишешь правильно, то в этом случае PHP становиться вовсе не проще, или, я бы сказал, тот же c/c++ не сложнее".

Цитата:

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

Да. 100% поддерживаю. Именно поэтому я не принимаю аргумент, в стиле "на PHP писать легче"

Цитата:

Правильное программирование, если Вы не в курсе, это не только правильное использование средств программирования и хранения данных, но и правильный их выбор. И если конкретное веб-приложение на PHP будет работать быстрее, чем аналогичное приложение на С/С++ (cgi) то выбор С/С++ будет свидетельством непрофессионализма.

В данном случае аргумент не только "быстрее/медленнее".

Цитата:

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

Если апдейт программы, независимо от того, на чем она написана, потребует пересмотрения структуры, то это опять-таки не говорит ничего о выборе средств програмиррования. Это говорит только о "танцоре". Не так ли?

Цитата:

Далее, есть такой фактор, как надежность. Ты можешь написать замечательную программу, которая будет работать быстрее и лучше, чем связка apache+php+daemon, но это будет в 99% случаев непрофессионально, поскольку количество багов в этой программе будет на порядок (как минимум) выше, чем в упомянутой связке. Просто по причине сложности программы.

Тут я бы промолчал. Для простых проектов это не верно с моей точки зрения. Для сложных - это не верно вдвойне. Но это мое мнение.

Цитата:

Единственный случай, когда это оправдано - если новый продукт на порядок повышает функциональность системы и такое повышение действительно является критичным.

А отсутствие старого продукта - это не причина?

Цитата:

А вот эти Ваши ехидные ухмылочки типа "PHP для тупиц" - не более чем дискуссионный прием, работа на публику.

Это действительно риторический прием. Когда мой подчиненый не может нарезать канал по достаточно простым правилам, я тогда упоминаю книгу "CISCO за 30 секунд для конченных идиотов" Обычно это стимулирует переход к конструктивизму. Ибо обижаются только дураки

Цитата:

Если Вы не умеете использовать PHP и не знаете других его достоинств, кроме терпимости к косоручию программера - это факт Вашей личной биографии, не имеющий собственно к PHP никакого отношения.

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

Цитата:

Если Вы не знаете, почему в некоторых случаях С++ использовать рациональнее чем С - см выше.

Обижаться не стоит на мои язвительные заявления. Но согласитесь, что базовая объектная модель несет в себе кое-какие накладные расходы. Поэтому я таким "скандальным" образом заметил, что давайте различать C и C++ с точки зрения ресурсных затрат. Заметьте, тут ничего нет ни о задачах, которые решает конечный продукт, ни о работе самого программиста. Только о конечном продукте с точки зрения ресурсных затрат.

Цитата:

Кстати, чтобы отмежеваться от Holy War, скажу, что я сам пишу в основном на С (и для web тоже иногда), совсем изредка на С++, и на PHP пишу тоже. Когда на чем - определяется задачами. Я достаточно ясно аргументировал свою точку зрения?

Кстати, что бы отвлечся от ее же замечу, что C не входит в список моих личных предпочтений, хотя писать приходится на нем очень много. Кстати, PHP тоже не входит, хотя и с ним приходится иметь дело не меньше. Работаю я ведь не только на себя, но и на заказчиков. А там всякое бывает.

А теперь в двух словах о моей позиции в данном диспуте, так сказать, людскими словами.

1. Работа програмиста, как такового. Как мы выяснили, профессионал выбирает инструмент (в рамках своих возможностей) исходя из задач и оптимальности их решения. В любом случае, для програмиста не бывает "легче" или "труднее" работать на том или ином приложении, ибо тогда он не професионал. Так-что выбор инструмента давайте переложим все же на требования конечного продукта, а не на дилетанство програмиста.

2. А теперь о приложениях. Мы говорим о web-приложениях. В таком случае, разумеется, речь никак не идет о домашней страничке, в стиле "это я, а это моя собака" с 5 униками в день на домашнем сервере. Речь идет о эффективности серъезного сервера с довольно-таки серъезной нагрузкой при обслуживании массы клиентов. Таким образом главное требование - производительность системы.

Как правило, на веб-серверах используется всеми любимый (и ненавидимый одновременно) Apache сервер. Самый существенный фактор его производительности - размер занимаемой памяти. Как только апач вылазит в своп - ему хана (точнее не ему, а его производительности). Попутно замечу, что размер программы имеет тоже какое-то определенное, хотя и не критичное, значение.

Давайте рассмотрим, из чего состоит апач, работающий на системе (честно говорю - пишу примерно по памяти). Бинарный образ core - где-то 300 кил. Все стандартные модули, исключая libphp - еще 500 кил. И собственно сам mod_php - более 2.5 метров - это в 12 раз больше следующего по размеру модуля - mod_ssl и в 8 раз больше самого апача. Это в 5 раз больше всех модулей вместе взятых. Один этот модуль php почти в два раза больше mmysqld. А апач плодится в памяти и тащит за собой контекст для каждого потомка (а его размер с php может достигать до 3-4 метров). Почему-то напрашивается вывод, что если избавиться от этого модуля, который позволяет начинающему програмисту написать "Hello чуваки" на пару строк меньше, то мы можем выиграть существенный прирост производительности, к тому же в рамках той-же памяти, иметь большее количество потомков самой апачи при существеннов возрастании эффективности каждого потомка в отдельности. А это не столько вопрос денег на озушки, сколько опять-таки вопрос производительности.

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

Давайте попробуем проанализировать. Самым оптимальным вариантом является бинарный образ (например, программа написанная на C и откомпиленная без лишних ненужных либ, например libc only). Вариант достаточно неплохой. Что может насторожить? Например, что программу надо каждый раз загружать с диска. Но при достаточно заметной нагрузке она давно лежит в дисковом кеше. Так-что это не проблема. Следующее - fork. Это может быть проблемой. Причем проблемой не потому, почему многие думают. Создание контекста процесса - операция достаточно быстрая (создание контекста нити интерпретатора php - вещь намного затратнее, тем более, что в отличие от forka, длается не на том уровне привилегий системной памяти). Проблема в том, что fork пытается заместить скриптом копию одной из апачи - и так огромного мультиниточного монстра. Но для этого умные люди придумали специальную маленьку форкалку в виде cgid, которая существенно увеличивает эффективность работы сервера, освобождая сам апач от выполнения этих противных форков.

Так-что с моей точки зрения, выбор PHP или C лежит вовсе не в разрезе комфортности одного конкретного програмиста. Отказ от PHP (и от его модуля) в рамках коммерческого проекта позволяет существенно улучшить качество обслуживания клиента. При этом не так уж и сильно усложняет работу действительного профессионала.

Если речь идет о како-либо простой примочке, типа, "а это моя кошечка", то в этом случае вообще вести какую-либо дискусию бесмысленно - тут уж лучше выбирать лучшие фотки своей кошечки, нежели задумываться о путях повышения эффективности работы сервера. (Перевожу - если ставишь cj на хосте спонсора - не стоит задумываться вообще о том, на чем он написан).

Я объяснил свою точку зрения?

Кароче, Склехфасовский
mod_php стоял и будет стоять на серваках еще достаточно долго. в подавляющем большинстве случаев от него наврят-ли будут отказываться.

Типичный пример - дедик. На нем 50 доменов. Нормальная ситуация. Думаешь для 50 доменов не найдется хотя бы 10, чтобы ПХП не юзали? Дедики чисто для галерок я не считаю - там ядреный/ядерный (модуль ядра короче) апач поставить, он только html понимает.

Дедик для одного проекта - скорей исключение.
Так что отказаться от mod_php и перевести все на ЦГИ - это очень большое исключение для очень серхезных проектов.

Про виртуалы без mod_php я молчу.

rst писал:

Кто-то блещет на всю борду пробелами в знаниях :-)

Хехе...

Цитата:

1) asm - это низкоуровневый язык программирования. Процессоры на нем не программируют.

Напомни-ка мне какой-нибудь машиннонезависимый asm, а то я за 20 с лишним лет позабыл о существовании таковых. Кстати, а не на процессорных-ли кодах базируется asm? Фраза не совсем удачная, согласен. Звучит убого.

Цитата:

2) язык для программирования процессоров называется microcode

Немножко другая вещь, не так ли? ("И тема диссертации интересная... Что-то там в носу...")

Цитата:

3) C - не язык общего назначения. С разрабатывался изначально для написания UNIX, и более ни для чего.

Многие языки изначально разрабатывались для каких-либо целей. Паскаль вон вообще придуман Виртом, как учебная безделушка... А гляди, как расперло. Ктому-же С писался Ричем и этим (блин, позабыл, Томпсоном? или Томпсон позже был? - блин, вот память короткая) изначально для поддержания игрухи.

Цитата:

4) C назвали так, потому, что это первый слог от слова system.

Что-то мне подсказывает, он назвается C, потому-что предыдущий язык B (би) не позволял в игрухе запоминать рекорды разных игроков. Так-что пороки, как известно, двигающие прогресс, и тут оказались виноватыми. Что же еще делать на PDP-11, если не "Посадкой на марс" играть целыми днями?

Цитата:

5) Basic кстати и паскаль тоже универсальные языки.

Лет 7 назад у меня было много cgi-шников, написанных на FPK. Так. из прикола. Дабы еще в то время продемонстрировать своим коллегам, как правильно определить критерии выбора языка. И что критерии находятся не в плоскости "так все делают", или "так проще". Вопрос был, кстати, практически аналогичный этому. Слинкованные с libc4, они до сих пор работают где-то в Австралии, регулярно принося мне мелочь на сигареты и кофе

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

Моя позиция в ответ на "что лучше?" - все хорошо. Зависит от задачи, исполнителя, заказчика и погоды на серверном полюсе. Но ПХП более распространен и писать на нем профессиональный код для вэб-приложений гораздо удобнее и быстрее. Дебаговая стадия она есть везде. И баги есть везде. ПХП конечно менее багоусойчив чем си, хотя х/з. Та же ситуация, когда ты записываешь значение в несуществующий элемент массива или за его пределы. Наэто си по моему не ругается . А последствия гораздо круче, чем бага в ПХП.

Pentarh писал:

Кароче, Склехфасовский mod_php стоял и будет стоять на серваках еще достаточно долго. в подавляющем большинстве случаев от него наврят-ли будут отказываться.

Вообще-то, кому как придется. Но при этом помним, кто платит, тот и заказывает музыку.

Цитата:

Типичный пример - дедик. На нем 50 доменов. Нормальная ситуация. Думаешь для 50 доменов не найдется хотя бы 10, чтобы ПХП не юзали?

Как там Варум поет - "все в твоих руках". Смотря, чьи это домены. Мне потребовалось больше года, что бы заказчику доказать, что 90% использования PHP на его доменах - излишне, и что он получит выигрыш, отказавшись от PHP (из 6 дедиков после удаления PHP, осталось только 2, загруженных меньше, чем на половину). Для сайтов, которые без PHP не обойдутся, был выделен один из освободившихся серверов.

Цитата:

Дедики чисто для галерок я не считаю - там ядреный/ядерный (модуль ядра короче) апач поставить, он только html понимает.

Если ты khttpd имеешь в виду, то самое оно для выдачи статики.

Цитата:

Дедик для одного проекта - скорей исключение. Так что отказаться от mod_php и перевести все на ЦГИ - это очень большое исключение для очень серхезных проектов.

Как правило, если даже на дедике много проектов, ими рулит одна команда. А найти стиль разработки для одной команды с учетом оптимизации не сложно. Как я сказал - выкинуть все затратное с php в отдельный корпус - хороший компромис.

Цитата:

Про виртуалы без mod_php я молчу.

Про вариант - "Это моя теща, а это мой велосипед" - мы вроде не говорим. Там вообще до "попы" на чем я буду делать - не моя забота.

Цитата:

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

на 100 % согласен , "помешательство" на Си (Си++) это не выход
когда можно применить пхп и нечего не потерять.По мойму тот же сидж на пхп не хуже работает, чем на cgi.Все живет, все работает , примеры в сети . И что-то я пока не слышал ищу сидж на Си , нах этот пхп .

Цитата:

Та же ситуация, когда ты записываешь значение в несуществующий элемент массива или за его пределы. Наэто си по моему не ругается . А последствия гораздо круче, чем бага в ПХП.

Не совсем согласен не нужно мне кажется вообще сравнивать архитектурные принципы С++ и ПХП .

Pentarh писал:

Моя позиция в ответ на "что лучше?" - все хорошо. Зависит от задачи, исполнителя, заказчика и погоды на серверном полюсе. Но ПХП более распространен и писать на нем профессиональный код для вэб-приложений гораздо удобнее и быстрее. Дебаговая стадия она есть везде. И баги есть везде. ПХП конечно менее багоусойчив чем си, хотя х/з. Та же ситуация, когда ты записываешь значение в несуществующий элемент массива или за его пределы. Наэто си по моему не ругается . А последствия гораздо круче, чем бага в ПХП.

На memory fault апач реагирует нормально, выдает ошибку из пятисотых. Отлаживается ЦГИ точно так-же, как и любая другая программа. Для этого даже вебсервер не нужен. Есть мнение, что програмирование на C делает програмиста более внимательным, хотя для меня это не очевидно.

lega_cobra писал:

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

Давайте! Ты наконец-то сделал бенчмарки?

Цитата:

Одна из основных проблем студентов, изучающих C - программа не собирается. Но никто не мешает запустить глючный PHP скрип, который поставит сервер раком.

Ну-ну.. раком сервера становятся обычно из-за логических ошибок при проектировании, реализация тут дело десятое.

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

Цитата:

Как заметил один начинающий программист сегодня в моем оффисе - "Правильно написанный скрип на PHP по сложности кода становиться не легче того-же C. А в больших проектах может быть даже сложнее и запутанее". Я не стал с ним спорить. Задание, которое я ему дал, подразумевало свободный выбор средств с его стороны. И он, действительно фанат PHP, в конце концов потратил две недели дополнительно, но переписал его на C.

Значит эту задачу правильнее (эффективнее) решать с помощью С. Была бы другая задача - возможно были бы к месту другие языки.

Цитата:

Так-что заметим базис один - "Если пишешь правильно, то в этом случае PHP становиться вовсе не проще, или, я бы сказал, тот же c/c++ не сложнее".

Кривая логика.

Цитата:

1. Работа програмиста, как такового. Как мы выяснили, профессионал выбирает инструмент (в рамках своих возможностей) исходя из задач и оптимальности их решения. В любом случае, для програмиста не бывает "легче" или "труднее" работать на том или ином приложении, ибо тогда он не професионал. Так-что выбор инструмента давайте переложим все же на требования конечного продукта, а не на дилетанство програмиста.

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

Цитата:

2. А теперь о приложениях. Мы говорим о web-приложениях. В таком случае, разумеется, речь никак не идет о домашней страничке, в стиле "это я, а это моя собака" с 5 униками в день на домашнем сервере. Речь идет о эффективности серъезного сервера с довольно-таки серъезной нагрузкой при обслуживании массы клиентов. Таким образом главное требование - производительность системы.

Не надо съезжать в сторону монстроидального софта. Мы говорим о вэб-скриптах. Типичный пример задачи средней сложности под обычный трафф - CJ скрипт. Если упорно хочешь узнать истинное положение вещей - сделай бенчмарки AvroraCJ как типичного представителя PHP+mySQL скриптов и UCJ/FET как типичного представителя C CGI, на обычном хостерском апаче. Премущество по скорости и ресурсоемкости отнюдь не на стороне С.

NOTE: я знаю про серьезный CJ софт c использованием демонов, написанный целиком на С, более того, я писал ТЗ к одному из них. Когда у человека проходит мегауник в сутки на одном сайте и он предпочитает потратить деньги на заказной софт вместо увеличения парка дедиков, тогда PHP в пролете.

Цитата:

Как правило, на веб-серверах используется всеми любимый (и ненавидимый одновременно) Apache сервер. Самый существенный фактор его производительности - размер занимаемой памяти. Как только апач вылазит в своп - ему хана (точнее не ему, а его производительности). Попутно замечу, что размер программы имеет тоже какое-то определенное, хотя и не критичное, значение. Давайте рассмотрим, из чего состоит апач, работающий на системе (честно говорю - пишу примерно по памяти). Бинарный образ core - где-то 300 кил. Все стандартные модули, исключая libphp - еще 500 кил. И собственно сам mod_php - более 2.5 метров - это в 12 раз больше следующего по размеру модуля - mod_ssl и в 8 раз больше самого апача. Это в 5 раз больше всех модулей вместе взятых. Один этот модуль php почти в два раза больше mmysqld. А апач плодится в памяти и тащит за собой контекст для каждого потомка (а его размер с php может достигать до 3-4 метров). Почему-то напрашивается вывод, что если избавиться от этого модуля, который позволяет начинающему програмисту написать "Hello чуваки" на пару строк меньше, то мы можем выиграть существенный прирост производительности, к тому же в рамках той-же памяти, иметь большее количество потомков самой апачи при существеннов возрастании эффективности каждого потомка в отдельности. А это не столько вопрос денег на озушки, сколько опять-таки вопрос производительности.

Ууууууу.. программер-профи, тебе фраза shared memory о чем-то говорит? Похоже что нет. Вернись на курсы "Системное программирование в юниксах для чайников за 24 часа", а потом сделай бенчмарки. А то мне страшно за благополучие твоих заказчиков и подчиненных, если они реально существуют конечно.

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

Я только скажу из практики.
Программер я еще с 7-го класса школы. rst по языкам может и не переплюнул, но истина где-то там, редко задумываюсь о количестве, главное ведь не "сколько" а "как"

Вэб-программер я уже года четыре и в софт-программеры уже не лезу. Сначала Перл, ПХП + MySQL с годик. Потом ASP+MSSQL с годик (реальное гавно, но пришлось ), плюс всякие нестандарты типа того же Си (на Си из-за того что клиент настаивал - не больше), Miva Empressa, ColdFusion. Потом ASP.NET (C#) с годик, понравилось хочу еще. Параллельно ПХП+MySQL+Postgres. Ну и как в адалт пришел, пока что не встречал таких задач, которые были бы оправданы использованием Си. Пробовал, знаю, гимор. Скрипт один ПХПшный (там еще и мускуль впридачу!) мег трафа в день держал ну и где-то 500 на виртуале. И ниче.

Нафига на Си париться? Дедик стоит. Несколько десятков доменов. Траф неплохо жрет. В основном динамика. Подавляющее большинство скриптов - ПХП+MYSQL. Правильных скриптов . Нормализация БД тоже дает свое. Общая загрузка процессора 15% - максимум что я видел.

Ну где тут Си? В моем конкретном случае (а случай довольно приближен к среднестатистическому) - не нужен тут си.

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

Quantum[Tau] писал:

Ух ты ж блин, где такие чудо-умельцы обитают??! Пусть легко декодируют мне четыре закрытых zend encoder скрипта, штуку баксов от такого счастья отвалю. Бред.

Обратись к администрации phpclub.ru ;)

clever писал:

Обратись к администрации phpclub.ru ;)

Обсуждение хаков, крыков и прочей фигни по моему здесь запрещено. Второй плюс захотел?

rst писал:

4) C назвали так, потому, что это первый слог от слова system.

А вродебы было не так, Томпсон и Ритчи сначала придумали язык A, потом B, затем усовершенствовали и получился C.

clever писал:

Обратись к администрации phpclub.ru ;)

Обязательно, только мелкая проблема заключается в том, что zend encoder делает с исходником фактически то же самое, что компилятор Java (превращает в байткод оптимизируя все что он посчитает нужным) и не сильно отличается от компиляции исходника на С в объектный файл.

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

Quantum[Tau] писал:

Давайте! Ты наконец-то сделал бенчмарки?

Да, сделал. И освободил заказчику 4 из 6 дедиков. А занялся я этим, когда заказчик собрался покупать еще два. Проблема не стоимости серверов - это копейки. Проблема в зарплате спецов, которые за этим зоопарком присматривают - а это деньги.

Цитата:

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

Еще раз отмечу, что к аргументам я этот факт не отношу. Это только небольшое замечание

Цитата:

Ууууууу.. программер-профи, тебе фраза shared memory о чем-то говорит? Похоже что нет. Вернись на курсы "Системное программирование в юниксах для чайников за 24 часа", а потом сделай бенчмарки. А то мне страшно за благополучие твоих заказчиков и подчиненных, если они реально существуют конечно.

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

lega_cobra писал:

Да, сделал. И освободил заказчику 4 из 6 дедиков. А занялся я этим, когда заказчик собрался покупать еще два. Проблема не стоимости серверов - это копейки. Проблема в зарплате спецов, которые за этим зоопарком присматривают - а это деньги.

Не делай вид что не понял. Я про бенчмарки, о которых писал на первой и второй страницах этого топика.

Можно конкретней о тех задачах, которые крутились на сэкономленных 4 дедиках? Что-то мне сильно подсказывает что там совсем не в PHP дело было, а скорее изначально чайник-программер выбрал неверную платформу, не подходящую под поставленную задачу.

Цитата:

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

Стек и область данных child процессов апача с mod_php - чтобы ты не верил мне на слово, посмотри сам на ближайшем к тебе сервере. Она совсем не 2.5 мега, и уж тем более не 3-4 (хотя если постараться, то кривыми руками так сделать можно). Далее, чтобы апач не вылетал за пределы оперативки в своп, нормальный админ просто считает допустимое число процессов апача с учетом другого поставленного на сервер софта, и жестко ограничивает это с помощью директивы MaxClients, не говоря уже о прочем тюнинге конфига.

Давайте сделаем lega_cobra подпись под ником "Склефасовский"
Не в обиду - лично у меня это уже ассоциация

Quantum[Tau] писал:

Не делай вид что не понял. Я про бенчмарки, о которых писал на первой и второй страницах этого топика.

А ты в бенчах, о которыз писал mod_php убирал? Причем не под эмуляцией, а под реальной нагрузкой (вещи-то разные, по сути).

Цитата:

Можно конкретней о тех задачах, которые крутились на сэкономленных 4 дедиках? Что-то мне сильно подсказывает что там совсем не в PHP дело было, а скорее изначально чайник-программер выбрал неверную платформу, не подходящую под поставленную задачу.

Задачи самые примитивные - обыкновенные адалтовые платники с картинками , видео, госевухами и форумами. Несколько доменов с ЛЛ и ТГП. Ничего военного. Нагрузка, правда, большая.

Цитата:

Стек и область данных child процессов апача с mod_php - чтобы ты не верил мне на слово, посмотри сам на ближайшем к тебе сервере. Она совсем не 2.5 мега, и уж тем более не 3-4 (хотя если постараться, то кривыми руками так сделать можно).

Достаточно много. Не поленился просто залезть для сравнения на несколько серверов для сравнения с модулем и без. Без php Data+Stack Size каждого малыша примерно полтора метра. Тот же параметр для апачи с mod_php около 4-х метров. Помним, что код самой апачи всего 300 кил.

Цитата:

Далее, чтобы апач не вылетал за пределы оперативки в своп, нормальный админ просто считает допустимое число процессов апача с учетом другого поставленного на сервер софта, и жестко ограничивает это с помощью директивы MaxClients, не говоря уже о прочем тюнинге конфига.

Ну а как же иначе? И при росте нагрузки добавлять и добавлять сервера Как ты считаешь, насколько ложна фраза - "Запуск апача без mod_php освобождает заметный объем ресурсов, что дает возможность дать существенно большую нагрузку на сервер". Вон сама апача рекомендует вообще все модули выкинуть нафик, оставив только три.

И так, маленькое заключение. Отках от php дает весьма существенный выигрыш в производительности. На существенных проектах стоит задуматься об этом, что бы выбрать друго инструмент - я предложил C programming. Хренодер обозвал это полной х... (что там за слово было, я уже не помню ).

Последний раз редактировалось: lega_cobra (14/04/04 в 04:53), всего редактировалось 1 раз

Pentarh писал:

Давайте сделаем lega_cobra подпись под ником "Склефасовский" Не в обиду - лично у меня это уже ассоциация

Давайте лучше мне приз от мастер-х дадим

А по поводу ассоциации - ты это зря.Просто выходной у меня сегодня. Первый в этом году. Вот и есть вермя поболтать.