[03:48:02] <valexey> https://hsto.org/files/911/73a/678/91173a678f1a466782841398ebf27809.png
[03:48:05] <valexey> O_O
[03:48:06] <valexey> @_@
[03:48:28] <valexey> /me want to reproduce this results.
[06:31:17] <Kemet> valexey: дык воспроизведи
[06:31:35] <valexey> in progress
[06:34:28] <Kemet> valexey: таки UnixAos64 мложно собрать только из под UnixAos32
[06:34:37] <valexey> I know.
[06:35:12] <valexey> Also UnixAos32 hangs if I'll try to multiply matrices with size = 3000
[06:35:20] <Kemet> yj djj,ot-nj vj;yj pfgbkbnm rhjccgkfnajhvtyye. c,jhre? lheujt ltkj xnj ybrjve yt yflj
[06:36:17] <Kemet> в принципе можно сделать кроспалтформенный инструментарий для сборки но кому это надо
[06:37:16] <Kemet> valexey: m[3000,3000] чтоли
[06:37:27] <valexey> yep
[06:37:42] <Kemet> да там может памяти не хватает )
[06:37:54] <valexey> or m[*,*] and with NEW(m,3000,3000);
[06:38:02] <valexey> how to increase heap size?
[06:40:57] <Kemet> как в юниксаос хз, надо покопать
[06:42:50] <Kemet> valexey: возможно Unix.I386.Machine.Mod MemBlockSize
[06:45:23] <Kemet> Там же, кстати, должен быть MaxCPU, если ядер # 4 то лучше поправить
[06:47:19] <valexey> There are 4 cores in my CPU.
[06:47:56] <Kemet> там 4 по умолчанию
[06:48:21] <valexey> But it seems like MemBlockSize is not a max heap size.
[06:48:37] <valexey> Because there is ExpandHeap procedure.
[06:52:19] <Kemet> ну может тогда это размер шматков запрашиваемых у линупса
[06:55:39] <valexey> the story is a little bit more complicated :-) It is a minimum expand size.
[06:57:10] <valexey> Hmm.. It seems like AO matrix multiplication is fast. But I have to do sanity check.
[06:59:54] <valexey> But anyway matlab has superior performance.
[07:05:39] <Kemet> матлаб быстрее? вряд ли
[07:07:36] <valexey> ofcourse matlab is faster. just because it uses high optimized c/asm code. Intel library - MKL
[07:07:40] <valexey> Intel MKL
[07:08:41] <valexey> ~4 times faster then Active Oberon
[07:12:50] <Kemet> valexey: дык в АО там Asm SSE
[07:12:55] <Kemet> SSE2
[07:13:16] <valexey> yep. but Intel MKL is faster anyway :-)
[07:13:26] <valexey> matlab is faster
[07:15:44] <Kemet> а что ты тести руешь,Ю что оно у тебя в 4 раза медленнее
[07:18:31] <valexey> C = A*B;
[07:24:00] <Kemet> valexey: VAR a,b,c : ARRAY [3000,3000] OF T ? или таки [*,*] ?
[07:24:15] <valexey> [*,*]
[07:24:34] <Kemet> ну ты задай статический размер
[07:24:39] <valexey> but it is doesn't matter
[07:24:50] <valexey> the results are the same
[07:48:43] <valexey> The only problem with AO and matrices - hanging AOS woth matrix size = 3000.
[07:51:20] <Kemet> valexey: у меня скорость несколько отличается между статикой и динамикой, но не на порядок, да
[07:54:20] <Kemet> valexey: бгг, у меня время выполнения умножения матрицы [1000, 1000] и [3000, 3000] практически идентично
[07:56:12] <Kemet> valexey: да, винаос оно норм, не падает
[07:56:27] <valexey> what duration?
[07:56:56] <valexey> Use Kernel.GetTicks()
[07:58:24] <Kemet> valexey:
MODULE Test;
IMPORT Kernel, Commands;
VAR a, b, c : ARRAY [*, *] OF LONGINT;
PROCEDURE Do*(context : Commands.Context);
VAR i, n, t : HUGEINT;
BEGIN
NEW(a, 3000,3000);NEW(b,1000,1000);NEW(c,1000,1000);
a := 10; b := 5;
i := Kernel.GetTicks();
REPEAT t := Kernel.GetTicks() UNTIL t # i;
c := b * c;
ASSERT (c # 50);
t := Kernel.GetTicks() - t;
context.out.Int(n, 1); context.out.String(" loops, ");
context.out.Int(t*1000 DIV Kernel.second, 1); context.out.String(" ms");
END Do;
END Test.
[07:59:26] <Kemet> valexey: *NEW(a, 1000,1000)
[08:00:23] <Kemet> тьфу *c : a*b
[08:00:26] <valexey> c := b * c; -- why not a := b*c ?
[08:00:44] <valexey> also please fill matrices with random data
[08:01:06] <valexey> also I use REAL
[08:02:18] <Kemet> и ASSERT ниже надо, вот он копипаст
[08:03:03] <Kemet> valexey: REAL или LONGREAL?
[08:03:10] <valexey> REAL
[08:03:23] <valexey> but I have to check LONGREAL too
[08:08:27] <Kemet> valexey: с LONGREAL НА ПОРЯДОК быстрее чем с LONGINT получается, хм..
[08:09:26] <valexey> :-)
[08:10:43] <valexey> In my case REAL is faster then LONGREAL
[08:10:57] <Kemet> ну SSE, да, там же реалы унутри, преобразование итить их
[08:11:33] <valexey> Hmm.. Is LONGREAL = double?
[08:11:38] <Kemet> valexey: потому что REALов вмещается больше в дыва раза в SSE регистр
[08:15:42] <Kemet> valexey: 64бит
[08:17:01] <Kemet> да, на REAL несколько быстрее
[08:22:45] <valexey> REAL: 0.95 sec, LONGREAL: 2,1 sec (matrix size = 2000)
[08:43:40] <Kemet> REAL 1000х1000 422ms
[08:43:42] <valexey> Optimized matrix production via GCC Vector-Extensions C++ code done it in 0.6 sec for LONG REAL (aka double)
[08:46:02] <valexey> In my case: Active Oberon for 1000 for LONGREAL : 377 ms
[08:48:14] <Kemet> f? e vtyz nj;t ,sk ДЩТПКУФД
[08:48:28] <Kemet> а у меня тоже был LONGREAL
[08:48:41] <valexey> fine
[08:50:01] <valexey> matrix size 2000, C++ result: 0.6 sec (600 ms)
[08:50:23] <valexey> but Intel MKL and matlab are still faster
[08:52:34] <valexey> hmm... but I don't know matlab number precision.. I have to check it.
[08:55:00] <valexey> ok. Have checked it. It was double (LONGREAL) for matlab.
[08:55:09] <valexey> single works even faster
[08:55:23] <valexey> ~150 ms for matrix size = 2000
[09:06:09] <Kemet> valexey: double - 64 bit?
[09:06:16] <valexey> yep
[09:06:24] <valexey> long double = 80 bit
[09:11:13] <Kemet> ак какой кот в цпп
[09:13:40] <valexey> Short answer: foo::axpy_prod(A, B, C, false);
[09:14:13] <valexey> A little bit longer answer: http://www.mathematik.uni-ulm.de/~lehn/test_ublas/session5/page01.html
[09:14:59] <valexey> Also I'd like to check FLENS
[09:15:04] <valexey> https://github.com/michael-lehn/FLENS
[09:16:09] <valexey> But in real world ofcourse if you want really fast matrix computattions on Intel arch then you should use Intel MKL.
[09:18:08] <valexey> or ATLAS
[09:24:24] <Kemet> valexey: поди многопоточная хрень?
[09:24:52] <valexey> no. single thread
[09:25:20] <valexey> I like to compare apples with apples, not oranges :-)
[09:49:46] <Kemet> valexey: ты поди оптимизацию по sse4 включил?
[09:52:00] <Kemet> В АО же SSE2, а в SSE4 размер регистра в 2 раза больше, поэтому оно будет быстрее примерно в 2 раза
[09:53:26] <Kemet> надо на цпп сгенерирвать кот под SSE2 и сравнить
[10:23:52] <Kemet> Но в АО есть еще оверхед, связанный с динамической адаптацией под поддерживаемый набор инструкций, если это выпилить, то, конечно,, несколько возрастет производительность
[11:11:56] <Kemet> хотя нет, вроде это только в AVX регистры шире, но SSE4 всё-равно быстрее чем SSE2
[11:18:08] <TRUE> WinAOS.exe (который в транке) вообще не запускается?
[11:25:42] <Kemet> TRUE: e vtyz hf,jnftn
[11:25:52] <Kemet> у меня работает
[11:29:56] <acidtech23> матрицес ))
[13:32:06] <sda> Kemet: http://colonelcassad.livejournal.com/2640384.html
[15:25:54] <valexey> Kemet: Noup. I compile C++ code with AVX. Not SSE4.
[15:25:56] <valexey> ;-)
[15:27:22] <valexey> FMA (AVX2)
[15:41:42] <valexey> As I see Active Oberon compiler has SSE3 support.
[15:41:52] <valexey> But only for windows target.
[15:57:31] <Kemet> valexey: мля, ну ты сам сравни SSE2 и AVX2 )))) вручную же написаны, компилятор ничего тут не гненерирует, а вручную они вод sse21
[15:57:47] <Kemet> sse2
[16:03:41] <valexey> yep. So we just compare not Active Oberon vs C++ but sse2 asm VS optimized C++ code with gcc intrinsics.
[16:13:52] <Kemet> valexey: а в А2 я сейчас даже на асме не смогу под FMAS нгаписать, ибо ассемблер не поддерживает и придётся писать в машинных кодах )
[16:14:05] <Kemet> *FMA
[16:14:15] <valexey> o_O
[16:15:44] <acidtech23> пиши в переключениях тумблеров
[16:16:02] <Kemet> ну может феликс и реализовал поддержку, но в паблике этого нема, впрочем там много чего нема
[16:19:50] <Kemet> valexey: кстати в WinAos на [3000x3000] тоже падает, если пер этим память не выделена была, а если скомпилировать статический массив, то норм
[16:20:38] <valexey> How to fix it?
[16:21:24] <valexey> It is not crashes, it hangs - I can move windows but I cant do anything in UnixAOS in such case.
[16:22:53] <Kemet> хотя нет, я счас норм [20000x20000] посчитал без падений
[16:23:32] <Kemet> но это таки проблемы с памятью какие-то
[16:24:32] <Kemet> valexey: так оно долго считает, может в ЮниксАос что-то подвисает, подожди подольше )
[16:24:59] <valexey> There is no CPU load. CPU is idle in such case.
[16:25:38] <Kemet> ну у мну нет под рукой лирупса чтоб проверить
[16:25:39] <Kemet> а линупс 64б?
[16:25:53] <acidtech23> обретите себе плис )
[16:25:56] <valexey> AMD64, yes.
[16:26:11] <acidtech23> для данных сука перемножений матриц
[16:26:36] <acidtech23> что ж вы мозги то ебете с этим c86
[16:26:37] <valexey> or Cuda :-D
[16:26:59] <acidtech23> во, на cuda хорошо получается
[16:27:10] <valexey> /me want to find this paper: Michael Baumgartner, Erweiterung des Active Oberon Compilers und Software En-
twicklungssystems im Hinblick auf die Ausnutzung der Intel SSE2 Vektoroperatio-
nen für mathematische Anwendungen, Diploma Thesis, ETH Zürich, 2003.
[16:33:02] <valexey> but no success :-(
[16:39:31] <Kemet> valexey: а на еколлекшн искал?
[16:39:42] <valexey> yes.
[16:44:15] <valexey> So. Short preliminary conclusion: the main problem for Active Oberon is not a performance. Performance is fine. But it is very unstable (in case of matrix production).
[17:02:03] <Kemet> valexey: я думаю, что сами матрицы норм, а вот с памятью... надо посмотреть
[17:07:28] <valexey> matrix production process can consume big amounts of memory.
[17:28:11] <Kemet> тут еще одна проблема - статические матрицы большой размерности не влезут в объектный файл, но, в принципе, это не столько проблема - данные нужно хзранить отдельно, да, но на поиграццо хотелось бы, да.
Также можно увеличить грануляроность запроса шматков памяти у хоста
[17:29:06] <valexey> If anyone want to replace matlab to AOS then this problem should be solved.
[17:30:01] <valexey> Because in real world only dynamic matrices will be used.
[17:30:06] <valexey> in REPL :-)
[17:35:01] <Kemet> valexey: я думаю, лучше написать Феликсу о проблеме или в мыллист, но думаю, что в личуку будет быстрее
[17:35:46] <Kemet> возможно, что такие проблемы только в публичной версии, ибо по остатьчному принципу,
[17:35:47] <valexey> how to do it? via e-mail?
[17:35:52] <Kemet> ага
[17:36:07] <valexey> hm. what e-mail address he has?
[17:38:22] <Kemet> felix[DOT]friedrich[DOG]inf[DOT]ethz[DOT]ch
[17:39:32] <valexey> ok. thanks. I'll do it.
[17:39:48] <Kemet> у них же есть так называемая medical kernel на базе А2
[17:40:17] <Kemet> и это матрасширение были по заказу сделаны
[17:40:26] <valexey> In 2003?
[17:40:36] <Kemet> хз
[17:41:21] <valexey> Also I'll try to reproduce this bug without matrix multiplication. I'll just try to allocate different arrays with a very different size.
[17:42:02] <Kemet> как раз счас этим занимаюсь
[17:43:52] <valexey> ok. So I have to go. I'll return to this question tomorrow.
[17:44:21] <valexey> Thanks for help.
[17:44:34] <valexey> And advices.
[17:50:40] <Kemet> valexey: также я думаю, что правильнее запускать вычисление в отдельном потоке с высоким приоритетом, так как гуяня много отъедает, или вообще консольную версию сделать
[18:04:31] <Kemet> valexey: ты использовал UnixAos32?
[18:18:21] <_valexey_> Kemet: думаю да
[18:18:37] <_valexey_> 32 битная версия была у меня точно
[18:18:52] <_valexey_> 64 еще не собрал
[18:19:32] <_valexey_> Консольную версию было бы круто сделать
[18:20:10] <_valexey_> Если есть хаутушка как ее делать, я попробую.
[18:22:00] <Kemet> _valexey_: думаю, что 32 бит реально использует адреса в диапазоте 31 бит, и размеры, так что с памятью тут надо смотреть
[18:22:26] <_valexey_> Попробую сделать 64
[18:22:33] <Kemet> чтото правилось на ADDRESS и SIZE но не всё
[18:23:53] <Kemet> ук меня в винде [3000x3000] в диспетчере показывает, что винаос заняла >1,6ГБ
[18:24:37] <Kemet> думаю в 32 бит венде это предел для процесса
[18:25:29] <_valexey_> Но у меня оно макс жрало 256
[18:25:41] <Kemet> ну хз
[18:26:10] <Kemet> MODULE Test;
IMPORT Kernel, Commands;
VAR a, b, c : ARRAY [*, *] OF LONGREAL;
PROCEDURE Do*(context : Commands.Context);
VAR i, t : HUGEINT; M : LONGINT;
BEGIN
IF context.arg.GetInteger(M, FALSE) THEN
context.out.String("N = "); context.out.Int(M, 1); context.out.Ln;
context.out.String("SIZEOF T = "); context.out.Int(SIZEOF(LONGREAL), 1); context.out.Ln;
i := Kernel.GetTicks();
REPEAT t := Kernel.GetTicks() UNTIL t # i;
NEW(a, M,M);NEW(b,M,M);NEW(c,M,M);
t := Kernel.GetTicks() - t;
context.out.String("Allocation = ");
context.out.Int(t*1000 DIV Kernel.second, 1); context.out.String(" ms");
context.out.Ln;
i := Kernel.GetTicks();
REPEAT t := Kernel.GetTicks() UNTIL t # i;
a := 10.0; b := 5.0;
t := Kernel.GetTicks() - t;
context.out.String("Initialization = ");
context.out.Int(t*1000 DIV Kernel.second, 1); context.out.String(" ms");
context.out.Ln;
i := Kernel.GetTicks();
REPEAT t := Kernel.GetTicks() UNTIL t # i;
c := a * b;
t := Kernel.GetTicks() - t;
context.out.String("Multiplication ");
context.out.Int(t*1000 DIV Kernel.second, 1); context.out.String(" ms");
context.out.Ln;
ELSE
context.out.String("ERROR");context.out.Ln;
END;
END Do;
END Test.
Test.Do 1000 ~
SystemTools.Free Test ~
[18:28:19] <_valexey_> И потом затыкалось.
[18:32:25] <Kemet> _valexey_: вот я запукаю этот тест и для 1000 у меня времы выделения 0, а для 3000 уже 124 мс
[18:32:58] <_valexey_> Выделения, не счета?
[18:33:17] <Kemet> да
[18:33:19] <Kemet> N = 1000
SIZEOF T = 8
Allocation = 0 ms
Initialization = 16 ms
Multiplication 358 ms
Unloading Test... done.
N = 3000
SIZEOF T = 8
Allocation = 124 ms
Initialization = 203 ms
Multiplication 9470 ms
[18:33:40] <_valexey_> Видимо приходится у хоста просить памяти
[18:33:52] <Kemet> угу
[18:35:56] <Kemet> я думаю еще и винда свопирует, так как винт мигает
[18:38:04] <_valexey_> Хм
[18:38:34] <_valexey_> Ну, у меня не винда и ничего не свопится. Памяти 12 гиг
[18:42:40] <Kemet> N = 4000
SIZEOF T = 8
Allocation = 640 ms
Initialization = 358 ms
Multiplication 21840 ms
[18:43:00] <Kemet> что странно в диспетчере процесс не сильно нагружал процессор
[18:43:50] <_valexey_> Своп?
[18:43:53] <Kemet> надо поробовать повысить приоритет а2
[18:44:20] <Kemet> но индикатор харда мигал, да
[18:44:28] <Kemet> думаю своп
[18:44:30] <_valexey_> Во время именно рассчета своп
[18:44:41] <Kemet> видимо да
[18:45:03] <Kemet> всё ыремя, пока работала процедура и потом немного
[18:45:17] <_valexey_> Если у меня дело в памяти, то на real должно работать с бОльшими размерностями чем на longreal
[18:45:26] <_valexey_> Проверю
[18:47:40] <Kemet> N = 4000
SIZEOF T = 4
Allocation = 422 ms
Initialization = 375 ms
Multiplication 10811 ms
[18:48:18] <Kemet> примернов 2 раза быстрее
[18:48:28] <Kemet> чем логреал
[18:50:09] <_valexey_> Угу. У меня тоже
[18:50:20] <_valexey_> И не только в обероне
[18:50:30] <Kemet> _valexey_: кстати, да, ксли вместо c := a * b использовать a := a * b; и вообще выпилить c то и с памятью лучше
[18:50:41] <_valexey_> В матлабе тоже в 2 раза быстрее
[19:03:22] <vlad2> js: http://thedailywtf.com/articles/bidding-on-security
[19:14:13] <sda> подскажите софт для сравнения двух текстов на совпадение
[19:14:24] <sda> именно на совпадение, а не на различие
[19:17:37] <vlad2> diff?
[19:18:09] <sda> а он умеет совпадения показывать?
[19:18:37] <sda> ну т.е. у меня два разных текста, которые имеют общие куски, вот их и надо выявить
[19:23:50] <Kemet> _valexey_: если использовать форму c := a*b;., то для c выделять память ненужно, ибо она автоматом выделяется при расчетах
[19:25:20] <_valexey_> Ок. Но это не важно в принципе
[19:25:42] <Kemet> и в этом смлучае у меня "всего" 400мб против 1700
[19:30:36] <_valexey_> Странно
[19:30:39] <_valexey_> Очень
[19:31:09] <_valexey_> Ибо матрица С не занимает столько места.
[20:06:52] <valexey> https://habrahabr.ru/company/edison/blog/277803/
[21:04:39] <Kemet> valexey, Чето я не то делал ибо повторить 1,7гб памяти не смог, больше 500мб не поднимается и это с учетом других пгиложентй
[21:08:38] <Kemet> но, тем не менее, cpu usage не сильно высок для процесса а2
[21:29:35] <valexey> Exactly one core in my case - 25% CPU usage.
[21:46:52] <valexey> Kemet: Is A2 works on raspberry pi?
[21:50:51] <Kemet> valexey, Угу, кстати в zonnon тшже есть матрасширение и вроде там через opencl
[21:51:33] <valexey> Yep. Zonnon math extensions had been done in my town :-) In nizhniy novgorod.
[21:51:46] <Kemet> valexey,
Есть кооперетивное ядро под рпи но гуйни вроде нет
[21:52:31] <valexey> http://www.unn.ru/pages/issues/vestnik/99999999_West_2010_3/29.pdf
[21:52:57] <valexey> command line only for rpi? it is ok.
[21:53:17] <Kemet> valexey, Ядро
[21:53:41] <valexey> Hmm. What about compiler and others?
[21:55:24] <valexey> I want to use UnixAOS for rpi.
[21:55:40] <valexey> "Reading through Release.Tool in the A2 source directory, it appears to me that A2 is now also supported on the Raspberry Pi.
Is there any additional information how to get it running?
Does it use Raspbian (or anything else) s hardware abstraction layer or is it running natively?"
[21:56:37] <Kemet> Думаю там нет текстовой консоли, только кросс или поднять вебсервер и через него чтото делать
[21:58:23] <Kemet> Юсб на рпи работает
[21:58:59] <Kemet> А вот с сетевухой хз что там на борде
[21:59:58] <valexey> Is it UnixAOS or native?
[22:00:14] <Kemet> Там просто образ собираешь и заливаешь и фсё
[22:00:30] <Kemet> valexey, Натив
[22:01:25] <Kemet> Не уверен что юнксаос под арм линукс заработает, думаю придется пилить
[22:01:45] <valexey> why? abi?
[22:02:14] <Kemet> valexey, Ну наверное да
[22:02:39] <Kemet> valexey, Думаю ч о никто не проверял
[22:06:14] <Kemet> valexey, 100% не зараюотает - там есть асм
[22:06:41] <valexey> :-\
[22:07:05] <Kemet> И эти части нужно переписать на neon
[22:07:57] <Kemet> Но если тебе только консоль, то думаю можно
[22:08:49] <valexey> neon? Why? Why not just a FPU?
[22:09:59] <Kemet> Здесь нужно копать в сторону нового формата шбъектника и линкера, который вроде как умеет эльф тоже
[22:10:24] <Kemet> valexey, Потому что графика
[22:12:00] <Kemet> valexey, Текущий комеилятор под х86 не генерит fpu - тока sse2
[22:12:07] <valexey> I know.
[22:12:27] <valexey> But it seems like it can generate code for ARM target without SIMD.
[22:13:12] <Kemet> Думею нужно переписать на неоне растровые операции, ну на крайняк на арм асм
[22:14:26] <valexey> http://www.opennet.ru/opennews/art.shtml?num=43962
[22:14:35] <valexey> ARM 64bit
[22:14:49] <Kemet> valexey, Угу, шоб на ихних армовых эелезякаъ запускалось- они же под минос в а2 разрабатывают
[22:15:15] <valexey> hm.. what is minos?
[22:15:44] <Kemet> valexey, Их авангардная ось на оберон07
[22:16:04] <valexey> o_O
[22:17:48] <valexey> http://cordis.europa.eu/docs/publications/1277/127704771-6_en.pdf
[22:17:50] <valexey> ?
[22:18:24] <Kemet> valexey, Когда то была армовая а2 для dec shark
[22:21:15] <Kemet> valexey, Я с телефона не прочитаю
[22:21:23] <valexey> ok
[22:22:43] <Kemet> valexey, А онбас да
[22:47:38] <Kemet> valexey: а юбниксаос у тебя под рукой?
[22:50:29] <valexey> yes
[22:51:18] <Kemet> а вот эту хрень выполни, в кернеллоге будет видно где оно тормозится
[22:51:27] <Kemet> MODULE Test;
IMPORT Kernel, KernelLog, Commands;
VAR a, b, c : ARRAY [*, *] OF LONGREAL;
PROCEDURE Do*(context : Commands.Context);
VAR i, t : HUGEINT; N : LONGINT;
BEGIN
IF context.arg.GetInteger(N, FALSE) THEN
KernelLog.String("N = "); KernelLog.Int(N, 1); KernelLog.Ln;
KernelLog.String("SIZEOF T = "); KernelLog.Int(SIZEOF(LONGREAL), 1); KernelLog.Ln;
i := Kernel.GetTicks();
REPEAT t := Kernel.GetTicks() UNTIL t # i;
NEW(a, N,N);NEW(b,N,N);NEW(c,N,N);
t := Kernel.GetTicks() - t;
KernelLog.String("Allocation = ");
KernelLog.Int(t*1000 DIV Kernel.second, 1); KernelLog.String(" ms");
KernelLog.Ln;
i := Kernel.GetTicks();
REPEAT t := Kernel.GetTicks() UNTIL t # i;
a := 10.0; b := 5.0;
t := Kernel.GetTicks() - t;
KernelLog.String("Initialization = ");
KernelLog.Int(t*1000 DIV Kernel.second, 1); KernelLog.String(" ms");
KernelLog.Ln;
i := Kernel.GetTicks();
REPEAT t := Kernel.GetTicks() UNTIL t # i;
c := a * b;
t := Kernel.GetTicks() - t;
KernelLog.String("Multiplication ");
KernelLog.Int(t*1000 DIV Kernel.second, 1); KernelLog.String(" ms");
KernelLog.Ln;
ELSE
KernelLog.String("ERROR");KernelLog.Ln;
END;
END Do;
END Test.
Test.Do 3000 ~
SystemTools.Free Test ~
[22:55:01] <Kemet> кстати винаос под вайном шустрее пашет, чем юниксаос
[22:55:26] <Kemet> пуйня
[22:55:35] <Kemet> гуйня )
[22:57:01] <valexey> Where is kernel log?
[22:57:17] <valexey> ok. I see
[22:57:34] <valexey> N = 3000
SIZEOF T = 8
[22:57:38] <valexey> and thats all
[22:58:18] <Kemet> а если NEW(c убрать
[22:59:22] <Kemet> но и так ясно - чтото в схеме )
[22:59:23] <Kemet> как и прдполагали это память
[23:02:00] <valexey> Also I've found bourderline : size=2500 - it works for REAL but hangs for LONGREAL.
[23:04:06] <Kemet> у меня 7500 норм
[23:04:31] <Kemet> но выделение 1217мс
[23:05:27] <Kemet> valexey: кстати, когда зависнет на 3000, убей а2 и посмотри в каталоге afqks trace* и trap*
[23:07:42] <valexey> in working dir?
[23:08:34] <Kemet> lf
[23:08:38] <Kemet> да
[23:08:55] <Kemet> но в юниксаос могут быть варианты, да
[23:09:04] <valexey> there is no new traps
[23:09:24] <valexey> only log-file: AOS.27719.Log
[23:10:26] <valexey> also there are several .tmp files
[23:16:16] <valexey> And yes. It is a memory allocation problem.
[23:16:41] <valexey> I just have reproduced it without matrix production.
[23:17:08] <valexey> simple: new(A, 10000, 10000); and thats all.
[23:17:19] <Kemet> SystemTrace* есть
[23:17:34] <Kemet> ?
[23:20:42] <Kemet> а что тут есть AOS.27719.Log
[23:21:30] <Kemet> кста, оптимизированная версия массивов только под 32 бита в паблике
[23:22:19] <Kemet> и там явно LONGINT всесто ADDRESS, возможно это несет проблемы и при вычислениях
[23:22:41] <Kemet> по крайнейм мере я местами увидел LONGINT
[23:23:28] <Kemet> лан я спать - почти пол третьего ночи
[23:23:34] <valexey> bb