mad_c 4 янв 2011 в 11:39

CGI-программирование на ассемблере?!? – Легко!

11 мин

13K

Ненормальное программирование *

Из песочницы

+35

Комментарии 62

misha91 4 янв 2011 в 12:13

Это случайно не Ваше?

mad_c 4 янв 2011 в 12:17

Моё, и это тоже.

misha91 4 янв 2011 в 12:18

читал когда то раньше, хорошая статья =)

НЛО прилетело и опубликовало эту надпись здесь

agul 4 янв 2011 в 12:19

Все-таки в линуксе с CGI намного проще :)

smartly 4 янв 2011 в 21:21

Точно также. Не зря же это Common интерфейс.

VolCh 4 янв 2011 в 21:32

Может имелось в виду, что вызовы ОС как-то проще? Сам только из Сей вызывал.

smartly 4 янв 2011 в 21:49

Прочитать значения переменных окружения, stdin и писать в stdout — точно также. А дальше уже обычное программирование. Оно в разных системах конечно разное, но CGI тут не при чём.

mad_c 4 янв 2011 в 13:46

Сорри, сменил блог статьи и почему-то срезало окончание, поправил, буду внимательнее.
З.Ы. Я так понимаю это не баг, а «фича» :)

amarao 4 янв 2011 в 14:16

CGI+ассемблер выглядит как сущее издевательство.

CGI — ОЧЕНЬ медленный интерфейс к приложениям. Требуется подготовить среду окружения и сделать форк-экзек для каждого обращения. На фоне накладных расходов от CGI любая оптимизация кода самой программы будет микроскопической.

Всё равно, что оптимизировать расположение стаканов на столе поезда. Быстрее он от этого не поедет. Если уж хотите показать быстро-быстро-быстро, то используйте быстрые интерфейсы. WSGI, свой модуль к апачу или даже свой сервер как бэкэнд к ngnix'у.

mad_c 4 янв 2011 в 17:52

Вы предисловие и наименование блога читали? А так я с вами полностью согласен :)

smartly 4 янв 2011 в 21:28

Как ни странно — это не очень медленный интерфейс. Собственно fork+exec в линуксе весьма быстр оказывается. Но, конечно, при условии, что запускаемая программа не здоровенная и не грузит кучу своих прибамбасов перед выполнением задачи.

WSGI — это питоновская фича. Может вы имели в виду FastCGI или SCGI?

stas_agarkov 5 янв 2011 в 03:28

блин, вот мне интересно, ты тестил?
мы вот тестили и увидели, что скорость создания потоков (даже НЕ процессов) в дебиан — 50 штук в секунду
это очень мало
50 запросов в секунду это мало для сервера, обрабатывающего http-запросы от тыщи пользователей

saterenko 5 янв 2011 в 09:13

Вы явно что-то не то меряли… Сейчас специально написал тест, 10 000 тредов на маке (10.5.0 Darwin Kernel Version 10.5.0: Fri Nov 5 23:20:39 PDT 2010; root:xnu-1504.9.17~1/RELEASE_I386 i386 i386) создаются за 2.8 сек, на сервере (Linux smallbrother 2.6.31-22-server #68-Ubuntu SMP Tue Oct 26 16:50:02 UTC 2010 x86_64 GNU/Linux) за 0.17 сек.

#include <stdio.h>

#include <stdlib.h>

#include <pthread.h>

#include <time.h>

static void     *thread_loop(void *arg);

int

main(int argc, char **argv)

{

    int         i;

    clock_t     cl;

    pthread_t   threads[10000];

    cl = clock();

    for (i = 0; i < 10000; i++) {

        pthread_create(&threads[i], NULL, &thread_loop, NULL);

    }

    printf("complete in %f sec\n", (float) (clock() - cl) / (float) CLOCKS_PER_SEC);

    for (i = 0; i < 10000; i++) {

        pthread_join(threads[i], NULL);

    }

    exit(0);

}

static void *

thread_loop(void *arg)

{

}

smartly 5 янв 2011 в 09:46

на дебиане получилось:
complete in 0.280000 sec
segmentation fault
хотя непонятно, почему рухнуло.

stas_agarkov 5 янв 2011 в 10:22

ок, спасибо.
забыл сказать, что мы запускали непустые потоки явы через пул
видимо дело в этом…

saterenko 5 янв 2011 в 11:25

Я так и понял, но об этом надо писать, а то возникает ощущение, что СОЗДАНИЕ ПОТОКА — это очень медленно…

stas_agarkov 5 янв 2011 в 12:07

затестил на java таким кодом:
public class ThreadTest extends Thread {
private static final int N = 10000;
private static Thread[] threads = new Thread[N];
private int index;
public ThreadTest(int index) {
this.index = index;
}
public static void main(String[] args) {
long t1 = System.currentTimeMillis();
for (int i = 0; i < N; i++) {
threads[i] = new ThreadTest(i);
threads[i].start();
}
for (int i = 0; i < N; i++) {
try {
threads[i].join();
} catch (InterruptedException ignored) { }
}
System.out.println((System.currentTimeMillis()-t1) + " мс");
}
public void run() { }
}
100 тысяч потоков за 7,5 секунд
значит дело не в java
будем разбираться значит…

mad_c 5 янв 2011 в 12:13

Хе-хе, ну потоки это уже FCGI, может кто-нить затестит процессы? :) Понимаю, что результаты будут не те, но все-таки может CGI не совсем умер на новых релизах (в плане скорости запуска процессов)?

saterenko 5 янв 2011 в 20:25

На маке выдало порядка 9000 fork-ов в сек (400 за 0.043552 сек), на сервере порядка 56000 в сек (5000 за 0.09 сек). Но это не показатель, одно дело создать кучу потоков/процессов, и совсем другое дело как система будет потом всем этим добром управлять, переключение контекста недешёвая операция.

mad_c 5 янв 2011 в 20:39

Ну по крайней мере теперь понятно, что накладные ресурсы для создания процесса/потока минимальны, этот вопрос меня беспокоил 7 лет :))))

saterenko 6 янв 2011 в 20:09

Ну смотря какая задача решается и что требуется :)

impass 4 янв 2011 в 16:11

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

mad_c 4 янв 2011 в 17:53

Вопрос тот же, что и к предыдущему оратору.

vit1251 4 янв 2011 в 20:43

Накладные расходы на CreateProcess не будут сильно тратить время на нагруженных проектах? mod_perl, mod_wcgi разве не для этого подключаются в Apache?

mad_c 4 янв 2011 в 21:36

Будут. См.п1.

Ray 4 янв 2011 в 20:47

По-моему здесь программирование ради программирования… Так, для души ))

VolCh 4 янв 2011 в 20:56

Ну вы что, компилятор не вытянет таких оптимизаций, которые доступны программисту на асме в совершенстве знающему архитектуру процессора :D

mad_c 4 янв 2011 в 21:33

Вытянет душу из программиста, если не более :) остальное опустим:)

GIum 4 янв 2011 в 23:01

А название блога «Ненормальное программирование» Вам не дает ответа на этот вопрос?

VolCh 4 янв 2011 в 18:31

Я на Си писал, причём не для «ненормального программирования», а для вполне себе продакшена, до ассемблера как-то не додумался :)

ЗЫ Потом открыл для себя PHP3

mad_c 4 янв 2011 в 18:47

Ну дык какие тогда года были :)

Vertex 4 янв 2011 в 19:56

— Доктор, а может Java?
— Не спорьте, доктор сказал, asm, значит asm…

dorian 4 янв 2011 в 20:05

не поймите неправильно но первая мысль — ССЗБ )))

googol 4 янв 2011 в 20:12

Я кстати подумываю о том чтобы попробывать web-development на языке Vala.

Vala быстр (сравнима с С++) и имеет кучу библиотек, например баиндинги к libsoup library.gnome.org/devel/libsoup/stable/libsoup-server-howto.html

DLag 4 янв 2011 в 21:34

Я только в Go вник и библиотек нужных написал, а вы еще один интересный конструктор…
Порвусь блин.:)

mono2k 4 янв 2011 в 20:21

– Легко!

но зачем???

mad_c 4 янв 2011 в 20:26

И опять — читать первый абзац :)

mono2k 5 янв 2011 в 09:46

вопрос-то был риторический…

mad_c 5 янв 2011 в 09:56

Тогда — риторический ответ :) Мне просто было это интересно 7 лет назад, а асм, в то время для меня был язык номер один, хотелось реализовать это именно на нем. Сейчас я занимаюсь решением совершенно других проблем. И в совершенно другой области, но этот опыт оказался совсем не лишним :)

OlegTar 4 янв 2011 в 20:26

Это же блог «ненормальное программирование»

mad_c 4 янв 2011 в 20:29

А вам кажется что писать cgi скрипты на асме это нормально?

mad_c 4 янв 2011 в 20:33

Предыдущий вопрос адресуется уровнем выше — никак не привыкну, сорь :)

JokerOfGod 4 янв 2011 в 20:25

Спасибо, интересная статья, уверен что мне в ближайшее время понадобится)

Vertex 4 янв 2011 в 21:40

Вот так, с юморком да с задоринкой, люди от военки косят… )

JokerOfGod 4 янв 2011 в 21:53

в смысле?

Hoorsh 4 янв 2011 в 22:10

Эх, еще бы сравнение производительности…
Например, сортировка пузырьком на PHP через CGI, PHP через mod_php и CGI asm

taliban 5 янв 2011 в 00:15

О.О Я ведь надеюсь это шутка была? Добавляйте тег иронии, ато могут не так понять

Doktor_Gradus 5 янв 2011 в 04:08

Шелдоны не поймут?

taliban 5 янв 2011 в 11:03

Учитывая последние тенденции, и судя по некоторым каментам, это вполне может быть не шуткой =)

Ppord 4 янв 2011 в 22:30

Из буханки хлеба и… Ну вы поняли. Афтор, я читал вас еще на васме, шикарный подход — но не оставлял вопрос: нафея? Я понимаю, ембед-сервер на асме для «мелких» железяк, но тут… Оставьте вы лавры пхпшнегам, делайте свое дело. Какой оптимайз на асме, коли у меня на кортесе третьем нгинкс с пхп5 (не поверите — «искаропки») шикарно справляются с отдачей динамики от полсотни точек телеметрии? Сам асм в руки брал последний раз два года назад — когда надо было лоадер для сегата .11 наваять для чтения памяти в режиме бутлоадера — для борьбы с пресловутой «мухой цц». Вот честно — чую, скоро нас динозавров в запас спишут. Обидно до жути — приходится приспосабливаться.

mad_c 4 янв 2011 в 23:03

Ну вы же читали первый абзц, да? :) с динозаврами согласен.

exception13 4 янв 2011 в 22:41

а под Inferno/Plan9/Linux/VxWorks/RTEMS ARM/MIPS/PPC это работает?

exception13 4 янв 2011 в 22:46

и таки да. прошу асмовый код под любой VLIW проц

taliban 5 янв 2011 в 00:17

=) Кто напишет на брейнфаке то же самое? Пол царства и царевну в придачу! После этого все что будет в этом блоге будет казаться детскими выходками…

feodal 5 янв 2011 в 14:09

мсье знает толк

kAIST 5 янв 2011 в 20:42

хм… даешь cms на bat'никах :)

mad_c 5 янв 2011 в 20:50

Легко! но лучше на скомпиленых из асма exe-шников, — вон, выше уже вроде определились: накладных расходов на cgi почти нет :)

kAIST 5 янв 2011 в 20:54

Нет, на асме более гибко получается, насколько я понимаю в ущербности сценариев bat, поэтому лучше на bat :)

mad_c 5 янв 2011 в 20:58

В таком случае предлагаю вернуться к коменту несколько выше и написать ее на brain fuck :)

w0lf 17 янв 2011 в 08:34

В совсем ранней юности делал чятик на чистом C. Потом уже открыл для себя все прелести Perl.

Ilja-K 3 ноя 2016 в 19:30

Хорошая статья. Спасибо.
Люблю ассемблер.

С CGI я впервые познакомился через perl и PHP. Потом пробовал Python.
Я люблю лёгкий и быстрый веб, долгое время искал дял себя тулкиты, писал CMS, а потом начал писать на Си.

Ну и естественно решил опробовать его для Web. Итогом стала библиотека для веб разработки. Весит меньше 80Кб. Содержит в себе встроенный веб сервер, который я использую как бэкенд. Парсит переменные POST, GET, Cookies, HTTP заголовки. Содержит лёгкий шаблонизатор. Свой сайт так и пишу на нём. Начал на днях разработку новой библиотеки, куда буду включать готовые модули: авторизация, рассылки, баг треккер и т.п.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий