FYI - 8s on my MacBookPro 13"
Regards Rob
Sent from my iPhone
> On 15 Jan 2014, at 7:12 pm, Ben Gorte - CITG <b.g.h.go...@tudelft.nl> wrote:
>
> Thanks, this is great. After recompiling libj with -O3 my computer does Fibo
> 1000000 in 13.6s instead of 41.3. Also Haralick became a bit quicker, 75s now.
>
> But shouldn't it be like this in the binary downloads as well?
>
> Regards,
> Ben
>
> ________________________________________
> From: programming-boun...@forums.jsoftware.com
> [programming-boun...@forums.jsoftware.com] on behalf of bill lam
> [bbill....@gmail.com]
> Sent: Wednesday, January 15, 2014 04:10
> To: programm...@jsoftware.com
> Subject: Re: [Jprogramming] On benchmarking results from J programming styles
>
> I get similar result for Fibo that linux needed about 41s and this is
> strange. I then recompiled the libj.so using gcc 4.8 -O3 switch,
> and it droped to 14s, a little bit faster than wine's 17s.
>
> I guess it depends on compiler and optimization level.
>
> Вт, 14 янв 2014, Ben Gorte - CITG писал(а):
>> With pleasure. Here are two examples. The first is from my work (image
>> analysis). It computes the good old Haralick texture on a 5000x5000 aerial
>> image. The adverb Filter uses ;. to activate TextSub at every 25th pixel (1M
>> times).
>>
>> ~$ ~/j701/bin/jconsole
>> load '/home/ben/j701-user/temp/pgm.ijs'
>>
>> CM =. 4 : '((# /.)~ y) (<"1 ~.y) } (x,x)$0'"0 2
>> Norm =: 3 : 'y%+/,y'
>> Contrast=: 3 : '+/, y * *:(<:#y)%~-/~i.#y'"2
>> Con =: 3 : 'Contrast Norm (+|:) y'"2 NB. for non-normalized
>> non-symmetrical cm
>>
>> TextSub =: 4 : 0 NB. texture in a sub-image
>> co =. |:,.(_1&}."1 ,: 1&}."1) y
>> cm =. x CM co
>> Con cm
>> )
>>
>> im =: <.(%16) * pgmread '/home/ben/data/Danbi/redsub.pgm'
>> NB. Filter applies 12&F to 7x7 subimages of <.im%16, at every 5th line and
>> column.
>> 6!:2 'conperpix =. <.1000*12 TextSub Filter (5 5,:7 7) <.im%16'
>> 87.5534
>>
>> ~$ wine /media/Windows/Documents\ and\ Settings/bgorte/j701/bin/jconsole.exe
>> ....
>> 6!:2 'conperpix =. <.1000*12 TextSub Filter (5 5,:7 7) <.im%16'
>> 67.088
>>
>> It's a 30% speed difference.
>>
>> Here's a more drastic example. I guess it spends most of its time doing
>> extended precision things. The Fibo routine is activated recursively just 20
>> times or so. The result has over 200000 digits.
>>
>> ~$ ~/j701/bin/jconsole
>> Fibo =: 3 : 0"0 NB. Compute large Fibonacci numbers like Fibo 1000000
>> if. y<5 do. NB. returns (F y-1),F y
>> ((,~<:)y){0 1 1 2 3x
>> elseif. 0=2|y do.
>> 'b c'=.Fibo -:y
>> a=.c-b
>> d=.c+b
>> p=.b*a+c
>> q=.c*b+d
>> (q-p),q
>> elseif. do.
>> 'b c'=.Fibo -:>:y
>> a=.c-b
>> d=.c+b
>> p=.b*a+c
>> q=.c*b+d
>> p,q-p
>> end.
>> )
>> 6!:2 'z=.{:Fibo 1000000'
>> 41.3298
>>
>>
>> ~$ wine /media/Windows/Documents\ and\ Settings/bgorte/j701/bin/jconsole.exe
>> ....
>> 6!:2 'z=.{:Fibo 1000000'
>> 15.5417
>>
>> #":z NB.
>> 208988
>>
>> ________________________________________
>> From: programming-boun...@forums.jsoftware.com
>> [programming-boun...@forums.jsoftware.com] on behalf of Michael Dykman
>> [mdyk...@gmail.com]
>> Sent: Tuesday, January 14, 2014 17:02
>> To: J Programming
>> Subject: Re: [Jprogramming] On benchmarking results from J programming styles
>>
>> As the timings that you are reporting are very tiny values, we should
>> pause for a moment and consider a basic difference between those OSs.
>> Under windows, the finest-grained application timer available tick
>> 18/s; on linux that number is 1024/s. I suggest that you try some
>> longer-running verbs if you expect a fair comparison.
>>
>> On Tue, Jan 14, 2014 at 6:11 AM, Ben Gorte - CITG
>> <b.g.h.go...@tudelft.nl> wrote:
>>> Speaking about J, performance and Linux, is it true that Windows is
>>> significantly faster? Or is there something wrong with my installation?
>>> Also when runnning windows J under wine on my linux PC I get a better
>>> performance than with native linux J:
>>>
>>> NB. Native Linux
>>> JVERSION
>>> Engine: j701/2011-01-10/11:25
>>> Library: 7.01.087
>>> Platform: Linux 32
>>> Installer: j701a_linux32.sh
>>> InstallPath: /home/ben/j701
>>> time'locs=:nudge"1 locs'
>>> 1.43086e_5
>>> time'locs=:pfn"1 locs'
>>> 7.41384e_6
>>> time'locs=:(pfn f.)"1 locs'
>>> 3.77003e_6
>>> time'locs=:pfns"1 locs'
>>> 3.7135e_5
>>>
>>> NB. wine + Windows J
>>> JVERSION
>>> Engine: j701/2011-01-10/11:25
>>> Library: 7.01.040
>>> Platform: Win 32
>>> Installer: j701a_win.exe
>>> InstallPath: z:/media/windows/documents and settings/bgorte/j701
>>> time'locs=:nudge"1 locs'
>>> 1.09025e_5
>>> time'locs=:pfn"1 locs'
>>> 5.56416e_6
>>> time'locs=:(pfn f.)"1 locs'
>>> 2.88706e_6
>>> time'locs=:pfns"1 locs'
>>> 2.77585e_5
>>>
>>> Regards,
>>> Ben
>>> ________________________________________
>>> From: programming-boun...@forums.jsoftware.com
>>> [programming-boun...@forums.jsoftware.com] on behalf of Raul Miller
>>> [rauldmil...@gmail.com]
>>> Sent: Monday, January 13, 2014 06:44
>>> To: Programming forum
>>> Subject: Re: [Jprogramming] On benchmarking results from J programming
>>> styles
>>>
>>> That sounds about right.
>>>
>>> The big caution I would place on interpreting these results is: "This
>>> won't necessarily apply for games implemented in J for Linux, where I
>>> intend to rely on the SDL and byte-per-pixel graphics layouts.
>>> Nonetheless, I retain the logic here, since it's representative of a
>>> real-world design decision which directly influences performance on
>>> the slower Kestrel architecture."
>>>
>>> If J is to perform well when applied in suboptimal fashion we'll need
>>> some way of representing the code which strips out a lot of the
>>> functionality (type checks, size checks, rank handling, maybe even
>>> overflow handling?), at least for the time-critical routines. (As much
>>> as possible, hoisting redundant operations out of primitives used in
>>> bottleneck loops.)
>>>
>>> Thanks,
>>>
>>> --
>>> Raul
>>>
>>>
>>> On Sun, Jan 12, 2014 at 11:59 PM, William Tanksley, Jr
>>> <wtanksle...@gmail.com> wrote:
>>>> A friend of mine wrote the following paper describing his attempt to
>>>> characterize the differences between a few different styles of
>>>> implementing the same code in J a few different ways -- explicit,
>>>> implicit, and a few variations. He also baselined against a Forth
>>>> implementation.
>>>>
>>>> I found his writeup very interesting. What do you think?
>>>>
>>>> http://sam-falvo.github.io/2014/01/05/subroutine-performance-in-j/
>>>>
>>>> -Wm
>>>> ----------------------------------------------------------------------
>>>> For information about J forums see http://www.jsoftware.com/forums.htm
>>> ----------------------------------------------------------------------
>>> For information about J forums see http://www.jsoftware.com/forums.htm
>>> ----------------------------------------------------------------------
>>> For information about J forums see http://www.jsoftware.com/forums.htm
>>
>>
>>
>> --
>> - michael dykman
>> - mdyk...@gmail.com
>>
>> May the Source be with you.
>> ----------------------------------------------------------------------
>> For information about J forums see http://www.jsoftware.com/forums.htm
>> ----------------------------------------------------------------------
>> For information about J forums see http://www.jsoftware.com/forums.htm
>
> --
> regards,
> ====================================================
> GPG key 1024D/4434BAB3 2008-08-24
> gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
> gpg --keyserver subkeys.pgp.net --armor --export 4434BAB3
> ----------------------------------------------------------------------
> For information about J forums see http://www.jsoftware.com/forums.htm
> ----------------------------------------------------------------------
> For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
