The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Оценка на сколько можно сократить число серверов Facebook, переписав PHP скрипты на C++

20.12.2009 21:03

Используя недавно опубликованные данные об инфраструктуре сети Facebook, создатели свободного инструментария для web-разработки Wt, пришли к выводу, что если переписать код PHP скриптов Facebook на языке C++, то число серверов обслуживающих проект уменьшилось бы с 30 тыс. до 7.5 тыс. Выключение 22.5 тыс. серверов за счет экономии электроэнергии позволило бы избежать выброса в атмосферу 49 тысяч тонн углекислого газа.

Представленные в статье выводы достаточно поверхностны и сделаны с расчетом на то, что язык С++ является в 10 раз более эффективным, чем PHP. При оценке не учтено то, что наиболее требовательные к производительности компоненты Facebook и так переписаны на С++, а PHP используется как правило только на стороне фронтэнда, при этом все что можно кэшируется в памяти. Также не учтено то, что большая нагрузка в Facebook приходится на систему ввода/вывода, так как в трафике большую долю занимают изображения. Основным же узким местом, несмотря на кэширование, по прежнему остается не PHP, а СУБД MySQL, именно на этапе обращений к СУБД возникают основные задержки, а не при выполнении силами PHP функций по агрегированию данных и компоновке web-страниц.

  1. Главная ссылка к новости (http://developers.slashdot.org...)
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/24748-php
Ключевые слова: php, cpp, web, optimization
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (54) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 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 раза с нуля написать? :)

     
     
  • 8.61, программер (?), 12:23, 22/12/2009 [^] [^^] [^^^] [ответить]  
  • +/
    здесь кто-то утверждал, что все ядро на асме написано ... текст свёрнут, показать
     
  • 5.41, Лукас (ok), 16:25, 21/12/2009 [^] [^^] [^^^] [ответить]  
  • +/
    Я продолжу.

    Но можно ассемблерную вставку делать как альтернативу коду на Си. Чтобы на Itanium работал код на Си. Такие директивы компилятора есть?

     
     
  • 6.44, программер (?), 16:47, 21/12/2009 [^] [^^] [^^^] [ответить]  
  • +/
    #ifndef IA64
    // код на си
    #else
    // Itanium assembler code
    __asm__()
    #endif
     
     
  • 7.45, программер (?), 16:48, 21/12/2009 [^] [^^] [^^^] [ответить]  
  • +/
    ну или как душе угодно
     
  • 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 [^] [^^] [^^^] [ответить]  
  • +/
    >Ассемблер, знаете ли, непортабелен

    Люди это знают. Проблема в том, что зарплата разработчиков превысит, если это не делает, расходы на датацентр.

     
  • 2.36, Aquarius (ok), 15:43, 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.

    Вот это самое разумное, а то круглыми сутками х...ю всяку болтают на этих соц. сетях, собственно как и мы все тут.

     
  • 2.34, Чорная дипрессия 666 (?), 14:51, 21/12/2009 [^] [^^] [^^^] [ответить]  
  • +/
    А вдруг вот поболтают чуваки на фейсбуке и придумают новый источник энергии.
     
     
  • 3.35, Аноним (-), 15:42, 21/12/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >А вдруг вот поболтают чуваки на фейсбуке и придумают новый источник энергии.

    Так оно и есть: в конечном счёте любой сайт существует за счёт посетителей. И придумывать ни чего не надо. Реклама же.

     

  • 1.16, FractalizeR (??), 00:42, 21/12/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Интересно, сколько разработчиков нужно будет нанять Facebook в дополнение к уже имеющимся, чтобы потом переписанный на C++ проект поддерживать?
     
     
  • 2.20, diff (??), 09:57, 21/12/2009 [^] [^^] [^^^] [ответить]  
  • +/
    Да, и сколько они ещё надышат СО2 :)
     
     
  • 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'е...)))

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру