Один из разработчиков проекта FFmpeg в статье "Ogg objections (http://hardwarebug.org/2010/03/03/ogg-objections/)" подробно рассказал о недостатках мультимедиа контейнера Ogg. Вывод в статье сделан неутешительный, свободность и независимость от патентов - это конечно хорошо, но с технической стороны формат не может конкурировать с аналогами и требует полной переработки. Изначально Ogg создан для работы с простейшими аудео-потоками, из чего следует его излишняя усложненность и нестандартность при работе с другими видами данных, например, при при инкапсуляции видео-потоков.
Основные недостатки Ogg:
- Излишнее расходование ресурсов при организации хранения привязанной к потоку служебной информации. Заголовок страницы данных имеет размер 27 байт, в то время как его без проблем можно было бы ужать до 12 байт. Большой объем лишних полей в заголовке страницы данных, приводит к увеличению размера итогового файла примерно на 1%, в то время как для формата MP4 этот показатель равен 0.0...URL:
Новость: http://www.opennet.me/opennews/art.shtml?num=25852
mkv - наше фсё!
btw для вашего всего нет нормальных редакторов
Вот только формат MKV настолько "развесист", что Avery Lee отказался его добавлять в свой VirtualBub. Приходится извращаться с AviSynth или DirectShow-фильтром.
Кто такой Avery Lee чтобы к его мнению прислушиваться?
Афтор Видовской рипалки/декодера/плющилки Virtualdub, меж прочим GPL-ная
>Кто такой Avery Lee чтобы к его мнению прислушиваться?http://sourceforge.net/projects/virtualdub/files/
Downloads virtualdub-win 48,184,752нужны ещё доводы?
То что Avery Lee не осилил mkv формат - как то не очень отзывается на его репутации.PS. Для меня VD стал неактуален после появления avidemux'а
>Для меня VD стал неактуален после появления avidemux'аможет подскажете, где в videmux задаются теги
mkvmerge - не осилили?
а про virtualdubmod(который работает с мкв) не слышали?
OGG был сделан для аудио и в этом плане он очень хорош, а с вдео подкачал не только OGG, но и Theora.
Будем надеяться, что появится свободный формат видео и контейнер для него, не уступающий H.264.
> контейнер для него, не уступающий H.264.H.264 - не контейнер.
>> контейнер для него, не уступающий H.264.
>
>H.264 - не контейнер.Я не верно выразился. Я имел в виду, что надеюсь на создание формата, не уступающего H.264
Вместо OGG все нормальные люди пользуются AAC. Я, например, кодирую трэки Audio CD в M4A и спокойно прослушиваю их на телефоне. На настольном компьютере использую кодеки faac/faad2.
Faac просто ужасен. По качеству сравнимо с Lame. Какой тогда толк от AAC, если можно закодировать с тем же качеством в MP3, который читается везде?
FAAC для меня нормален. Кодирую WAV в AAC (контейнер M4A) с битрейтом VBR от 150 до 320kbps и оптимизацией (ключ -s).В MP3 и в OGG/Vorbis на низких битрейтах я отчётливо различаю металлический звон, кодированная музыка становится какая-то искусственная "машинная" — в AAC такого нет.
>FAAC для меня нормален. Кодирую WAV в AAC (контейнер M4A) с битрейтом
>VBR от 150 до 320kbps и оптимизацией (ключ -s).
>
>В MP3 и в OGG/Vorbis на низких битрейтах я отчётливо различаю металлический
>звон, кодированная музыка становится какая-то искусственная "машинная" — в AAC такого
>нет.Врубай какой нить SACD Музикал Фиделити с усилком Raysonic с пирделками Paradigm Signature
и тебе скрипки Страдивари выпущенные до 1700 года покажутся говном :)
FLAC - наше всё.
Вместо контейнера вы используете кодек?
OGG -> OGG/Vorbis
OGG и Theora - не в одной ли корзине сидят?
Зато звук можно аж 256 каналов в ogg завернуть =) Ведь был-же у Монти проект OGG2, только чего-то не пилят его больше. Сорцы в транке два года назад правились.
какие проблемы? взяли да и переделали.
>какие проблемы? взяли да и переделалиа финансировать кто будет
тот, кто и до этого финансировал...
а чем ЗВУК отличается от ВИДИО?чтото так и не понял....
>а чем ЗВУК отличается от ВИДИО?
>
>чтото так и не понял....Данных меньше и при видео появляются две субстанции, которые нужно синхронизировать, звук + видео.
Звук ты слушаешь ушами, видио - смотришь глазами
>Звук ты слушаешь ушами, видио - смотришь глазамиМожно наоборот сделать, только долго учится придется...
Хотя, звукоинженеры замечательно синусойды АЧХ слушают.
Бум - Большая широкая горка, Тыц - несколько маленьких, тыц-тыц-тыц - гармошка :)
я при настройке гитары тоже синусоиды вижу =))
У вас либо видения либо двойка по математике. Гитара не дает синусоиду.
не нервничайте, про синусоиду было упрощение
Более того, дирижеры порою воспринимают звук через ощущения цвета: в результате симфония видится как некоторая картина.
>а чем ЗВУК отличается от ВИДИО?
>чтото так и не понял....Звук есть везде, видео как-такого вообще нет.
Ничего не идеально в нашем мире, но стремиться к этому нужно)
Только это, ошибочка в переводе, latency - эт время ожидания и чем оно меньше, тем лучше.
>Задержка на стороне отправителя возникает из-за того что заголовок страницы данных в Ogg зависит от содержимого страницы, т.е. отображение и передача страниц осуществляется только блоками - пока весь блок данных не будет получен, невозможно рассчитать передаваемую в заголовке контрольную сумму и размер страницы, что приводит к задержке из-за лишней буферизации.Это напомнило мне строки в C/C++: пока не просканируешь ВСЮ строку от начала до завершающего нуля, не узнаешь её длину. Сильно, сильно. :))
То ли дело в Pascal и Java — длина строки заранее известна и её не нужно вычислять!
Думаете, именно из-за этого Java быстрее, чем C/C++ ?
>Думаете, именно из-за этого Java быстрее, чем C/C++ ?Да он сарказмирует )
>Думаете, именно из-за этого Java быстрее, чем C/C++ ?Java не быстрее C/C++, так как JVM написана на C/C++. Код на Java, работающий со строками, выполняется гораздо быстрее, чем код, написанный на C/C++.
> Код на Java, работающий со строками, выполняется гораздо быстрее, чем код, написанный на C/C++.Хотите сравнить? Давайте, я напишу на Си тот код по работе со строками, который у Вас, будучи реализованым на Java, работает "гораздо быстрее"? А потом посмотрим, насколько хороша Ваша Java.
"Маша" + "мыла" + "раму!" и так мульён раз. Спорим, что на Java быстрее?
Проверяйте... и больше не пишите глупостей
#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);
}
Может, strcat() вместо strcpy()?
>[оверквотинг удален]
>#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
Машамылараму!И это всё?!
Научись сначала правильно писать программы.
>> Код на 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 секунд.
#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
>[оверквотинг удален]
> 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 миллисекунд. Откуда такая разница?Сто миллионов итераций за две или (в зависимости от способа компиляции) шесть секунд. Круто!
> char *string = (char*) malloc (d * (strlen (a) + strlen (b) + strlen (c)));И привет buffer overflow.
Молодец! Внимателен! При редактировании "+1" случайно удалил, а исправить здесь не могу.
как бы то ни было, наглядная демонстрация проблем языков более низкого уровня
Быстрее уже не бывает...
#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
Быстрее уже не бывает...
Отсюда вывод: чем ниже уровень ЯП, тем выше скорость программы при прочих равных условиях.
не позорили бы 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++
>не позорили бы Java что ли!
>вот так бы хотя бы написали:Давайте Вы не будете указывать, что мне делать.
Строковую конкатенацию оптимизировали на уровне компилятора ещё в Java2 1.4.x — там вместо конкатенации используется StringBuffer. А в Java 5.0 его "заменили" на StringBuilder. Если декомпилировать мой класс, то можно увидеть StringBuilder.append(...); вместо "сложения" строк.
Привет!
а Вы попробуйте откомпилировать и запустить предоставленные мной примеры, ну пожалуйста, ради интереса ;)
...я даже могу объяснить почему, но Вы ведь не спросите :)
>а Вы попробуйте откомпилировать и запустить предоставленные мной примеры, ну пожалуйста, ради
>интереса ;)StrBench2
Результат: Машамылараму!Машамылараму!Машамылараму!Машамылараму!Машамылараму!Машамылараму!Ма за 48 мс.StrBench3
Результат: Машамылараму!Машамылараму!Машамылараму!Машамылараму!Машамылараму!Машамылараму!Ма за 41 мс.>я даже могу объяснить почему, но Вы ведь не спросите :)
Я сам знаю. Вы заранее выделяете память под буфер StringBuilder, а у меня она выделяется динамически во время выполнения теста.
это только в 3-м тесте выделяется заранее, во втором буфер расширяется динамически, выигрышь в 7 мс, причины охрененной разницы с Вашим тестом несколько иные, но хотя бы Java от полного позора спасли и то ладно
>это только в 3-м тесте выделяется заранее, во втором буфер расширяется динамически,
>выигрышь в 7 мс, причины охрененной разницы с Вашим тестом несколько
>иные, но хотя бы Java от полного позора спасли и то
>ладноЧто вы бабушку лохматите?
И в первом и во втором ваших тестах ЗАРАНЕЕ распределяется память под StringBuilder (в первом случае "как JVM на душу положит", во втором — сразу вся необходимая).
JIT-компилятор ЗАРАНЕЕ (перед тем, как проанализировать цикл for) осведомлён о распределении памяти под объекты и делает полную оптимизацию выполнения и в первом и во втором случае.В моём случае переменная d полагается ТОЛЬКО на динамическую оптимизацию вычислений. StringBuilder создаётся внутри цикла, а не вне его; в конце КАЖДОЙ итерации цикла выполняется StringBuilder.toString для строковой переменной d, чего в вашем коде нет. Отсюда и отставание моего кода от вашего в три раза.
130 с. vs 40 мс. по Вашему всего в 3 раза? пожалуй с Вами не стоит спорить, впрочем причину Вы уже озвучили - неспособность Java компилятора (JIT, кстати, здесь вообще ни при чем) оптимизировать распределенные конкатенации строк, чего конечно же компилятор и не обязан делатьна счет изначального размера StringBuilder'а, то он определяется не тем как JVM на душу положит, а (по крайней мере в случае JRE от Sun) значением буфера в констуре по умолчанию, а он там, если мне не изменяет память равен 16, пойду проверю, ну да, так и есть (все же заставили меня запустить Eclipse), и расширяется по мере надобности по алгоритму capacity = (capacity + 1) * 2
> от 6 раз и более...лучше спать идите, а то поздно уже :)
130 с. / 40 мс. ~ 3250 раз - вот такой оптимизации я добился в своем коде по сравнению с Вашим, вынеся создание StringBuilder'а за пределы цикла, а не полагаясь на оптимизацию компилятора
JIT компилятор - тот что в Runtime - конечно же отличная вещь, никто не спорит, но он оптимизирует совершенно другие вещи и не может повлиять на явные просчеты в логике программы
> Вы кто по профессии и роду деятельности, если не секрет?это не изменит результатов тестов и тех явных промахов в Ваших рассуждениях о Java и ее возможностях оптимизации, которые мне не особо охота обсуждать
просто не хотелось, чтобы Java так сильно дескридитировали синтетическими тестами, где код на С++ выполняется за милисекунды, а программе реализованной на Java для этого якобы требуется почти 2 минуты
я просто мимо проходил
>> от 6 раз и более...
>
>лучше спать идите, а то поздно уже :)
>
>130 с. / 40 мс. ~ 3250 раз - вот такой оптимизацииДа. Надо поспать. :)))
>>это только в 3-м тесте выделяется заранее, во втором буфер расширяется динамически,
>>выигрышь в 7 мс, причины охрененной разницы с Вашим тестом несколько
>Отсюда и отставание моего кода от вашего в три раза.В три тыщи раз.
> Напишите хотябы для ста тысяч итераций конкатенаций строк...У меня Ваш код работает несколько медленнее:
Результат: Машамылараму!Машамылараму!Машамылараму!Машамылараму!Машамылараму!Машамылараму!Ма за 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: 8real 0m0.022s
user 0m0.000s
sys 0m0.022s
#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.
Сейчас буду гонять Ваш код.
> 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
>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
И какая связь этого с "Размышление над проблемами формата Ogg"? :)
>И какая связь этого с "Размышление над проблемами формата Ogg"? :)Никакой. Зато прямое подтверждение стратегии M$: win всегда будет значительно быстрее mono.
Исправил. Без cout получается:
real 0m0.010s
user 0m0.008s
sys 0m0.000s
>[оверквотинг удален]
>
>
>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!
>Java не быстрее C/C++, так как JVM написана на C/C++.Не факт, что байткод интерпретируется JVM. Язык может приблизится по скорости к C/C++, если он на лету преобразует байткод в машинные инструкции. JIT-компиляция великая вещь.
скажу по секрету gcc умеет из java делать бинарный код который работает без всякой JVM и прочих извращений
>>Думаете, именно из-за этого Java быстрее, чем C/C++ ?
>
>Java не быстрее C/C++, так как JVM написана на C/C++.А вы знаете, что реализация Python, написанная на самом Python, говорят, в Разы быстрее исходной, написанной на C++? А ещё когда-то здесь же на опеннете пролетала новость где сравнивались разными бенчмарками разные виртуальные машины (VirtualBox, VMWare, и т.п.) и физическая, и по некоторым статьям какие-то виртуальная машина обгоняли физическую, на которой сами работали.
>>>Думаете, именно из-за этого Java быстрее, чем C/C++ ?
>>
>>Java не быстрее C/C++, так как JVM написана на C/C++.
>
>А вы знаете, что реализация Python, написанная на самом Python, говорят, в
>Разы быстрее исходной, написанной на C++? А ещё когда-то здесь же
>на опеннете пролетала новость где сравнивались разными бенчмарками разные виртуальные машины
>(VirtualBox, VMWare, и т.п.) и физическая, и по некоторым статьям какие-то
>виртуальная машина обгоняли физическую, на которой сами работали.нет -- не читайте до обеда....
эти люди ещё жалуются .... мама дорогая -- Кругом они! (C) Опеннет.
> Это напомнило мне строки в C/C++...А плюсы то Вы не знаете...
http://www.cplusplus.com/reference/string/string/length/
А как эта функция внутри работает, не задумывались?
Отройте исходники, да посмотрите наконец сами!
>То ли дело в Pascal и Java — длина строки заранее известна и её не нужно вычислять!И откуда же, по-вашему, они берут длину?
>>То ли дело в Pascal и Java — длина строки заранее известна и её не нужно вычислять!
>
>И откуда же, по-вашему, они берут длину?считают заранее в java String - immutable
>>То ли дело в Pascal и Java — длина строки заранее известна и её не нужно вычислять!
>
>И откуда же, по-вашему, они берут длину?Вначале строки хранят размер.
А зачем вообще мешать все в кучу и вставлять в ogg видео?
>А зачем вообще мешать все в кучу и вставлять в ogg видео?есть другие предложения?
Оставить контейнер OGG для аудио (Vorbis), и признать тот факт, что OGG как универсальный медиаконтейнер так и не состоялся.
Для видео же стоит использовать более подходящий контейнер - Matroska, и забить на попытки переделать OGG. Де факто сейчас всё именно так и есть.
>Оставить контейнер OGG для аудио (Vorbis), и признать тот факт, что OGG как универсальный медиаконтейнер так и не состоялся. Для видео же стоит использовать более подходящий контейнер - Matroska, и забить на попытки переделать OGG. Де факто сейчас всё именно так и есть.OGG и не разрабатывался для хранения всего на свете. хз почему решили именно этот контейнер всунуть в рекомендации. matroska/mp4+ h.264 + aac - гораздо лучший вариант, ставший стандартом де-факто
>есть другие предложения?Ну как? Создать отдельный контейнер для видео.
В целом - почитайте 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.