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
