I didn't test. Which tests failed with gcc 4.8? I guess it is the loop
vectorize optimization that may break ar.c, you may try disable it with a CFLAG
switch.
15.01.2014, в 20:38, Thomas Costigliola <tcost...@gmail.com> написал(а):
> Hi Bill, did you run the test suite after compiling? I have been having
> problems with gcc 4.8. I haven't been able to get a passing libj, I have
> tried a few distros' gcc with different optimizations. It seems to always
> be overoptimizing some things. Gcc 4.7 doesn't have the issue.
>
> On Jan 14, 2014 10:11 PM, "bill lam" <bbill....@gmail.com> wrote:
>>
>> 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
