Используя недавно опубликованные данные (http://idleprocess.wordpress.com/2009/11/24/presentation-sum.../) об инфраструктуре сети Facebook, создатели инструментария для web-разработки Wt (http://www.webtoolkit.eu/wt), пришли к выводу (http://developers.slashdot.org/story/09/12/20/1433257/The-En...), что если переписать код PHP скриптов Facebook на языке C++, то число серверов обслуживающих проект уменьшилось бы с 30 тыс. до 7.5 тыс. Выключение 22.5 тыс. серверов за счет экономии электроэнергии позволило бы избежать выброса в атмосферу 49 тысяч тонн углекислого газа.
Представленные в статье выводы достаточно поверхностны и сделаны с расчетом на то, что язык С++ является в 10 раз более эффективным, чем PHP. При оценке не учтено то, что наиболее требовательные к производительности компоненты Facebook и так переписаны на С++, а PHP используется как правило только на стороне...URL: http://developers.slashdot.org/story/09/12/20/1433257/The-En...
Новость: http://www.opennet.me/opennews/art.shtml?num=24748
Линукс орг ру вместо пи эйч пи использует вообще Яву - и ничего, отлчно справляется. А вместо СУБД МуСКЛ - постгреСКЛ. По-моему, не хуже и даже во многом лучше. Но на С++... Если сумеют - было бы очень неплохо! А по скорости лучшим вариантом был бы разве что Ассемблер.
дада, при этом не надо использовать готовый вебсервер, а написать фэйсбуксервер со встроенным контентом на ассемблере, ага.вот ведь земля дураками полнится.
есть библиотеки парсеров и regexp, так что особого гемора не вижу. обработка string производится тоже очень быстро.
> А по скорости лучшим вариантом был бы разве что Ассемблер.Ассемблер, знаете ли, непортабелен (портирование == написанию с нуля) а жестко сидеть на одной архитектуре без шансов ее сменить - это попадалово. Некоторые вот так подсели хренадцать лет назад на проприетарные системы. И теперь жрут свой кактус до упора, потому что по простому уйти на что-то еще - опаньки.
А так, по моим наблюдениям, ряд high-load проектов юзает с или плюсы в критичных местах ну и заменяет тормозной SQL на примитивные но быстрые базы key-value. Понятное дело что геморрой. Зато скорость...
и куда это Вы собрались портироваться? O_o x86 будет еще дофигадцать лет.
как будто на x86 платформе свет клином сошелся.
ну и портировать на асме можно тоже. только не на асме писать, а на сях или плюсах. а только в тех местах, которые критичны можно делать inline для конкретной платформы. #ifdef X86
__asm__ (..)
#endif
>#ifdef X86
>__asm__ (..)
>#endifА вы на практике это делаете? Если перенести код на другую платформу, появятся другие ошибки, которые не отлажены.
если бы я на практике такого не делал, не заикался бы о таком. кстати, подобные решения есть и в ядре линукса
>подобные решения есть и в ядре линуксаТолько оно не все на асме писано, в отличие от дурацких предложений. У мну вот пингвин есть на x64, ARM и MIPS процессорах. Нормально, да? :) А теперь представьте себе то же самое если бы ВСЕ было писано на асме... кто бы уперся ядро 3 раза с нуля написать? :)
здесь кто-то утверждал, что все ядро на асме написано?
Я продолжу.Но можно ассемблерную вставку делать как альтернативу коду на Си. Чтобы на Itanium работал код на Си. Такие директивы компилятора есть?
#ifndef IA64
// код на си
#else
// Itanium assembler code
__asm__()
#endif
ну или как душе угодно
>__asm__ (..)
>#endifА ничего что если всю прогу так писать то это надо огромную монстрилу на х86 асме наворотить а потом еще и остальное на чем-то более портабельном. По сути 2 in 1 .. и кроме того - а вы пробовали писать большие проги на асме? Ну и как вам получившиеся портяночки? А чтоб потом еще и майнтайнить их нормально? :)
Итого - вменяемые люди так делают только мелкие вставки. А всю прогу на асме таким манером - удел маньяков.
>Итого - вменяемые люди так делают только мелкие вставки. А всю прогу на асме таким манером - удел маньяков.конечно, я разве утверждал что-то другое? небольшие асмовские вставки в критичных местах. да и то, если это действительно является одним из последних шагов оптимизации. обычно оптимизируют сами алгоритмы и/или структуры данных
если строчить на асме а потом отлаживать, то:
1. возрастает себестоимость продукта
2. исчезает "внятность" алгоритма (читабильность), а особенно, если программа пишется группой программистов, что увеличивает время разработки с последующим пунктом 1
>и куда это Вы собрались портироваться? O_o x86 будет еще дофигадцать лет.О блин, анонимные аналитики отжигают! Да, один когда-то про 640Кб говорил. А вы решили повторить достижение но только вместо "640Kb" будет "4Gb"? Или как вы будете адресовывать в рамках 1 процесса более 4Г не через зад если указатели 32-битные и все тут? Будет, простите, x64 всякое. Сервера, собссно, уже в массе своей на 64 бита переползать начинают. Что логично. А x64 (AMD64 и интельский эквивлент) - это все-таки не х86 и переписывать асм - придется... :P. Ну или скажем выпустит айбиэм (или кто там еще) проц бьющий на голову х86. И вы будете как лох сидеть на устаревшем, тормозном и неэффективном до упора, просто потому что на этапе принятия решений пролошились? Чужие примеры некоторым видимо не в прок :)
>Ассемблер, знаете ли, непортабеленЛюди это знают. Проблема в том, что зарплата разработчиков превысит, если это не делает, расходы на датацентр.
проекты несколько различного масштаба
и к чему такое сравнение? чисто теоретический прикид того, что плюсы в десять раз быстрее, не учтено то, что критические компоненты уже реализованы не на php...
Авторы Wt выбросили больше 49 тысяч тонн пафоса, когда придумали как прорекламировать себя за счет популярного сайта. А вообще, на C++ может и быстрее, но они не посчитали разницу во времени написания/отладки/поддержки программы, за которую придется заплатить наверняка больше чем стоят эти сервера."The Environmental Impact of PHP Compared To C++ On Facebook" - это вообще гринписи писали, что они понимают в программировании :)
Тут и иожыку понятно, что а + b на PHP (со всем необходимым окружением), сожрет за день
1 кВтч, а на С++ 50Втч
У Вас есть результаты тестов ?
Просто a + b достаточно простая вещь, и она вряд ли в 20 раз медленнее в PHPЗ.Ы.
Сам пишу на разных языках, какой для решения задачи удобнее - тот и использую.
А ничего, что a + b в С - это де-факто несклько инструкций процессора, а в PHP - выхов кучи фукций с возможным приведением типов?
>a + b в С - это де-факто несклько инструкций процессораконечно, конечно
(листинг посмотрите, ага)>в PHP - выхов кучи фукций
а ничего, что php хорошо кешируется?
>а ничего, что php хорошо кешируется?А ничего, что тут кое-кто ни разу ни понимает разницу между ценой операции сложения в языках со статической и динамической типизацией? В с++ сложение — это одна инструкция ADD (FADD для плавающей точки) и возможно одна-две инструкции работы с регистром/стеком (если оптимизатор их не убрал). PHP же каждый раз
1) проверяет, к какому типу принадлежат оба операнда
2) преобразует их к одному типу
3) и только затем выполняет сложениеХорошо кешируемый код виртуальной машины, который выполняется чуть ли не быстрее машинного кода — это миф. Т.е. да, были такие процессоры, на которых шитый код форта часто выполнялся быстрее кода скомпилированного средним C-транслятором того времени. Но в форте, как и в С/С++ динамической типизации нет.
Хотя PHP и дооптимизировали до состояния самого быстрого скриптового языка до С/С++ ему далеко. Да и до Java ещё не близко.
>У Вас есть результаты тестов ?Я не гордая, я сделаю...
------ C++ -------------------------------------
#include <iostream>
#include <stdlib.h>int main(int argc, char **argv) {
long long a = 0;
std::cout << "C++ INPUT = " << argv[1] << std::endl;for (int i = 0; i <= atoi(argv[1]); i++) {
a += i;
}
std::cout << "C++ RESULT = " << a << std::endl;
return 0;
}--- PHP -------------------------------------
#!/usr/bin/php<?php
$a = 0;echo "PHP INPUT = $argv[1]\n";
for ($i = 0; $i <= ($argv[1]); $i++) {
$a += $i;
}echo "PHP RESULT = $a\n";
?>-------------------------------------
Будем арифметич. прогрессию, от 0 до 1.000.000.000
сначала запущу на C++, потом на PHP и пойду покурю... :)C++
# time ./a.out 1000000000;
C++ INPUT = 1000000000
C++ RESULT = 500000000500000000real 1m37.795s
user 1m37.651s
sys 0m0.015sPHP
#time ./test.php 1000000000;
PHP INPUT = 1000000000
PHP RESULT = 500000000500000000real 7m15.317s
user 7m14.815s
sys 0m0.033s
В 4.48 раза медленее. Умножаем на 75W процессор, 336.00 Ватт в воздух.
>[оверквотинг удален]
>PHP INPUT = 1000000000
>PHP RESULT = 500000000500000000
>
>real 7m15.317s
>user 7m14.815s
>sys 0m0.033s
>
>
>В 4.48 раза медленее. Умножаем на 75W процессор, 336.00 Ватт в воздух.Или в 435 медленее, если C++ в режиме OpenMPI на 4 горшках
# time ./a.out 1000000000
C++ INPUT = 1000000000
C++ RESULT = 500000000500000000real 0m0.474s
user 0m1.788s
sys 0m0.034s--- OpenMPI C++ -----
// gcc-4.4 -fopenmp test.cpp#include <iostream>
#include <stdlib.h>int main(int argc, char **argv) {
long long a = 0;
int i = 0;
int limit = atoi(argv[1]);std::cout << "C++ INPUT = " << limit << std::endl;
#pragma omp parallel for \
default(shared) \
private (i) \
schedule(static,4) \
reduction(+:a)for (i = 0; i <= limit; i++) {
a += i;
}
#pragma omp end parallelstd::cout << "C++ RESULT = " << a << std::endl;
return 0;
}
После проделанных тестов у меня слов не хватает, куда надо засунуть PHP. :)
О, придумал, rpm -e && apt-get remove ....
интересно было бы увидеть "производительность" строковых операций на яве. ;)
>интересно было бы увидеть "производительность" строковых операций на яве. ;)Не-е-е-е-е, .... сами, сами..
Фейсбук -- это не движок численного решения систем дифференциальных уравнений, тут почти все операции -- со строками. Допустим, переписываем на ассемблере. И точно так же будем вызывать библиотечные функции для операций со строками, но из кода на ассемблере. Толку вообще никакого.
Зачем на ассемблере библиотечные функции для операций со строками? И на чём по вашему написаны эти самые библиотеки? Наоборот от библиотек можно будет избавиться. И от размещения сторк в стеке. И от парсинга конструкций типа "str:%d:%d:%d". И процессор умеет что-то типа rep movsb. Profit!
>процессор умеет что-то типа rep movsbдада, и при этом из sqlБД. LOL
>дада, и при этом из sqlБД. LOLТак, дайте подумать. Это аргумент против ассемблера или против sqlБД?
От чего же лучше отказаться ради сокращения числа серверов Facebook?
Похоже против sqlБД.
пусть будет так.
я вообще за защиту компьютеров от компьютерной информации. ;-)
>Фейсбук -- это не движок численного решения систем дифференциальных уравненийА сложение двух целых ещё долеко не дифура, и проще a + b, наверно только а = b :)
Вам что, выдрать кусок из Фейсбука из написать аналог на С++ ??? Не буду я, и так знаю.
Но если приспичит, опущу этот код ниже плинтуса, см. пример с openmpДля справки: OpenMPI применяется не только для математики, чудно можно сортировать, сравнивать массивы чего хочешь, многопоточные алгоритмы... итп
АвтоВАЗ и PHP - Друзья на век!!! Кстати, сайт АВ не на PHP ли?-------
Чесслово я не знал :)
http://www.lada-auto.ru/configurator/divdesign.php?=PHPE9568...
http://www.lada-auto.ru/configurator/divdesign.php?=PHPE9568...
Лучше бы просто написали новость о выходе третьей версии этого инструментария, чем заниматься грязным пиаром без каких-либо серьезных доказательств.
А ещё можно выключить все сервера Facebook.
Производительность труда и состояние окружающей среды только улучшатся.
>А ещё можно выключить все сервера Facebook.Вот это самое разумное, а то круглыми сутками х...ю всяку болтают на этих соц. сетях, собственно как и мы все тут.
А вдруг вот поболтают чуваки на фейсбуке и придумают новый источник энергии.
>А вдруг вот поболтают чуваки на фейсбуке и придумают новый источник энергии.Так оно и есть: в конечном счёте любой сайт существует за счёт посетителей. И придумывать ни чего не надо. Реклама же.
Интересно, сколько разработчиков нужно будет нанять Facebook в дополнение к уже имеющимся, чтобы потом переписанный на C++ проект поддерживать?
Да, и сколько они ещё надышат СО2 :)
>Да, и сколько они ещё надышат СО2 :)а уж сколько сероводорода от натуги произведут - и подумать страшно (-:
не учтено то, не учтено сё ...сферический Facebook в вакууме получается
выключить
+1
а также однокласников и вконтактов
это ж сколько яхт абрамовичу можно построить на секономленную энергию :)
Они точно всё правильно подсчитали? Что-то сдается мне, что всё упирается в базу данных и максимум они оптимизируют процентов на десять, если на C++ перепишут.
это теоретический подсчет, никаких конкретных цифр. ровным столько, как и предположение об "оптимизации процентов на десять".
>это теоретический подсчет, никаких конкретных цифр. ровным столько, как и предположение об
>"оптимизации процентов на десять".Разработчики Livejournal в свое время проводили эксперименты и делали подобные измерения. В итоге у них даже балансировщик нагрузки на Perl остался, так как в реальных условиях оправдана переработка на Си только очень небольших частей, от которых и зависит 90% производительности. Остальное смысла на Си переписывать нет, получим те пресловутые 10% выигрыша, но значительно потеряем в удобстве разработки, расширения и поддержки.
просто спортивного интереса ради хотелось бы получить ссылку. не потому что не верю, нужно посмотреть в развернутом виде на сие исследование. там профайлинги всякие...
увеличение скорости обработки зависит от качества исследования. я может и не сомневаюсь в знаниях разработчиков Livejournal, но некоторые вещи можно бешено оптимировать даже не прибегая к другим языкам программирования.
в удобстве разработки можно тоже не терять, достаточно решать задачи не "в лоб". например, критичные функции скидываем в либу, а вызовы оригинальных функций перенаправлять, например.
Wt хотят что бы им денег дали на разработку и модернизацию. а гринписовские писюльки нужны что бы глаза замутить, потому что запросят они намного больше, чем стоят эти 20 тыщ серверов.
А вообще идея C++ веб-фреймвока неплоха. Для суперзагруженных сайтов и т. п. А имея некий работающий прототип на том же PHP, написать нечто похожее на C++ (имея соотв. б-ку) не то, чтобы архисложно.Вот только Wt тут, имхо, не в тему. Он не для написания (классических) сайтов, а для создания веб-морд к гуёвым приложениям (к примеру, использующим Qt). Заменяем Qt-шные виджеты на Wt-шные и брюки превращаются... превращаются... Ну в общем вы поняли.
В delphi есть похожая штука (если не убрали в новых версиях), IntraWeb зовётся.
А классический MVC веб-фреймвок для C++, это CppCMS (http://cppcms.sf.net/).
ГЫ, они бы еще Google предложили переписать на С++, с учетом того сколько у гугла серверов и датацентров....ну в общем гринписовцы бы от радости обделались
>ГЫ, они бы еще Google предложили переписать на С++, с учетом того
>сколько у гугла серверов и датацентров....Понимаешь, 90% кода Google на Java. PHP они вообще не используют. А Java, конечно, оверхеда поболее C++ даёт, но не фатально. Причём, мне думается, что все критичные вещи у Google если и не на C++, то это настолько заоптимизированная Java, что нам и не снилось.
>>ГЫ, они бы еще Google предложили переписать на С++, с учетом того
>>сколько у гугла серверов и датацентров....
>
>Понимаешь, 90% кода Google на Java. PHP они вообще не используют. А
>Java, конечно, оверхеда поболее C++ даёт, но не фатально. Причём, мне
>думается, что все критичные вещи у Google если и не на
>C++, то это настолько заоптимизированная Java, что нам и не снилось.
>Ну тогда нуна переписать гугл на ASM'е...)))