The OpenNET Project / Index page

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

форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка  RSS
"Размышление над проблемами формата Ogg"
Вариант для распечатки  
Пред. тема | След. тема 
Форумы Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Размышление над проблемами формата Ogg"  +/
Сообщение от opennews on 18-Мрт-10, 16:51 
Один из разработчиков проекта FFmpeg в статье "Ogg objections (http://hardwarebug.org/2010/03/03/ogg-objections/)" подробно рассказал о недостатках мультимедиа контейнера Ogg. Вывод в статье сделан неутешительный, свободность и независимость от патентов - это конечно хорошо,  но с технической стороны формат не может конкурировать с аналогами и требует полной переработки. Изначально Ogg создан для работы с простейшими аудео-потоками, из чего следует его излишняя усложненность и нестандартность при работе с другими видами данных, например, при при инкапсуляции видео-потоков.


Основные недостатки Ogg:


-  Излишнее расходование ресурсов при организации хранения привязанной к потоку служебной информации. Заголовок страницы данных имеет размер 27 байт, в то время как его без проблем можно было бы ужать до 12 байт. Большой объем лишних полей в заголовке страницы данных, приводит к увеличению размера итогового файла примерно на 1%, в то время как для формата MP4 этот показатель равен 0.0...

URL:
Новость: https://www.opennet.ru/opennews/art.shtml?num=25852

Высказать мнение | Ответить | Правка | Cообщить модератору

Оглавление

Сообщения по теме [Сортировка по времени | RSS]


1. "Размышление над проблемами формата Ogg"  +8 +/
Сообщение от VyacheslavS on 18-Мрт-10, 16:51 
mkv - наше фсё!
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

3. "Размышление над проблемами формата Ogg"  –3 +/
Сообщение от аноним on 18-Мрт-10, 17:12 
btw для вашего всего нет нормальных редакторов
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

6. "Размышление над проблемами формата Ogg"  –2 +/
Сообщение от RedRat (ok) on 18-Мрт-10, 17:23 
Вот только формат MKV настолько "развесист", что Avery Lee отказался его добавлять в свой VirtualBub. Приходится извращаться с AviSynth или DirectShow-фильтром.
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

7. "Размышление над проблемами формата Ogg"  +5 +/
Сообщение от аноним on 18-Мрт-10, 17:47 
Кто такой Avery Lee чтобы к его мнению прислушиваться?
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

10. "Размышление над проблемами формата Ogg"  –1 +/
Сообщение от pavlinux (ok) on 18-Мрт-10, 17:54 
Афтор Видовской рипалки/декодера/плющилки Virtualdub, меж прочим GPL-ная
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

12. "Размышление над проблемами формата Ogg"  –4 +/
Сообщение от аноним on 18-Мрт-10, 18:15 
>Кто такой Avery Lee чтобы к его мнению прислушиваться?

http://sourceforge.net/projects/virtualdub/files/
Downloads virtualdub-win 48,184,752

нужны ещё доводы?

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

18. "Размышление над проблемами формата Ogg"  +3 +/
Сообщение от gfh (??) on 18-Мрт-10, 18:35 
То что Avery Lee не осилил mkv формат - как то не очень отзывается на его репутации.

PS. Для меня VD стал неактуален после появления avidemux'а

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

19. "Размышление над проблемами формата Ogg"  +/
Сообщение от аноним on 18-Мрт-10, 18:44 
>Для меня VD стал неактуален после появления avidemux'а

может подскажете, где в videmux задаются теги

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

20. "Размышление над проблемами формата Ogg"  +5 +/
Сообщение от VyacheslavS on 18-Мрт-10, 18:49 
mkvmerge - не осилили?
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

27. "Размышление над проблемами формата Ogg"  +2 +/
Сообщение от name (??) on 18-Мрт-10, 20:51 
а про virtualdubmod(который работает с мкв) не слышали?
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

2. "Размышление над проблемами формата Ogg"  –3 +/
Сообщение от Vitto74 email(ok) on 18-Мрт-10, 16:54 
OGG был сделан для аудио и в этом плане он очень хорош, а с вдео подкачал не только OGG, но и Theora.
Будем надеяться, что появится свободный формат видео и контейнер для него, не уступающий H.264.
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

8. "Размышление над проблемами формата Ogg"  +3 +/
Сообщение от аноним on 18-Мрт-10, 17:48 
> контейнер для него, не уступающий H.264.

H.264 - не контейнер.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

26. "Размышление над проблемами формата Ogg"  +1 +/
Сообщение от Vitto74 email(ok) on 18-Мрт-10, 20:50 
>> контейнер для него, не уступающий H.264.
>
>H.264 - не контейнер.

Я не верно выразился. Я имел в виду, что надеюсь на создание формата, не уступающего H.264

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

24. "Размышление над проблемами формата Ogg"  +/
Сообщение от iZEN (ok) on 18-Мрт-10, 19:37 
Вместо OGG все нормальные люди пользуются AAC. Я, например, кодирую трэки Audio CD в M4A и спокойно прослушиваю их на телефоне. На настольном компьютере использую кодеки faac/faad2.
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

28. "Размышление над проблемами формата Ogg"  –1 +/
Сообщение от h31 (ok) on 18-Мрт-10, 20:55 
Faac просто ужасен. По качеству сравнимо с Lame. Какой тогда толк от AAC, если можно закодировать с тем же качеством в MP3, который читается везде?
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

42. "Размышление над проблемами формата Ogg"  +/
Сообщение от iZEN (ok) on 19-Мрт-10, 00:23 
FAAC для меня нормален. Кодирую WAV в AAC (контейнер M4A) с битрейтом VBR от 150 до 320kbps и оптимизацией (ключ -s).

В MP3 и в OGG/Vorbis на низких битрейтах я отчётливо различаю металлический звон, кодированная музыка становится какая-то искусственная "машинная" — в AAC такого нет.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

47. "Размышление над проблемами формата Ogg"  –1 +/
Сообщение от pavlinux (ok) on 19-Мрт-10, 03:59 
>FAAC для меня нормален. Кодирую WAV в AAC (контейнер M4A) с битрейтом
>VBR от 150 до 320kbps и оптимизацией (ключ -s).
>
>В MP3 и в OGG/Vorbis на низких битрейтах я отчётливо различаю металлический
>звон, кодированная музыка становится какая-то искусственная "машинная" — в AAC такого
>нет.

Врубай какой нить SACD Музикал Фиделити с усилком Raysonic с пирделками Paradigm Signature
и тебе скрипки Страдивари выпущенные до 1700 года покажутся говном :)


Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

89. "Размышление над проблемами формата Ogg"  +/
Сообщение от Keeper (??) on 21-Мрт-10, 11:07 
FLAC - наше всё.
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

30. "Размышление над проблемами формата Ogg"  +/
Сообщение от Tav (ok) on 18-Мрт-10, 21:21 
Вместо контейнера вы используете кодек?
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

43. "Размышление над проблемами формата Ogg"  +/
Сообщение от iZEN (ok) on 19-Мрт-10, 00:24 
OGG -> OGG/Vorbis
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

57. "Размышление над проблемами формата Ogg"  +/
Сообщение от korrado on 19-Мрт-10, 11:41 
OGG и Theora -  не в одной ли корзине сидят?


Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

4. "Размышление над проблемами формата Ogg"  +/
Сообщение от Антоним email on 18-Мрт-10, 17:13 
Зато звук можно аж 256 каналов в ogg завернуть =) Ведь был-же у Монти проект OGG2, только чего-то не пилят его больше. Сорцы в транке два года назад правились.
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

5. "Размышление над проблемами формата Ogg"  +/
Сообщение от jura12 (ok) on 18-Мрт-10, 17:17 
какие проблемы? взяли да и переделали.
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

11. "Размышление над проблемами формата Ogg"  +/
Сообщение от аноним on 18-Мрт-10, 18:07 
>какие проблемы? взяли да и переделали

а финансировать кто будет

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

13. "Размышление над проблемами формата Ogg"  +1 +/
Сообщение от anonimus on 18-Мрт-10, 18:16 
тот, кто и до этого финансировал...
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

14. "Размышление над проблемами формата Ogg"  +/
Сообщение от polymorphm1 (ok) on 18-Мрт-10, 18:19 
а чем ЗВУК отличается от ВИДИО?

чтото так и не понял....

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

15. "Размышление над проблемами формата Ogg"  +2 +/
Сообщение от Аноним (??) on 18-Мрт-10, 18:22 
>а чем ЗВУК отличается от ВИДИО?
>
>чтото так и не понял....

Данных меньше и при видео появляются две субстанции, которые нужно синхронизировать, звук + видео.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

17. "Размышление над проблемами формата Ogg"  +8 +/
Сообщение от Кэп on 18-Мрт-10, 18:34 
Звук ты слушаешь ушами, видио - смотришь глазами
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

49. "Размышление над проблемами формата Ogg"  +/
Сообщение от pavlinux (ok) on 19-Мрт-10, 04:11 
>Звук ты слушаешь ушами, видио - смотришь глазами

Можно наоборот сделать, только долго учится придется...
Хотя, звукоинженеры замечательно синусойды АЧХ слушают.
Бум - Большая широкая горка, Тыц - несколько маленьких, тыц-тыц-тыц - гармошка :)  

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

53. "Размышление над проблемами формата Ogg"  +/
Сообщение от koblin (ok) on 19-Мрт-10, 09:43 
я при настройке гитары тоже синусоиды вижу =))
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

54. "Размышление над проблемами формата Ogg"  +/
Сообщение от azure (ok) on 19-Мрт-10, 10:49 
У вас либо видения либо двойка по математике. Гитара не дает синусоиду.
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

91. "Размышление над проблемами формата Ogg"  +/
Сообщение от koblin (ok) on 21-Мрт-10, 11:40 
не нервничайте, про синусоиду было упрощение
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

87. "Размышление над проблемами формата Ogg"  +/
Сообщение от Aesthetus Animus (??) on 21-Мрт-10, 05:21 
Более того, дирижеры порою воспринимают звук через ощущения цвета: в результате симфония видится как некоторая картина.
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

48. "Размышление над проблемами формата Ogg"  +/
Сообщение от pavlinux (ok) on 19-Мрт-10, 04:07 
>а чем ЗВУК отличается от ВИДИО?
>чтото так и не понял....

Звук есть везде, видео как-такого вообще нет.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

21. "Размышление над проблемами формата Ogg"  +/
Сообщение от oneonfire email on 18-Мрт-10, 19:05 
Ничего не идеально в нашем мире, но стремиться к этому нужно)
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

22. "Размышление над проблемами формата Ogg"  +/
Сообщение от Анон on 18-Мрт-10, 19:07 
Только это, ошибочка в переводе, latency - эт время ожидания и чем оно меньше, тем лучше.
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

23. "Размышление над проблемами формата Ogg"  –1 +/
Сообщение от iZEN (ok) on 18-Мрт-10, 19:33 
>Задержка на стороне отправителя возникает из-за того что заголовок страницы данных в Ogg зависит от содержимого страницы, т.е. отображение и передача страниц осуществляется только блоками - пока весь блок данных не будет получен, невозможно рассчитать передаваемую в заголовке контрольную сумму и размер страницы, что приводит к задержке из-за лишней буферизации.

Это напомнило мне строки в C/C++: пока не просканируешь ВСЮ строку от начала до завершающего нуля, не узнаешь её длину. Сильно, сильно. :))

То ли дело в Pascal и Java — длина строки заранее известна и её не нужно вычислять!

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

31. "Размышление над проблемами формата Ogg"  +/
Сообщение от Unixoid_потому_что_кривые_руки_писали_этот_модуль email(ok) on 18-Мрт-10, 21:26 
Думаете, именно из-за этого Java быстрее, чем C/C++ ?
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

41. "Размышление над проблемами формата Ogg"  +/
Сообщение от XoRe (ok) on 19-Мрт-10, 00:02 
>Думаете, именно из-за этого Java быстрее, чем C/C++ ?

Да он сарказмирует )

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

44. "Размышление над проблемами формата Ogg"  +/
Сообщение от iZEN (ok) on 19-Мрт-10, 00:29 
>Думаете, именно из-за этого Java быстрее, чем C/C++ ?

Java не быстрее C/C++, так как JVM написана на C/C++. Код на Java, работающий со строками, выполняется гораздо быстрее, чем код, написанный на C/C++.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

45. "Размышление над проблемами формата Ogg"  +/
Сообщение от Aesthetus Animus (ok) on 19-Мрт-10, 01:03 
> Код на Java, работающий со строками, выполняется гораздо быстрее, чем код, написанный на C/C++.

Хотите сравнить? Давайте, я напишу на Си тот код по работе со строками, который у Вас, будучи реализованым на Java, работает "гораздо быстрее"? А потом посмотрим, насколько хороша Ваша Java.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

46. "Размышление над проблемами формата Ogg"  +/
Сообщение от iZEN (ok) on 19-Мрт-10, 02:04 
"Маша" + "мыла" + "раму!" и так мульён раз. Спорим, что на Java быстрее?
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

62. "Размышление над проблемами формата Ogg"  +/
Сообщение от coder on 19-Мрт-10, 18:23 
Проверяйте... и больше не пишите глупостей
#include <stdio.h>
#include <string.h>
int main (void)
{
    char string[0x100];
    for (int cnt = 1000000; cnt > 0; cnt--)
        stpcpy (stpcpy (stpcpy (string, "Маша"), "мыла"), "раму!");
    printf ("%s\n", string);
}
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

63. "Размышление над проблемами формата Ogg"  +/
Сообщение от Владимир (??) on 19-Мрт-10, 19:42 
Может, strcat() вместо strcpy()?
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

64. "Размышление над проблемами формата Ogg"  –1 +/
Сообщение от iZEN (ok) on 19-Мрт-10, 21:06 
>[оверквотинг удален]
>#include <stdio.h>
>#include <string.h>
>int main (void)
>{
>    char string[0x100];
>    for (int cnt = 1000000; cnt > 0; cnt--)
>        stpcpy (stpcpy (stpcpy (string,
>"Маша"), "мыла"), "раму!");
>    printf ("%s\n", string);
>}

% g++ -o StrBench StrBench.c
% ./StrBench
Машамылараму!

И это всё?!
Научись сначала правильно писать программы.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

65. "Размышление над проблемами формата Ogg"  +/
Сообщение от iZEN (ok) on 19-Мрт-10, 21:51 
>> Код на Java, работающий со строками, выполняется гораздо быстрее, чем код, написанный на C/C++.
>
>Хотите сравнить? Давайте, я напишу на Си тот код по работе со
>строками, который у Вас, будучи реализованым на Java, работает "гораздо быстрее"?
>А потом посмотрим, насколько хороша Ваша Java.

Напишите хотябы для ста тысяч итераций конкатенаций строк:
public class StrBench {
    public static void main(String[] arg) {
        String a = "Маша", b = "мыла", c = "раму!", d = "";
        long begin = System.currentTimeMillis();
        for (int cnt = 100000; cnt > 0; cnt--)
            d += a + b + c;
        long end = System.currentTimeMillis();
        System.out.printf("Результат: %.80s за %d мс.", d, (end - begin));
    }
}


Результат: Машамылараму!Машамылараму!Машамылараму!Машамылараму!Машамылараму!Машамылараму!Ма за 129634 мс.

— получен на AMD Phenom || 810. Запускал несколько раз — время выполнения теста от 126 до 130 секунд.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

66. "Размышление над проблемами формата Ogg"  +/
Сообщение от coder on 20-Мрт-10, 00:18 
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/time.h>
int main (void)  
{
    const char *a = "Маша", *b = "мыла", *c = "раму!";
    const int d = 100000;
    char *string = (char*) malloc (d * (strlen (a) + strlen (b) + strlen (c)));
    char *ptr = string;
    struct timeval start, end;
    gettimeofday(&start, NULL);
    for (int cnt = d; cnt > 0; cnt--)  
        ptr = stpcpy (stpcpy (stpcpy (ptr, a), b), c);
    gettimeofday(&end, NULL);
    printf ("Результат: %.50s за %ld мс.\n", string, \
        (end.tv_sec - start.tv_sec) * 1000 + (end.tv_usec - start.tv_usec) / 1000);
    free (string);
}
$ gcc -std=gnu99 -O1 add.c && ./a.out
Результат: Машамылараму!Машамылараму! за 2 мс.
$ uname -p
Intel(R) Core(TM)2 Duo CPU P7350 @ 2.00GHz
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

67. "Размышление над проблемами формата Ogg"  +/
Сообщение от iZEN (ok) on 20-Мрт-10, 01:56 
>[оверквотинг удален]
>    printf ("Результат: %.50s за %ld мс.\n", string, \
>
>        (end.tv_sec - start.tv_sec) *
>1000 + (end.tv_usec - start.tv_usec) / 1000);
>    free (string);
>}
>$ gcc -std=gnu99 -O1 add.c && ./a.out
>Результат: Машамылараму!Машамылараму! за 2 мс.
>$ uname -p
>Intel(R) Core(TM)2 Duo CPU P7350 @ 2.00GHz

Хитро-хитро. :)

Пробовал компилировать двумя способами:
1. gcc -std=gnu99 -O1 add.c
и
2. cc -std=c99 -o add add.c
В первом случае пример выполняется за 3 миллисекунды, во втором — за 17 миллисекунд. Откуда такая разница?

Сто миллионов итераций за две или (в зависимости от способа компиляции) шесть секунд. Круто!

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

79. "Размышление над проблемами формата Ogg"  +/
Сообщение от Aleksey Salow email(ok) on 20-Мрт-10, 12:47 
> char *string = (char*) malloc (d * (strlen (a) + strlen (b) + strlen (c)));

И привет buffer overflow.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

82. "Размышление над проблемами формата Ogg"  +/
Сообщение от coder on 20-Мрт-10, 21:16 
Молодец! Внимателен! При редактировании "+1" случайно удалил, а исправить здесь не могу.
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

94. "Размышление над проблемами формата Ogg"  +/
Сообщение от qpq (ok) on 22-Мрт-10, 12:51 
как бы то ни было, наглядная демонстрация проблем языков более низкого уровня
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

90. "Размышление над проблемами формата Ogg"  +1 +/
Сообщение от coder on 21-Мрт-10, 11:15 
Быстрее уже не бывает...
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/time.h>
int main (void)
{
    const char *a = "Маша", *b = "мыла", *c = "раму!";
    const int count = 1e5;
    const int strlength = count * (strlen (a) + strlen (b) + strlen (c));
    char *string = (char*) malloc (strlength + 1);
    if (!string)
        return 1;
    char *ptrcur = string, *ptrstop = string + strlength;
    struct timeval begin, end;
    gettimeofday(&begin, NULL);
    while (ptrcur < ptrstop)
        ptrcur = stpcpy (stpcpy (stpcpy (ptrcur, a), b), c);
    gettimeofday(&end, NULL);
    long elapsed_ms = (end.tv_sec - begin.tv_sec) * 1000 + (end.tv_usec - begin.tv_usec) / 1000;
    printf ("Результат: %.50s за %ld мс.\n", string, elapsed_ms);
    free (string);
    return 0;
}
$ uname -p
Intel(R) Core(TM)2 Duo CPU P7350 @ 2.00GHz
$ gcc -O1 add.c && ./a.out
Результат: Машамылараму!Машамылараму! за 1 мс.
gcc -O0 add.c && ./a.out
Результат: Машамылараму!Машамылараму! за 6 мс.
При -O1 цикл компилируется в набор инструкций
        movabsq $-5705910293682414384, %rdi
        movabsq $-5705854223505048368, %rsi
        movabsq $-8948163380102790959, %rcx
.L5:    movq    %rdi, (%rax)
        movq    %rsi, 8(%rax)
        leaq    16(%rax), %rdx
        movq    %rcx, (%rdx)
        movw    $33, 8(%rdx)
        addq    $25, %rax
        cmpq    %rax, %rbx
        ja      .L5
Быстрее уже не бывает...
Отсюда вывод: чем ниже уровень ЯП, тем выше скорость программы при прочих равных условиях.
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

68. "Размышление над проблемами формата Ogg"  +1 +/
Сообщение от qpq (ok) on 20-Мрт-10, 02:30 
не позорили бы Java что ли!
вот так бы хотя бы написали:

public class StrBench2
{
    public static void main(String[] arg)
    {
        final String a = "Маша", b = "мыла", c = "раму!";
        final StringBuilder sb = new StringBuilder();
        
        long begin = System.currentTimeMillis();
        
        for (int cnt = 100000; cnt > 0; cnt--) {
            sb.append(a).append(b).append(c);
        }
        
        long end = System.currentTimeMillis();
        System.out.printf("Результат: %.80s за %d мс.", sb, (end - begin));
    }
}

а еще лучше вот так:

public class StrBench3
{
    public static void main(String[] arg)
    {
        final String a = "Маша", b = "мыла", c = "раму!";
        final StringBuilder sb = new StringBuilder((a.length() + b.length() + c.length()) * 100000);
        
        long begin = System.currentTimeMillis();
        
        for (int cnt = 100000; cnt > 0; cnt--) {
            sb.append(a).append(b).append(c);
        }
        
        long end = System.currentTimeMillis();
        System.out.printf("Результат: %.80s за %d мс.", sb, (end - begin));
    }
}

впрочем, я все равно за C++

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

69. "Размышление над проблемами формата Ogg"  +/
Сообщение от iZEN (ok) on 20-Мрт-10, 02:50 
>не позорили бы Java что ли!
>вот так бы хотя бы написали:

Давайте Вы не будете указывать, что мне делать.

Строковую конкатенацию оптимизировали на уровне компилятора ещё в Java2 1.4.x — там вместо конкатенации используется StringBuffer. А в Java 5.0 его "заменили" на StringBuilder. Если декомпилировать мой класс, то можно увидеть StringBuilder.append(...); вместо "сложения" строк.

Привет!

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

70. "Размышление над проблемами формата Ogg"  +/
Сообщение от qpq (ok) on 20-Мрт-10, 02:53 
а Вы попробуйте откомпилировать и запустить предоставленные мной примеры, ну пожалуйста, ради интереса ;)
...

я даже могу объяснить почему, но Вы ведь не спросите :)

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

71. "Размышление над проблемами формата Ogg"  +/
Сообщение от iZEN (ok) on 20-Мрт-10, 02:58 
>а Вы попробуйте откомпилировать и запустить предоставленные мной примеры, ну пожалуйста, ради
>интереса ;)

StrBench2
Результат: Машамылараму!Машамылараму!Машамылараму!Машамылараму!Машамылараму!Машамылараму!Ма за 48 мс.

StrBench3
Результат: Машамылараму!Машамылараму!Машамылараму!Машамылараму!Машамылараму!Машамылараму!Ма за 41 мс.

>я даже могу объяснить почему, но Вы ведь не спросите :)

Я сам знаю. Вы заранее выделяете память под буфер StringBuilder, а у меня она выделяется динамически во время выполнения теста.


Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

72. "Размышление над проблемами формата Ogg"  +/
Сообщение от qpq (ok) on 20-Мрт-10, 03:02 
это только в 3-м тесте выделяется заранее, во втором буфер расширяется динамически, выигрышь в 7 мс, причины охрененной разницы с Вашим тестом несколько иные, но хотя бы Java от полного позора спасли и то ладно
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

73. "Размышление над проблемами формата Ogg"  +/
Сообщение от iZEN (ok) on 20-Мрт-10, 03:20 
>это только в 3-м тесте выделяется заранее, во втором буфер расширяется динамически,
>выигрышь в 7 мс, причины охрененной разницы с Вашим тестом несколько
>иные, но хотя бы Java от полного позора спасли и то
>ладно

Что вы бабушку лохматите?
И в первом и во втором ваших тестах ЗАРАНЕЕ распределяется память под StringBuilder (в первом случае "как JVM на душу положит", во втором — сразу вся необходимая).
JIT-компилятор ЗАРАНЕЕ (перед тем, как проанализировать цикл for) осведомлён о распределении памяти под объекты и делает полную оптимизацию выполнения и в первом и во втором случае.

В моём случае переменная d полагается ТОЛЬКО на динамическую оптимизацию вычислений. StringBuilder создаётся внутри цикла, а не вне его; в конце КАЖДОЙ итерации цикла выполняется StringBuilder.toString для строковой переменной d, чего в вашем коде нет. Отсюда и отставание моего кода от вашего в три раза.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

74. "Размышление над проблемами формата Ogg"  +/
Сообщение от qpq (ok) on 20-Мрт-10, 03:40 
130 с. vs 40 мс. по Вашему всего в 3 раза? пожалуй с Вами не стоит спорить, впрочем причину Вы уже озвучили - неспособность Java компилятора (JIT, кстати, здесь вообще ни при чем) оптимизировать распределенные конкатенации строк, чего конечно же компилятор и не обязан делать

на счет изначального размера StringBuilder'а, то он определяется не тем как JVM на душу положит, а (по крайней мере в случае JRE от Sun) значением буфера в констуре по умолчанию, а он там, если мне не изменяет память равен 16, пойду проверю, ну да, так и есть (все же заставили меня запустить Eclipse), и расширяется по мере надобности по алгоритму capacity = (capacity + 1) * 2

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

76. "Размышление над проблемами формата Ogg"  +2 +/
Сообщение от qpq (ok) on 20-Мрт-10, 04:59 
> от 6 раз и более...

лучше спать идите, а то поздно уже :)

130 с. / 40 мс. ~ 3250 раз - вот такой оптимизации я добился в своем коде по сравнению с Вашим, вынеся создание StringBuilder'а за пределы цикла, а не полагаясь на оптимизацию компилятора

JIT компилятор - тот что в Runtime - конечно же отличная вещь, никто не спорит, но он оптимизирует совершенно другие вещи и не может повлиять на явные просчеты в логике программы


> Вы кто по профессии и роду деятельности, если не секрет?

это не изменит результатов тестов и тех явных промахов в Ваших рассуждениях о Java и ее возможностях оптимизации, которые мне не особо охота обсуждать

просто не хотелось, чтобы Java так сильно дескридитировали синтетическими тестами, где код на С++ выполняется за милисекунды, а программе реализованной на Java для этого якобы требуется почти 2 минуты

я просто мимо проходил

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

77. "Размышление над проблемами формата Ogg"  +/
Сообщение от iZEN (ok) on 20-Мрт-10, 05:28 
>> от 6 раз и более...
>
>лучше спать идите, а то поздно уже :)
>
>130 с. / 40 мс. ~ 3250 раз - вот такой оптимизации

Да. Надо поспать. :)))

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

78. "Размышление над проблемами формата Ogg"  +/
Сообщение от iZEN (ok) on 20-Мрт-10, 05:31 
>>это только в 3-м тесте выделяется заранее, во втором буфер расширяется динамически,
>>выигрышь в 7 мс, причины охрененной разницы с Вашим тестом несколько
>Отсюда и отставание моего кода от вашего в три раза.

В три тыщи раз.


Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

83. "Размышление над проблемами формата Ogg"  +/
Сообщение от Aesthetus Animus (??) on 20-Мрт-10, 22:09 
> Напишите хотябы для ста тысяч итераций конкатенаций строк...

У меня Ваш код работает несколько медленнее:

Результат: Машамылараму!Машамылараму!Машамылараму!Машамылараму!Машамылараму!Машамылараму!Ма за 271690 мс.

А вот код на плюсах:

#include <iostream>

extern "C"
{
  #include <sys/time.h>
}


int main(int argc, char** argv)
{
  std::string s1 = "Мама", s2 = "мыла", s3 = "раму!";
  std::string cat;
  int count;
  int elapsed_ms;

  struct timeval begin, end;

  gettimeofday(&begin, NULL);

  count = 1e5;
  cat.reserve((s1.size() + s2.size() + s3.size()) * count);
  while (count--)
    cat.append(s1).append(s2).append(s3);

  gettimeofday(&end, NULL);

  elapsed_ms =  (end.tv_sec - begin.tv_sec) * 1000 + (end.tv_usec - begin.tv_usec) / 1000;

  std::cerr << "Elapsed time: " << elapsed_ms << std::endl;
  std::cout << cat << std::endl;

  return 0;
}

Компилил без оптимизации, вот так:
gcc -g -O0 -Wall -pedantic   -o main.o -c main.cpp
gcc -lstdc++ -g -Wl,-Map=string-test.map    -o string-test  main.o

В общем, почуствуйте разницу:
$ time ./string-test > output
Elapsed time: 8

real    0m0.022s
user    0m0.000s
sys    0m0.022s

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

84. "Размышление над проблемами формата Ogg"  +/
Сообщение от Интересующийся (??) on 21-Мрт-10, 00:07 
#include <iostream>
#include <string>
#include <sys/time.h>
using namespace std;

int main(int argc,char* argv[])
{
  const int MAX_ITERS = 100000;
  string s1("Маша"),s2("мыла"),s3("раму!");
  struct timeval start,end;
gettimeofday(&start,NULL);
  for(size_t i = 0; i < MAX_ITERS; ++i){
    string s(s1+" "+s2+" "+s3);
cout << s ;
  }
  gettimeofday(&end,NULL);
cout << (end.tv_sec - start.tv_sec) << endl;    
  return 0;
}

Собирается g++ -O1 -o sstring sstring.cpp. Выполняется за 1с. Если MAX_ITERS увеличить на порядок, то за 7. Длина строка получается одной командой s1.
Система  Intel(R) Core(TM)2 Quad CPU    Q6600  @ 2.40GHz ,6 Gb Ram.
Сейчас буду гонять Ваш код.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

85. "Размышление над проблемами формата Ogg"  +/
Сообщение от Aleksey Salow email(ok) on 21-Мрт-10, 01:40 
>  for(size_t i = 0; i < MAX_ITERS; ++i){
>    string s(s1+" "+s2+" "+s3);
>cout << s ;

^^^^^^^^^^^^^^^^^^^^
>  }
>
>Собирается g++ -O1 -o sstring sstring.cpp. Выполняется за 1с. Если MAX_ITERS увеличить
>на порядок, то за 7. Длина строка получается одной командой s1.

Патамуша вывод в цикле делают только идиоты. Если убрать cout << s то на C2D E6300 получается ~280ms

ловите .net/c# :)

using System;
using System.Diagnostics ;
using System.Text;

namespace StringPerformanceTest
{
    class Program
    {
        const int Iter = 100000 ;
        const string s1 = "Маша" ;
        const string s2 = "мыла" ;
        const string s3 = "раму!" ;
        
        static void Main ()
        {
            var result = new StringBuilder ((s1.Length + s2.Length + s3.Length) * Iter) ;
            
            var watch = Stopwatch.StartNew () ;
            for (var i = 0; i < Iter; i++)
                result.Append (s1).Append (s2).Append (s3) ;
            watch.Stop () ;

            Console.WriteLine ("String length: {0}; Elapsed time: {1}ms", result.Length, watch.ElapsedMilliseconds) ;
        }
    }
}

C2Q Q6600/Windows: String length: 1300000; Elapsed time: 10ms
C2D E6300/FreeBSD/Mono JIT compiler version 2.4.2.3: String length: 1300000; Elapsed time: 63ms

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

86. "Размышление над проблемами формата Ogg"  +/
Сообщение от Aleksey Salow email(ok) on 21-Мрт-10, 01:46 
>C2Q Q6600/Windows: String length: 1300000; Elapsed time: 10ms
>C2D E6300/FreeBSD/Mono JIT compiler version 2.4.2.3: String length: 1300000; Elapsed time: 63ms

Кстати, если сделать динамическое выделение буфера, то получаются следующие результаты:
Win: String length: 1300000; Elapsed time: 37ms
Mono: String length: 1300000; Elapsed time: 98ms

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

88. "Размышление над проблемами формата Ogg"  +/
Сообщение от coder on 21-Мрт-10, 10:44 
И какая связь этого с "Размышление над проблемами формата Ogg"? :)
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

92. "Размышление над проблемами формата Ogg"  +/
Сообщение от Аноним (??) on 21-Мрт-10, 15:50 
>И какая связь этого с "Размышление над проблемами формата Ogg"? :)

Никакой. Зато прямое подтверждение стратегии M$: win всегда будет значительно быстрее mono.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

93. "Размышление над проблемами формата Ogg"  +/
Сообщение от Интересующийся (??) on 21-Мрт-10, 16:27 

Исправил. Без cout получается:
real    0m0.010s
user    0m0.008s
sys     0m0.000s
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

95. "Размышление над проблемами формата Ogg"  +/
Сообщение от iZEN (ok) on 22-Мрт-10, 16:36 
>[оверквотинг удален]
>
>            
>Console.WriteLine ("String length: {0}; Elapsed time: {1}ms", result.Length, watch.ElapsedMilliseconds) ;
>        }
>    }
>}
>
>C2Q Q6600/Windows: String length: 1300000; Elapsed time: 10ms
>C2D E6300/FreeBSD/Mono JIT compiler version 2.4.2.3: String length: 1300000; Elapsed time: 63ms
>

Хех, у меня на Java ~60 мс для 13000000 символов (в десять раз больше, чем у вас):
public class StrBench4 {
    public static void main(String[] arg) {
        final int TEST_COUNT = 10;
        final int COUNT = 1000000;
        final String a = "Маша", b = "мыла", c = "раму!";
        for (int tests = 1; tests <= TEST_COUNT; tests++) {
            StringBuilder sb = new StringBuilder((a.length() + b.length() + c.length()) * COUNT);
            long begin = System.currentTimeMillis();
            for (int cnt = COUNT; --cnt >= 0;) {
                sb.append(a).append(b).append(c);
            }
            long end = System.currentTimeMillis();
            System.out.printf("Тест №%d\nРезультат: %.78s — длина строки %s символов\nВремя выполнения  %d мс.\n", tests, sb, sb.length(), (end - begin));
        }
    }
}
Вывод:
Тест №1
Результат: Машамылараму!Машамылараму!Машамылараму!Машамылараму!Машамылараму!Машамылараму! — длина строки 13000000 символов
Время выполнения  84 мс.
Тест №2
Результат: Машамылараму!Машамылараму!Машамылараму!Машамылараму!Машамылараму!Машамылараму! — длина строки 13000000 символов
Время выполнения  74 мс.
Тест №3
Результат: Машамылараму!Машамылараму!Машамылараму!Машамылараму!Машамылараму!Машамылараму! — длина строки 13000000 символов
Время выполнения  42 мс.
Тест №4
Результат: Машамылараму!Машамылараму!Машамылараму!Машамылараму!Машамылараму!Машамылараму! — длина строки 13000000 символов
Время выполнения  42 мс.
Тест №5
Результат: Машамылараму!Машамылараму!Машамылараму!Машамылараму!Машамылараму!Машамылараму! — длина строки 13000000 символов
Время выполнения  42 мс.
Тест №6
Результат: Машамылараму!Машамылараму!Машамылараму!Машамылараму!Машамылараму!Машамылараму! — длина строки 13000000 символов
Время выполнения  43 мс.
Тест №7
Результат: Машамылараму!Машамылараму!Машамылараму!Машамылараму!Машамылараму!Машамылараму! — длина строки 13000000 символов
Время выполнения  42 мс.
Тест №8
Результат: Машамылараму!Машамылараму!Машамылараму!Машамылараму!Машамылараму!Машамылараму! — длина строки 13000000 символов
Время выполнения  42 мс.
Тест №9
Результат: Машамылараму!Машамылараму!Машамылараму!Машамылараму!Машамылараму!Машамылараму! — длина строки 13000000 символов
Время выполнения  42 мс.
Тест №10
Результат: Машамылараму!Машамылараму!Машамылараму!Машамылараму!Машамылараму!Машамылараму! — длина строки 13000000 символов
Время выполнения  42 мс.

Эта ваша Mono сливает Яве в десять раз!

$ java -version
openjdk version "1.6.0"
OpenJDK Runtime Environment (build 1.6.0-b17)
OpenJDK 64-Bit Server VM (build 14.0-b16, mixed mode)
% uname -rsm
FreeBSD 8.0-STABLE amd64
% dmesg | grep AMD
CPU: AMD Phenom(tm) II X4 810 Processor (2594.47-MHz K8-class CPU)
  Origin = "AuthenticAMD"  Id = 0x100f42  Stepping = 2
  AMD Features=0xee500800<SYSCALL,NX,MMX+,FFXSR,Page1GB,RDTSCP,LM,3DNow!+,3DNow!

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

52. "Размышление над проблемами формата Ogg"  +/
Сообщение от Аноним (??) on 19-Мрт-10, 09:42 
>Java не быстрее C/C++, так как JVM написана на C/C++.

Не факт, что байткод интерпретируется JVM. Язык может приблизится по скорости к C/C++, если он на лету преобразует байткод в машинные инструкции. JIT-компиляция великая вещь.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

56. "Размышление над проблемами формата Ogg"  +/
Сообщение от sluge (ok) on 19-Мрт-10, 11:12 
скажу по секрету gcc умеет из java делать бинарный код который работает без всякой JVM и прочих извращений
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

60. "Размышление над проблемами формата Ogg"  +/
Сообщение от Онаним on 19-Мрт-10, 15:00 
>>Думаете, именно из-за этого Java быстрее, чем C/C++ ?
>
>Java не быстрее C/C++, так как JVM написана на C/C++.

А вы знаете, что реализация Python, написанная на самом Python, говорят, в Разы быстрее исходной, написанной на C++? А ещё когда-то здесь же на опеннете пролетала новость где сравнивались разными бенчмарками разные виртуальные машины (VirtualBox, VMWare, и т.п.) и физическая, и по некоторым статьям какие-то виртуальная машина обгоняли физическую, на которой сами работали.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

61. "Размышление над проблемами формата Ogg"  +/
Сообщение от pavel_simple (ok) on 19-Мрт-10, 15:58 
>>>Думаете, именно из-за этого Java быстрее, чем C/C++ ?
>>
>>Java не быстрее C/C++, так как JVM написана на C/C++.
>
>А вы знаете, что реализация Python, написанная на самом Python, говорят, в
>Разы быстрее исходной, написанной на C++? А ещё когда-то здесь же
>на опеннете пролетала новость где сравнивались разными бенчмарками разные виртуальные машины
>(VirtualBox, VMWare, и т.п.) и физическая, и по некоторым статьям какие-то
>виртуальная машина обгоняли физическую, на которой сами работали.

нет -- не читайте до обеда....

эти люди ещё жалуются .... мама дорогая -- Кругом они! (C) Опеннет.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

32. "Размышление над проблемами формата Ogg"  +/
Сообщение от Aesthetus Animus (ok) on 18-Мрт-10, 21:50 
> Это напомнило мне строки в C/C++...

А плюсы то Вы не знаете...
http://www.cplusplus.com/reference/string/string/length/

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

36. "Размышление над проблемами формата Ogg"  +/
Сообщение от slayer email(??) on 18-Мрт-10, 22:04 
А как эта функция внутри работает, не задумывались?
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

40. "Размышление над проблемами формата Ogg"  +/
Сообщение от Aesthetus Animus (ok) on 18-Мрт-10, 22:54 
Отройте исходники, да посмотрите наконец сами!
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

34. "Размышление над проблемами формата Ogg"  +/
Сообщение от Аноним (??) on 18-Мрт-10, 22:00 
>То ли дело в Pascal и Java — длина строки заранее известна и её не нужно вычислять!

И откуда же, по-вашему, они берут длину?

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

37. "Размышление над проблемами формата Ogg"  +2 +/
Сообщение от uZver (??) on 18-Мрт-10, 22:19 
>>То ли дело в Pascal и Java — длина строки заранее известна и её не нужно вычислять!
>
>И откуда же, по-вашему, они берут длину?

считают заранее в java String - immutable

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

38. "Размышление над проблемами формата Ogg"  +/
Сообщение от Аноним (??) on 18-Мрт-10, 22:26 
>>То ли дело в Pascal и Java — длина строки заранее известна и её не нужно вычислять!
>
>И откуда же, по-вашему, они берут длину?

Вначале строки хранят размер.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

33. "Размышление над проблемами формата Ogg"  +/
Сообщение от Аноним (??) on 18-Мрт-10, 21:58 
А зачем вообще мешать все в кучу и вставлять в ogg видео?
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

35. "Размышление над проблемами формата Ogg"  +/
Сообщение от аноним on 18-Мрт-10, 22:03 
>А зачем вообще мешать все в кучу и вставлять в ogg видео?

есть другие предложения?

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

50. "Размышление над проблемами формата Ogg"  +1 +/
Сообщение от Алексей (??) on 19-Мрт-10, 05:18 
Оставить контейнер OGG для аудио (Vorbis), и признать тот факт, что OGG как универсальный медиаконтейнер так и не состоялся.
Для видео же стоит использовать более подходящий контейнер - Matroska, и забить на попытки переделать OGG. Де факто сейчас всё именно так и есть.
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

59. "Размышление над проблемами формата Ogg"  +/
Сообщение от аноним on 19-Мрт-10, 14:12 
>Оставить контейнер OGG для аудио (Vorbis), и признать тот факт, что OGG как универсальный медиаконтейнер так и не состоялся. Для видео же стоит использовать более подходящий контейнер - Matroska, и забить на попытки переделать OGG. Де факто сейчас всё именно так и есть.

OGG и не разрабатывался для хранения всего на свете. хз почему решили именно этот контейнер всунуть в рекомендации. matroska/mp4+ h.264 + aac - гораздо лучший вариант, ставший стандартом де-факто

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

39. "Размышление над проблемами формата Ogg"  +/
Сообщение от Аноним (??) on 18-Мрт-10, 22:40 
>есть другие предложения?

Ну как? Создать отдельный контейнер для видео.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

51. "Размышление над проблемами формата Ogg"  +1 +/
Сообщение от gapsf2 (ok) on 19-Мрт-10, 06:56 
В целом  - почитайте FAQ - там говорится, что для целей аудио Ogg хорошо сделан,
а для аудио/видео есть Ogm, хотя MKV более гибкий.
Так что ничего страшного.

Из http://www.matroska.org/technical/guides/faq/index.html
Ogg
1. Designed for streaming.
2. Designed to hold Vorbis.
3. Well documented for above two purposes.
Ogm
1. Implementation of Ogg to hold video, other audio codecs, and a type of subtitle.
2. Implements Chapter support.
Matroska
1. Designed to hold any type of codec. (Audio, Video, Subtitle, etc)
2. Designed for editability.
3. Purposely flexible design.
4. Well documented portions, others in process.
5. Initial design is to support presentation container features such as Chapters, Tags, AudioGain, Menus, etc.
Will Matroska be streamable? Yes, but low bitrate streaming like streaming Vorbis, will always be better in Ogg. This is because their design is for different purposes.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Спонсоры:
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

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