1.2, Зенитар (?), 21:13, 20/12/2009 [ответить] [﹢﹢﹢] [ · · · ]
| –4 +/– |
Линукс орг ру вместо пи эйч пи использует вообще Яву - и ничего, отлчно справляется. А вместо СУБД МуСКЛ - постгреСКЛ. По-моему, не хуже и даже во многом лучше. Но на С++... Если сумеют - было бы очень неплохо! А по скорости лучшим вариантом был бы разве что Ассемблер.
| |
|
2.4, Mike Lee (?), 21:42, 20/12/2009 [^] [^^] [^^^] [ответить]
| –1 +/– |
дада, при этом не надо использовать готовый вебсервер, а написать фэйсбуксервер со встроенным контентом на ассемблере, ага.
вот ведь земля дураками полнится.
| |
2.7, Карбофос (ok), 22:04, 20/12/2009 [^] [^^] [^^^] [ответить]
| +2 +/– |
есть библиотеки парсеров и regexp, так что особого гемора не вижу. обработка string производится тоже очень быстро.
| |
2.17, User294 (ok), 01:52, 21/12/2009 [^] [^^] [^^^] [ответить]
| +3 +/– |
> А по скорости лучшим вариантом был бы разве что Ассемблер.
Ассемблер, знаете ли, непортабелен (портирование == написанию с нуля) а жестко сидеть на одной архитектуре без шансов ее сменить - это попадалово. Некоторые вот так подсели хренадцать лет назад на проприетарные системы. И теперь жрут свой кактус до упора, потому что по простому уйти на что-то еще - опаньки.
А так, по моим наблюдениям, ряд high-load проектов юзает с или плюсы в критичных местах ну и заменяет тормозной SQL на примитивные но быстрые базы key-value. Понятное дело что геморрой. Зато скорость...
| |
|
3.18, Аноним (-), 08:54, 21/12/2009 [^] [^^] [^^^] [ответить]
| –4 +/– |
и куда это Вы собрались портироваться? O_o x86 будет еще дофигадцать лет.
| |
|
4.25, программер (?), 11:10, 21/12/2009 [^] [^^] [^^^] [ответить]
| +2 +/– |
как будто на x86 платформе свет клином сошелся.
ну и портировать на асме можно тоже. только не на асме писать, а на сях или плюсах. а только в тех местах, которые критичны можно делать inline для конкретной платформы. #ifdef X86
__asm__ (..)
#endif
| |
|
5.40, Лукас (ok), 16:21, 21/12/2009 [^] [^^] [^^^] [ответить]
| +/– |
>#ifdef X86
>__asm__ (..)
>#endif
А вы на практике это делаете? Если перенести код на другую платформу, появятся другие ошибки, которые не отлажены.
| |
|
6.43, программер (?), 16:45, 21/12/2009 [^] [^^] [^^^] [ответить]
| +/– |
если бы я на практике такого не делал, не заикался бы о таком. кстати, подобные решения есть и в ядре линукса
| |
|
7.58, User294 (ok), 23:28, 21/12/2009 [^] [^^] [^^^] [ответить]
| +/– |
>подобные решения есть и в ядре линукса
Только оно не все на асме писано, в отличие от дурацких предложений. У мну вот пингвин есть на x64, ARM и MIPS процессорах. Нормально, да? :) А теперь представьте себе то же самое если бы ВСЕ было писано на асме... кто бы уперся ядро 3 раза с нуля написать? :)
| |
|
|
5.41, Лукас (ok), 16:25, 21/12/2009 [^] [^^] [^^^] [ответить]
| +/– |
Я продолжу.
Но можно ассемблерную вставку делать как альтернативу коду на Си. Чтобы на Itanium работал код на Си. Такие директивы компилятора есть?
| |
5.57, User294 (ok), 23:21, 21/12/2009 [^] [^^] [^^^] [ответить]
| +/– |
>__asm__ (..)
>#endif
А ничего что если всю прогу так писать то это надо огромную монстрилу на х86 асме наворотить а потом еще и остальное на чем-то более портабельном. По сути 2 in 1 .. и кроме того - а вы пробовали писать большие проги на асме? Ну и как вам получившиеся портяночки? А чтоб потом еще и майнтайнить их нормально? :)
Итого - вменяемые люди так делают только мелкие вставки. А всю прогу на асме таким манером - удел маньяков.
| |
|
6.59, программер (?), 00:52, 22/12/2009 [^] [^^] [^^^] [ответить]
| +/– |
>Итого - вменяемые люди так делают только мелкие вставки. А всю прогу на асме таким манером - удел маньяков.
конечно, я разве утверждал что-то другое? небольшие асмовские вставки в критичных местах. да и то, если это действительно является одним из последних шагов оптимизации. обычно оптимизируют сами алгоритмы и/или структуры данных
если строчить на асме а потом отлаживать, то:
1. возрастает себестоимость продукта
2. исчезает "внятность" алгоритма (читабильность), а особенно, если программа пишется группой программистов, что увеличивает время разработки с последующим пунктом 1
| |
|
|
4.56, User294 (ok), 23:19, 21/12/2009 [^] [^^] [^^^] [ответить]
| +/– |
>и куда это Вы собрались портироваться? O_o x86 будет еще дофигадцать лет.
О блин, анонимные аналитики отжигают! Да, один когда-то про 640Кб говорил. А вы решили повторить достижение но только вместо "640Kb" будет "4Gb"? Или как вы будете адресовывать в рамках 1 процесса более 4Г не через зад если указатели 32-битные и все тут? Будет, простите, x64 всякое. Сервера, собссно, уже в массе своей на 64 бита переползать начинают. Что логично. А x64 (AMD64 и интельский эквивлент) - это все-таки не х86 и переписывать асм - придется... :P. Ну или скажем выпустит айбиэм (или кто там еще) проц бьющий на голову х86. И вы будете как лох сидеть на устаревшем, тормозном и неэффективном до упора, просто потому что на этапе принятия решений пролошились? Чужие примеры некоторым видимо не в прок :)
| |
|
3.39, Лукас (ok), 16:19, 21/12/2009 [^] [^^] [^^^] [ответить]
| +/– |
>Ассемблер, знаете ли, непортабелен
Люди это знают. Проблема в том, что зарплата разработчиков превысит, если это не делает, расходы на датацентр.
| |
|
|
1.5, Карбофос (ok), 21:51, 20/12/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
и к чему такое сравнение? чисто теоретический прикид того, что плюсы в десять раз быстрее, не учтено то, что критические компоненты уже реализованы не на php...
| |
1.11, NaGoS (?), 22:22, 20/12/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Авторы Wt выбросили больше 49 тысяч тонн пафоса, когда придумали как прорекламировать себя за счет популярного сайта. А вообще, на C++ может и быстрее, но они не посчитали разницу во времени написания/отладки/поддержки программы, за которую придется заплатить наверняка больше чем стоят эти сервера.
"The Environmental Impact of PHP Compared To C++ On Facebook" - это вообще гринписи писали, что они понимают в программировании :)
| |
|
2.14, pavlinux (ok), 00:03, 21/12/2009 [^] [^^] [^^^] [ответить]
| –1 +/– |
Тут и иожыку понятно, что а + b на PHP (со всем необходимым окружением), сожрет за день
1 кВтч, а на С++ 50Втч
| |
|
3.21, Юниксоид (??), 10:02, 21/12/2009 [^] [^^] [^^^] [ответить]
| –1 +/– |
У Вас есть результаты тестов ?
Просто a + b достаточно простая вещь, и она вряд ли в 20 раз медленнее в PHP
З.Ы.
Сам пишу на разных языках, какой для решения задачи удобнее - тот и использую.
| |
|
4.29, Voviandr (??), 11:40, 21/12/2009 [^] [^^] [^^^] [ответить]
| +/– |
А ничего, что a + b в С - это де-факто несклько инструкций процессора, а в PHP - выхов кучи фукций с возможным приведением типов?
| |
|
5.33, аноним (?), 12:38, 21/12/2009 [^] [^^] [^^^] [ответить]
| +/– |
>a + b в С - это де-факто несклько инструкций процессора
конечно, конечно
(листинг посмотрите, ага)
>в PHP - выхов кучи фукций
а ничего, что php хорошо кешируется?
| |
|
6.53, be_nt_all (ok), 19:04, 21/12/2009 [^] [^^] [^^^] [ответить]
| +/– |
>а ничего, что php хорошо кешируется?
А ничего, что тут кое-кто ни разу ни понимает разницу между ценой операции сложения в языках со статической и динамической типизацией? В с++ сложение — это одна инструкция ADD (FADD для плавающей точки) и возможно одна-две инструкции работы с регистром/стеком (если оптимизатор их не убрал). PHP же каждый раз
1) проверяет, к какому типу принадлежат оба операнда
2) преобразует их к одному типу
3) и только затем выполняет сложение
Хорошо кешируемый код виртуальной машины, который выполняется чуть ли не быстрее машинного кода — это миф. Т.е. да, были такие процессоры, на которых шитый код форта часто выполнялся быстрее кода скомпилированного средним C-транслятором того времени. Но в форте, как и в С/С++ динамической типизации нет.
Хотя PHP и дооптимизировали до состояния самого быстрого скриптового языка до С/С++ ему далеко. Да и до Java ещё не близко.
| |
|
|
4.47, pavlinux (ok), 16:55, 21/12/2009 [^] [^^] [^^^] [ответить]
| +2 +/– |
>У Вас есть результаты тестов ?
Я не гордая, я сделаю...
------ 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 = 500000000500000000
real 1m37.795s
user 1m37.651s
sys 0m0.015s
PHP
#time ./test.php 1000000000;
PHP INPUT = 1000000000
PHP RESULT = 500000000500000000
real 7m15.317s
user 7m14.815s
sys 0m0.033s
В 4.48 раза медленее. Умножаем на 75W процессор, 336.00 Ватт в воздух.
| |
|
5.48, pavlinux (ok), 18:01, 21/12/2009 [^] [^^] [^^^] [ответить]
| +2 +/– |
>[оверквотинг удален]
>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 = 500000000500000000
real 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 parallel
std::cout << "C++ RESULT = " << a << std::endl;
return 0;
}
После проделанных тестов у меня слов не хватает, куда надо засунуть PHP. :)
О, придумал, rpm -e && apt-get remove ....
| |
|
6.55, Карбофос (ok), 19:51, 21/12/2009 [^] [^^] [^^^] [ответить]
| +/– |
интересно было бы увидеть "производительность" строковых операций на яве. ;)
| |
|
7.63, pavlinux (ok), 23:13, 22/12/2009 [^] [^^] [^^^] [ответить]
| +/– |
>интересно было бы увидеть "производительность" строковых операций на яве. ;)
Не-е-е-е-е, .... сами, сами..
| |
|
|
|
|
3.37, Чорная дипрессия 666 (?), 15:52, 21/12/2009 [^] [^^] [^^^] [ответить]
| +/– |
Фейсбук -- это не движок численного решения систем дифференциальных уравнений, тут почти все операции -- со строками. Допустим, переписываем на ассемблере. И точно так же будем вызывать библиотечные функции для операций со строками, но из кода на ассемблере. Толку вообще никакого.
| |
|
4.38, Аноним (-), 16:13, 21/12/2009 [^] [^^] [^^^] [ответить]
| +/– |
Зачем на ассемблере библиотечные функции для операций со строками? И на чём по вашему написаны эти самые библиотеки? Наоборот от библиотек можно будет избавиться. И от размещения сторк в стеке. И от парсинга конструкций типа "str:%d:%d:%d". И процессор умеет что-то типа rep movsb. Profit!
| |
|
5.42, hhg (ok), 16:34, 21/12/2009 [^] [^^] [^^^] [ответить]
| +/– |
>процессор умеет что-то типа rep movsb
дада, и при этом из sqlБД. LOL
| |
|
6.46, Аноним (-), 16:50, 21/12/2009 [^] [^^] [^^^] [ответить]
| +/– |
>дада, и при этом из sqlБД. LOL
Так, дайте подумать. Это аргумент против ассемблера или против sqlБД?
От чего же лучше отказаться ради сокращения числа серверов Facebook?
Похоже против sqlБД.
| |
|
7.49, hhg (ok), 18:21, 21/12/2009 [^] [^^] [^^^] [ответить]
| +/– |
пусть будет так.
я вообще за защиту компьютеров от компьютерной информации. ;-)
| |
|
|
|
4.52, pavlinux (ok), 18:55, 21/12/2009 [^] [^^] [^^^] [ответить]
| +/– |
>Фейсбук -- это не движок численного решения систем дифференциальных уравнений
А сложение двух целых ещё долеко не дифура, и проще a + b, наверно только а = b :)
Вам что, выдрать кусок из Фейсбука из написать аналог на С++ ??? Не буду я, и так знаю.
Но если приспичит, опущу этот код ниже плинтуса, см. пример с openmp
Для справки: OpenMPI применяется не только для математики, чудно можно сортировать, сравнивать массивы чего хочешь, многопоточные алгоритмы... итп
АвтоВАЗ и PHP - Друзья на век!!! Кстати, сайт АВ не на PHP ли?
-------
Чесслово я не знал :)
http://www.lada-auto.ru/configurator/divdesign.php?=PHPE9568F34-D428-11d2-A76
http://www.lada-auto.ru/configurator/divdesign.php?=PHPE9568F35-D428-11d2-A76
| |
|
|
|
1.12, croster (ok), 22:46, 20/12/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
Лучше бы просто написали новость о выходе третьей версии этого инструментария, чем заниматься грязным пиаром без каких-либо серьезных доказательств.
| |
1.13, Аноним (-), 23:51, 20/12/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +10 +/– |
А ещё можно выключить все сервера Facebook.
Производительность труда и состояние окружающей среды только улучшатся.
| |
|
2.15, pavlinux (ok), 00:06, 21/12/2009 [^] [^^] [^^^] [ответить]
| +6 +/– |
>А ещё можно выключить все сервера Facebook.
Вот это самое разумное, а то круглыми сутками х...ю всяку болтают на этих соц. сетях, собственно как и мы все тут.
| |
|
3.35, Аноним (-), 15:42, 21/12/2009 [^] [^^] [^^^] [ответить]
| +/– |
>А вдруг вот поболтают чуваки на фейсбуке и придумают новый источник энергии.
Так оно и есть: в конечном счёте любой сайт существует за счёт посетителей. И придумывать ни чего не надо. Реклама же.
| |
|
|
1.16, FractalizeR (??), 00:42, 21/12/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Интересно, сколько разработчиков нужно будет нанять Facebook в дополнение к уже имеющимся, чтобы потом переписанный на C++ проект поддерживать?
| |
|
|
3.51, hhg (ok), 18:27, 21/12/2009 [^] [^^] [^^^] [ответить]
| +/– |
>Да, и сколько они ещё надышат СО2 :)
а уж сколько сероводорода от натуги произведут - и подумать страшно (-:
| |
|
|
1.22, Q (??), 10:31, 21/12/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
не учтено то, не учтено сё ...
сферический Facebook в вакууме получается
| |
1.23, Oles (?), 10:33, 21/12/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
выключить
+1
а также однокласников и вконтактов
это ж сколько яхт абрамовичу можно построить на секономленную энергию :)
| |
1.24, Чорная дипрессия 666 (?), 10:39, 21/12/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Они точно всё правильно подсчитали? Что-то сдается мне, что всё упирается в базу данных и максимум они оптимизируют процентов на десять, если на C++ перепишут.
| |
|
2.27, программер (?), 11:16, 21/12/2009 [^] [^^] [^^^] [ответить]
| +/– |
это теоретический подсчет, никаких конкретных цифр. ровным столько, как и предположение об "оптимизации процентов на десять".
| |
|
3.31, Аноним (-), 11:49, 21/12/2009 [^] [^^] [^^^] [ответить]
| +/– |
>это теоретический подсчет, никаких конкретных цифр. ровным столько, как и предположение об
>"оптимизации процентов на десять".
Разработчики Livejournal в свое время проводили эксперименты и делали подобные измерения. В итоге у них даже балансировщик нагрузки на Perl остался, так как в реальных условиях оправдана переработка на Си только очень небольших частей, от которых и зависит 90% производительности. Остальное смысла на Си переписывать нет, получим те пресловутые 10% выигрыша, но значительно потеряем в удобстве разработки, расширения и поддержки.
| |
|
4.32, Карбофос (ok), 12:11, 21/12/2009 [^] [^^] [^^^] [ответить]
| +/– |
просто спортивного интереса ради хотелось бы получить ссылку. не потому что не верю, нужно посмотреть в развернутом виде на сие исследование. там профайлинги всякие...
увеличение скорости обработки зависит от качества исследования. я может и не сомневаюсь в знаниях разработчиков Livejournal, но некоторые вещи можно бешено оптимировать даже не прибегая к другим языкам программирования.
в удобстве разработки можно тоже не терять, достаточно решать задачи не "в лоб". например, критичные функции скидываем в либу, а вызовы оригинальных функций перенаправлять, например.
| |
|
|
|
1.50, аноним (?), 18:25, 21/12/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Wt хотят что бы им денег дали на разработку и модернизацию. а гринписовские писюльки нужны что бы глаза замутить, потому что запросят они намного больше, чем стоят эти 20 тыщ серверов.
| |
1.54, be_nt_all (ok), 19:17, 21/12/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
А вообще идея C++ веб-фреймвока неплоха. Для суперзагруженных сайтов и т. п. А имея некий работающий прототип на том же PHP, написать нечто похожее на C++ (имея соотв. б-ку) не то, чтобы архисложно.
Вот только Wt тут, имхо, не в тему. Он не для написания (классических) сайтов, а для создания веб-морд к гуёвым приложениям (к примеру, использующим Qt). Заменяем Qt-шные виджеты на Wt-шные и брюки превращаются... превращаются... Ну в общем вы поняли.
В delphi есть похожая штука (если не убрали в новых версиях), IntraWeb зовётся.
А классический MVC веб-фреймвок для C++, это CppCMS (http://cppcms.sf.net/).
| |
|
2.60, Mr.Code (?), 07:22, 22/12/2009 [^] [^^] [^^^] [ответить]
| +/– |
ГЫ, они бы еще Google предложили переписать на С++, с учетом того сколько у гугла серверов и датацентров....ну в общем гринписовцы бы от радости обделались
| |
|
3.62, be_nt_all (ok), 22:38, 22/12/2009 [^] [^^] [^^^] [ответить]
| +/– |
>ГЫ, они бы еще Google предложили переписать на С++, с учетом того
>сколько у гугла серверов и датацентров....
Понимаешь, 90% кода Google на Java. PHP они вообще не используют. А Java, конечно, оверхеда поболее C++ даёт, но не фатально. Причём, мне думается, что все критичные вещи у Google если и не на C++, то это настолько заоптимизированная Java, что нам и не снилось.
| |
|
4.64, Mr.Code (?), 12:50, 12/01/2010 [^] [^^] [^^^] [ответить]
| +/– |
>>ГЫ, они бы еще Google предложили переписать на С++, с учетом того
>>сколько у гугла серверов и датацентров....
>
>Понимаешь, 90% кода Google на Java. PHP они вообще не используют. А
>Java, конечно, оверхеда поболее C++ даёт, но не фатально. Причём, мне
>думается, что все критичные вещи у Google если и не на
>C++, то это настолько заоптимизированная Java, что нам и не снилось.
>
Ну тогда нуна переписать гугл на ASM'е...)))
| |
|
|
|
|