Почему Так сложилось, что я очень сильно люблю...

Почему Так сложилось, что я очень сильно люблю ECMAScript. Когда я понял, что его можно запускать только внутри браузера, я, разумеется, расстроился. Когда видишь что-то хорошее, хочется это применить. А в браузере не наприменяешься. Ну да ладно.
Суть-то в том, что я ошибался! Узнал я когда-то о такой штуке, как node.js, и только совсем недавно у меня дошли руки до того, чтобы поиграться с ней. Собственно, заметка это для того, чтобы поделиться результатами, которые уже все наверняка знают года 2. Но ничего страшного, наверняка кому-то будет интересно.

Что исследовать? Дабы исследования не были причиной холиваров, я не стал тестировать функционал (а он действительно впечатляющий - мне пока не хватило терпения разобраться во всех надстройках node,js над классической спецификацией ECMAScript). Вместо этого я решил попробовать использовать его для того, для чего его, естественно использовать не стоит - но, извините, а зачем мы здесь собрались? (Кстати, вы здесь, очевидно, просто так, но вот я...) Итак, перед нами linux, программа time, а также коллеги в виде g++, javac (openjdk6) и (барабанная дробь) PHP CLI. Должен же быть рядом конкурент!
Хотя уместно было бы поерничать "нашел с чем сравнивать".
Исследовать будем производительность.
Я постарался все сделать максимально честно и не использовать сильные стороны языка.

Тест1: простые пробегом до корня, N=10000000
Время работыЯзык Время работы PHP 3m42s node.js 14.5s g++,O2 8.4s java 8.5s
Если вы, потирая руки, предвкушали измывательство над PHP, вы попали туда, куда надо! :-)
Этот тест, честно говоря, больше всего меня огорчил. Я не вижу причин, по которым скрипт на node.js должен выполняться принципиально дольше, чем java.

Тест2: решето Эратосфена за O(N * log log N), N=5000000 Выбор такого маленького N обусловлен печальными ограничениями на память у node.js. Очевидно, они расширяются, но я так расстроился, что не стал ничего менять.

Время работыЯзык Время работы PHP 6.1s node.js 0.72s g++,O2 0.14s java 0.23s


В этом тесте C++ относительно ожидаемо ушел в отрыв, также, как node ожидаемо пошел в баню - все-таки это, наверное, только моя мечта, чтобы в таких языках была такая сложная структура данных, как массив. Хотя стоит отметить, что node.js в этом плане хоть немного приличнее PHP.

Тест 3: алгоритм Флойда на случайном графе, N=1000, maxw=10000
Время работыЯзык Время работы PHP 5m41s node.js 19.9s g++,O2 1.8s java 1.6s
Эти результаты тоже достаточно предсказуемы, особенно после предыдущих. PHP держит марку и радует web-разработчиков, node.js отстал еще больше снова из-за массивов (двумерная адресация, вот и судите), а java обошла C++, видимо, из-за лучшей адресации и отсутствия возможности для C использовать свои хитрые оптимизации.

Пришло время заняться тем, чем занимаются олимпиадники почти в каждой задаче.

Тест 4: просуммировать числа из входного файла, N=1000000 Да, это, разумеется, важный тест. И особенно важный в свете того, что у node.js есть только низкоуровневые методы работы с I/O. Конечно, здесь я поимел счастье оценить, насколько я отстойный программист, и, знаете, оправдал возложенные на себя надежды - моя библиотека работает медленно.
Но тем не менее, node.js использовал универсальную библиотеку Scanner.js, которая в точности копирует функционал известной связки BufferedReader + StringTokenizer на java.
Итак, резы.

Время работыЯзык, способ чтения Время работы g++, scanf 0.13s g++, cin 0.31s java, BufferedReader 0.32s (WTF?) java, Scanner 1.10s node.js, Scanner.js 0.71s


К превеликому сожалению, почему-то BufferedReader+StringTokenizer работал дольше, чем iostream, и это меня сильно удивило. Скорее всего, я просто слишком хорошо думаю о BR (или слишком плохо о iostream).
Тем не менее: результат для node.js, как мне кажется, более, чем достойный. Особенно, если держать в уме тест№1, определяющий вычислительную производительность.


Заключение? Я доволен сделанной работой по ряду причин.
Во-первых, я все-таки спустился с небес на землю и понял, что на данном уровне развития платформы node.js не имеет шансов соревноваться с классиками вычислений - Си и Джавой. (И не надо говорить, что я Си даже не тестировал, а юзал богомерзкие плюсы)

Во-вторых, тем не менее, я увидел сравнимые величины, и это важно. Отличие на порядок на сложных тестах - это печально, безусловно. Но так ли часто вам нужен такой шикарный язык для вычислений чего-то на матрицах? Очевидно, для использования его мощи как раз нужны другие задачи, в которых он ведет себя достойно. Все понимают, что с той же джавой случится непотребство, стоит только начать клепать много объектов. Мораль: тестить мне еще и тестить.

И третий, такой, холиварный вывод. Уже на данный момент почти нет вещей, которые умеет PHP и не умеет node.js. Но, наверное, стоит оценить, сколько времени PHP жил и развивался, как серверный язык. И сколько node.js.
Сейчас интернет развивается, веб 2.0 становится все более веб 2.0-нее, и PHP уже начинает иногда кряхтеть и от своей скорости, и от архитектуры программ, на нем пишущихся. Да, в новых версиях появляются заплатки, добавлящие нужные фичи, анонимные функции... Но ведь это все костыли.
Что получается? Люди пишут на PHP, а не Си ради скорости разработки, но сейчас есть node.js, на котором и разрабатывать проще, и работает он ГОРАЗДО быстрее, и поддерживать проект, подозреваю, на нем попроще. Во всяком случае, в PHP сложно использовать инкапсуляцию, не пользуясь объектами и классами.

Почему я не упоминаю Python, Perl, Ruby?
Ну, например, потому что я в них не разбираюсь =) Но стоит отметить то, что захватить мир может только сравнительно новая технология (потому что иначе она бы захватила мир раньше). И также я не думаю, что "самый медленный язык в мире" имеет шанс стать стандартом де-факто.
Отсюда следует то, что будет соперничество. Но почему-то я не думаю, что PHP останется тем же гигантом.
Достаточно посмотреть на соотношение проектов C/C++ и Java. Постепенно, шаг за шагом, Java отвоевывает все больше и больше. Также будет и с этими языками. Роли можете расставить сами.

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

Надо продолжить тестировать node, находить слабые места и улучшать их. V8 - это, конечно, хорошо, но что-то мне подсказывает, что там есть, где найти быдлокода... Сейчас же не модно писать оптимально.

И, да, кстати, казалось бы, при чем тут холодец с васаби?
Потому что я его ем время от времени. И, знаете, как и node.js, он взбадривает десны, да и вообще, идет волшебно. 
Why It so happened that I really love ECMAScript. When I realized that it can only be run inside the browser, I, of course, was upset. When you see something good, you want to apply it. But you can’t use it in the browser. Anyway.
The bottom line is that I was wrong! I once found out about such a thing as node.js, and only recently I got my hands on it to play with it. Actually, this note is in order to share the results that everyone probably already knows about 2 years. But it's okay, for sure someone will be interested.

What to research? So that research was not the cause of holivars, I did not test the functionality (and it is really impressive - I haven’t had the patience to understand all the add-ons node, js over the classic ECMAScript specification). Instead, I decided to try to use it for what it is naturally not worth using it - but, excuse me, why are we here? (By the way, you are here, obviously, just like that, but here I am ...) So, we have linux, the time program, as well as colleagues in the form of g ++, javac (openjdk6) and (drum roll) PHP CLI. A competitor must be nearby!
Although it would be appropriate to curse "found something to compare."
We will investigate performance.
I tried to do everything as honestly as possible and not use the strengths of the language.

Test1: simple mileage to root, N = 10,000,000
Runtime Language Runtime PHP 3m42s node.js 14.5s g ++, O2 8.4s java 8.5s
If you, rubbing your hands, were looking forward to the abuse of PHP, you got where you need to! :-)
This test, frankly, upset me the most. I see no reason why the script on node.js should run essentially longer than java.

Test2: Eratosthenes sieve for O (N * log log N), N = 5,000,000. The choice of such a small N is due to the sad memory restrictions of node.js. Obviously, they are expanding, but I was so upset that I did not change anything.

Runtime Language Runtime of PHP 6.1s node.js 0.72s g ++, O2 0.14s java 0.23s


In this test, C ++ relatively expectedly went ahead of the gap, just as node expectedly went to the bathhouse - after all, it is probably only my dream that such languages ​​had such a complex data structure as an array. Although it is worth noting that node.js in this regard is at least a bit more decent than PHP.

Test 3: Floyd's algorithm on a random graph, N = 1000, maxw = 10000
Runtime Language Runtime PHP 5m41s node.js 19.9s g ++, O2 1.8s java 1.6s
These results are also quite predictable, especially after the previous ones. PHP holds the mark and pleases web developers, node.js lags even further again due to arrays (two-dimensional addressing, so judge), and java bypassed C ++, apparently due to better addressing and the lack of the ability for C to use its tricky optimizations .

It's time to do what the Olympiads do in almost every task.

Test 4: to sum the numbers from the input file, N = 1,000,000 Yes, this, of course, is an important test. And especially important in light of the fact that node.js has only low-level methods for working with I / O. Of course, here I had the good fortune to appreciate how much I am a sloppy programmer, and, you know, I justified my hopes - my library is slow.
Nevertheless, node.js used the universal library Scanner.js, which exactly copies the functionality of the well-known bundle BufferedReader + StringTokenizer to java.
So, the cuts.

Run time Language, way to read Run time g ++, scanf 0.13s g ++, cin 0.31s java, BufferedReader 0.32s (WTF?) Java, Scanner 1.10s node.js, Scanner.js 0.71s


Unfortunately, for some reason, BufferedReader + StringTokenizer worked longer than iostream, and this surprised me a lot. Most likely, I'm just thinking too much about BR (or too bad about iostream).
Nevertheless: the result for node.js, as it seems to me, is more than worthy. Especially if you keep in mind the test number 1, which determines the computational performance.


Conclusion? I am pleased with the work done for a number of reasons.
Firstly, I nevertheless descended from heaven to earth and realized that at this level of development of the platform node.js has no chance to compete with the classics of computing - C and Java. (And it’s not necessary to say that I didn’t even test X, but I used yummy advantages)

Secondly, however, I saw comparable values, and this is important. The difference in order on complex tests is sad, of course. But do you often need such a chic language for computing something on matrices? Obviously, to use his power just need other tasks in which he behaves with dignity. Everyone understands that indecency will happen with the same Java, you just have to start riveting a lot of objects. Moral: I also test to test.

And the third, such a holistic conclusion. Already at the moment there are almost no things that PHP can and node.js. can not. But it’s probably worth evaluating how long PHP has lived and developed as a server language. And how many node.js.
Now the Internet is evolving, web 2.0 is becoming more and more web 2.0, and PHP already sometimes starts to groan from its own
У записи 28 лайков,
5 репостов.
Эту запись оставил(а) на своей стене Валентин Фондаратов

Понравилось следующим людям