OK, I have downloaded the updated Linux j806 Beta-5 and now it doesn't run (gets Illegal instruction on starting jconsole ). I believe that Bill Lam meant to say "Your cpu does [NOT] support avx and supposed to be incapable of running j806 binary." and that would seem to be the case now.
On the other hand, I am very impressed that my ancient benchmark is 2.7 times faster in (the broken?) Beta-5 than it is in j805. Sure would be nice to have twice the performance in things I do routinely... Anyway, moving on to OS X 10.12.6 I downloaded and installed again. Using jconsole (even without permission/quarantine problems) works as expected. Repeating my benchmark, I see - MBpro:~ jkt$ jb JVERSION Engine: j806/j64avx/darwin Beta-5: commercial/2017-08-28T14:34:11 Library: 8.06.06 Platform: Darwin 64 Installer: J806 install InstallPath: /applications/j64-806 Contact: www.jsoftware.com 5 (6!:2) '%. 1000 1000 ?@$ 0' 0.8359176 exit 0 MBpro:~ jkt$ ja JVERSION Engine: j805/j64/darwin Release: commercial/2016-12-11T08:17:56 Library: 8.05.10 Platform: Darwin 64 Installer: J805 install InstallPath: /applications/j64-805 Contact: www.jsoftware.com 5 (6!:2) '%. 1000 1000 ?@$ 0' 1.5612282 1.56 % 0.835 1.868263473 So, 1.9 times faster in 806 compared to 805 is nice, even if it isn't the unexplained (in my mind) 2.7 in the "botched" Linux release. Again I fiddled with jQt - this time with limited success... Double clicking on the jqt.app in /Applications/J64-806/bin seems to launch, but fails with error 127. If I ask Finder to display contents of the jqt.app bundle, then drill down through Resources to MacOS and double click on the apprun executable - it dutifully starts a terminal window and brings up the QT IDE which seems all OK. But I can't keep the alias on the launch bar because while it starts the terminal window, it then fails thusly - Last login: Mon Aug 28 23:50:12 on ttys008 MBpro:~ jkt$ /Applications/j64-806/bin/jqt ; exit; This application failed to start because it could not find or load the Qt platform plugin "cocoa" in "". Reinstalling the application may fix this problem. Abort trap: 6 logout Saving session... ...copying shared history... ...saving history...truncating history files... ...completed. [Process completed] I'm sure there is some simple thing I can change to clear this up. Not a big inconvenience to not have jqt handily available, but it is nice to demo things and run labs etc. In any case, I'm going to get some rest and will try to do more experiments later. Onward - joey > On 2017Aug 28, at 13:30, Eric Iverson <[email protected]> wrote: > > We have fixed it (I hope). > The installer should install libj.so and 9!:14 should show j64avx. > Please try again and thanks for your patience. > > On Mon, Aug 28, 2017 at 1:01 PM, Eric Iverson <[email protected]> > wrote: > >> Yes, there is a chance I messed up the packaging again. I will take a look >> later today. >> >> On Mon, Aug 28, 2017 at 10:11 AM, Xiao-Yong Jin <[email protected]> >> wrote: >> >>> It reported j64 instead of j64avx, and the performance is lower, too. >>> I guess something is wrong with the packaging again? >>> >>>> On Aug 28, 2017, at 3:10 AM, bill lam <[email protected]> wrote: >>>> >>>> jkt@set1:~$ jb >>>> JVERSION >>>> Engine: j806/j64/linux >>>> Beta-5: commercial/2017-08-23T10:33:49 >>>> >>>> The line Engine reported j64 instead of j64avx. Previous beta seemed >>>> provided avx binaries. Your cpu does support avx and supposed to be >>>> incapable of running j806 binary. >>>> >>>> >>>> >>>> On Mon, Aug 28, 2017 at 2:17 PM, Joey K Tuttle <[email protected]> wrote: >>>>> I have installed the new beta on my MacBook and on a Ubuntu server. No >>> particular problems, but some fiddling around was required to get jQt >>> working on the Mac. I only use ssh access to the Linux server, so that >>> removes the fiddling. >>>>> >>>>> I decided to run my favorite benchmark (inverting a matrix). I have >>> been doing this for about 47 years - starting with APLSV running on a 360 >>> Model 50 with 32Kbyte (woo hoo!) workspaces... As I recall, the inverse of >>> a 20 20 matrix took several seconds and maxed out the available workspace. >>> Kind of puts into perspective where processing (and memory) has gone. >>> Anyway, here are some results - >>>>> >>>>> jkt@set1:~$ ja >>>>> JVERSION >>>>> Engine: j805/j64/linux >>>>> Release: commercial/2016-12-11T08:02:52 >>>>> Library: 8.05.14 >>>>> Platform: Linux 64 >>>>> Installer: J805 install >>>>> InstallPath: /usr/local/lib/j64-805 >>>>> Contact: www.jsoftware.com >>>>> >>>>> 5 (6!:2) 'mi=. %. 1000 1000 ?.@$ 0' >>>>> 2.71839 >>>>> >>>>> NB. Not too shabby >>>>> >>>>> (3!:1 mi) fwrite 'v805' NB. store the result for later comparison >>>>> 8000048 >>>>> >>>>> exit 0 >>>>> jkt@set1:~$ >>>>> jkt@set1:~$ jb >>>>> JVERSION >>>>> Engine: j806/j64/linux >>>>> Beta-5: commercial/2017-08-23T10:33:49 >>>>> Library: 8.06.06 >>>>> Platform: Linux 64 >>>>> Installer: J806 install >>>>> InstallPath: /usr/local/lib/j64-806 >>>>> Contact: www.jsoftware.com >>>>> >>>>> 5 (6!:2) 'mi=. %. 1000 1000 ?.@$ 0' >>>>> 0.97644 >>>>> >>>>> NB. Whoa! J806 more than twice as fast as J805 on my favorite >>> benchmark. >>>>> >>>>> (3!:1 mi) fwrite 'v806' >>>>> 8000048 >>>>> v5=. fread 'v805' >>>>> v6=. fread 'v806' >>>>> v5 -: v6 >>>>> 0 >>>>> NB. Well, the results aren't identical - but they are probably "very >>> close" ... More research required. >>>>> >>>>> exit 0 >>>>> jkt@set1:~$ cat /proc/cpuinfo >>>>> processor : 0 >>>>> vendor_id : GenuineIntel >>>>> cpu family : 6 >>>>> model : 30 >>>>> model name : Intel(R) Xeon(R) CPU X3430 @ 2.40GHz >>>>> stepping : 5 >>>>> microcode : 0x3 >>>>> cpu MHz : 1200.000 >>>>> cache size : 8192 KB >>>>> physical id : 0 >>>>> siblings : 4 >>>>> core id : 0 >>>>> cpu cores : 4 >>>>> apicid : 0 >>>>> initial apicid : 0 >>>>> fpu : yes >>>>> fpu_exception : yes >>>>> cpuid level : 11 >>>>> wp : yes >>>>> flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge >>> mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall >>> nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology >>> nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 >>> xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm ida dtherm tpr_shadow vnmi >>> flexpriority ept vpid >>>>> bogomips : 4800.60 >>>>> clflush size : 64 >>>>> cache_alignment : 64 >>>>> address sizes : 36 bits physical, 48 bits virtual >>>>> power management: >>>>> .... >>>>> >>>>> The other 3 cores are the same, but irrelevant because j is only using >>> 1 anyway... >>>>> >>>>> Since matrix inverse is implemented essentially in j (I presume that >>> is still true), I'm guessing that the speed up comes from better copy and >>> memory management and that will have a nice impact on a lot of systems! >>>>> >>>>> Congrats on the improvements. >>>>> >>>>> - joey >>>>> >>>>>> On 2017Aug 24, at 05:59, Eric Iverson <[email protected]> >>> wrote: >>>>>> >>>>>> New zip installers are available for win 32/64, linux 32/64, and mac >>> 64 >>>>>> built with the latest source. >>>>> >>>>> ---------------------------------------------------------------------- >>>>> 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 >>> >> >> > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
