Recent posts

41

Questions / Mcafee report

Last post by ed frybarger - July 14, 2014, 12:05:07 AM

Mcafee is reporting Artemis!C53789ADE641 Trojan for

Lunatics_win32_v0.41_setup.exe and
Lunatics_win64_v0.41_setup.exe

when attempting to download or scanning previous downloades!

I assume this is a Mcafee bug ... but wanted to let you folks know!

Ed F

42

Questions / Re: 64-bit package still runs ...

Last post by Jason G - May 26, 2014, 07:20:22 PM

During testing, it was found that the 64-bit executables were slower than the 32-bit versions.

That seems really odd, unless large portion of in-memory data contains mostly pointers, like pointer-based b-tree index or such.  Or, if the code has x86-specific asm instead of using SSE intrinsics that work on both platforms.  I've written compression code using SSE intrinsics, and it is at least 30% faster as 64-bit app vs 32-bit app.

Is the source code available somewhere to browse?

Thx.

For Cuda it's the extra address space that makes Cuda64 apps slower,

Stock is in seti_boinc, Optimised and xbranch in is in branches/sah_v7_opt:

Porting and optimizing SETI@home

https://setisvn.ssl.berkeley.edu/trac/browser

Claggy

Correct.  Simply put, With a lot of memory bound operations at this time (meaning mostly pointer arithmetic), and few latency hiding mechanisms used, pointers being double the size means double the size of code.  Since loading code induces various latencies, and larger pointers sap precious GPU register space... 32 bit GPU code is just faster On Windows (Linux a different special case where 32 bit won't build due to OS and Cuda toolkit limitations). 

As with everything though, things can change and evolve.  As we have no use whatsoever for huge amounts of GPU memory within one application instance ( Yet! ), focussing on making native 64 bit Cuda binaries for Windows isn't high on any priority list.  That will possibly change as newer hardware, drivers, toolkjits, and latency hiding techniques become employed.

In general though, bear in mind that using huge amounts of memory (either host or GPU) tends to be an indicator of poor optimisation, not good optimisation.

43

Questions / Re: 64-bit package still runs ...

Last post by Claggy - May 20, 2014, 11:17:47 PM

During testing, it was found that the 64-bit executables were slower than the 32-bit versions.

That seems really odd, unless large portion of in-memory data contains mostly pointers, like pointer-based b-tree index or such.  Or, if the code has x86-specific asm instead of using SSE intrinsics that work on both platforms.  I've written compression code using SSE intrinsics, and it is at least 30% faster as 64-bit app vs 32-bit app.

Is the source code available somewhere to browse?

Thx.

For Cuda it's the extra address space that makes Cuda64 apps slower,

Stock is in seti_boinc, Optimised and xbranch in is in branches/sah_v7_opt:

Porting and optimizing SETI@home

https://setisvn.ssl.berkeley.edu/trac/browser

Claggy

44

Questions / Re: 64-bit package still runs ...

Last post by tommcg - May 20, 2014, 10:56:40 PM

During testing, it was found that the 64-bit executables were slower than the 32-bit versions.

That seems really odd, unless large portion of in-memory data contains mostly pointers, like pointer-based b-tree index or such.  Or, if the code has x86-specific asm instead of using SSE intrinsics that work on both platforms.  I've written compression code using SSE intrinsics, and it is at least 30% faster as 64-bit app vs 32-bit app.

Is the source code available somewhere to browse?

Thx.

45

Questions / Re: 64-bit package still runs ...

Last post by William - May 20, 2014, 06:32:13 PM

The difference is in the app_info.xml file created by the installer, as it contains entries expected by 64-bit BOINC and necessary to retain work in progress.

46

Questions / Re: 64-bit package still runs ...

Last post by arkayn - May 20, 2014, 03:27:17 PM

During testing, it was found that the 64-bit executables were slower than the 32-bit versions. The choice was made to release 32-bit versions for all packages.

47

Questions / 64-bit package still runs 32-b...

Last post by tommcg - May 20, 2014, 01:09:28 PM

Both the 0.41 64-bit windows installer package, and the individual 64-bit cuda50 package contain only 32-bit executable.  Where can I find the real 64-bit package or binaries?

Thx.

48

General Discussion / Re: Parallella: A Supercompute...

Last post by Claggy - May 18, 2014, 01:01:37 AM

My Parellella's are now both built into their ABOpen Cases, so they have sufficient cooling, the supplied psu's don't work, someone disassembled theirs and found bulged capitors,
replacing those got them going, Bikeman from Einstein has foundout they were recalled by verizon because they didn't work with their routers:

http://forums.parallella.org/viewtopic.php?f=50&t=1145&start=20

so i've got myself two STONTRONICS - T2301ST,  just had to find a pair of power cables for them,
yesterday i got the parallella's to boot, learn't how to ssh into them,  updated them, build Boinc 7.2.47, only one missing dependency,
rebuilt boinc again, attached them to both the Einstein projects and both the Seti projects, got work for both of them the Einstein projects, one's got too much,
temps are running around 55 to 56 degrees C on one, and 59 to 60 degrees C on the other, both under load,
today i've got the seti_boinc and branches sources, bult Seti 7.28 on my T8100 Ubuntu Laptop, and tried to build it on one of the Parallella's,
but it fails with the same error that building Seti on the Pi fails with (Already fixed in the Debrian tree):

/usr/bin/ld: error: seti_boinc uses VFP register arguments, analyzeFuncs_neon.o does not
/usr/bin/ld: failed to merge target specific data of file analyzeFuncs_neon.o
/usr/bin/ld: error: seti_boinc uses VFP register arguments, analyzeFuncs_vfp.o does not
/usr/bin/ld: failed to merge target specific data of file analyzeFuncs_vfp.o
collect2: error: ld returned 1 exit status
make[2]: *** [seti_boinc] Error 1
make[2]: Leaving directory `/home/linaro/seti_boinc/client'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/linaro/seti_boinc'
make: *** [all] Error 2
linaro-nano:~/seti_boinc>

I'll try the AKv8 sources next, but don't have much confidence that i'll make any more progress.

Claggy

49

General Discussion / Re: Parallella: A Supercompute...

Last post by Claggy - May 06, 2014, 08:28:41 PM

Mine have arrived.

Claggy

Yay toys   how long till you can crack those puppies open and hopefully get GCC running ? Command line only, or some desktop GUI?  Will it build base and core wxwigdets libraries ?

Well, I've been building Boinc 7.2.4x on the Pi for a couple of months, so once I've got them built into their cases with sufficient cooling (the Zynq-7020 runs hot and must have a heatsink and fan) that won't be long,
there are Ubuntu and Debian images out there or the Parallella, so there is a GUI, I have been getting wxwidgets libs from the repository on the Pi, not been building them.
On the Pi side I've tried compiling a Stock Set app for it but it fails with an error, (already fixed in the Debian source, but not the seti source), can't compile AKv8 ethier, one, all the files that need to be executed
don't that the execution bit set, so they need to be manually set before doing autosetup, etc, two, the compilation, or the make fails with an error, once I have the parallella built i'll report back,
(I've already posted about it at Lunatics), I forget the exact errors, compiling the Stock Seti app shouldn't be a problem on the Parallella like it is on the Pi.

Been running two SDCards with Raspbian Wheezy and Sid on them, Wheezy didn't have a recent Seti app in it, it was a 5.xx app, but after a post on the forums it now has 6.97,
I've not run that app yet, have tried running the Daniel Carrion 7.00 port, that is very slow, times for Wu completion are on the 800 hour scale, and I haven't managed to complete a Wu yet,
On Raspbian Sid we have there is 6.19 svn5051-2 app, this has the more recent optimisations as is a lot faster, some thing like 150 hours a Wu, BUT, not all Wu's completed have come out valid,
Gianfranco Costamagna reports his first Wu on his AMD64 host also was invalid, probably not something to do with arm v6 with vfp, more to do with the repository way of running apps,
or compilation choices, I also have no way of benching repository apps, they can't seem to be run on their own in my home directory like I could with the Daniel Carrion apps (no Arm bench program)

On the Parallella, I have four microSD cards, One of them I've loaded with ubuntu-14.01-lxde but I'm unsure if it was done correctly and if it'll work,
I had file permission errors when I tried writing it, and had to reset the permissions, then force it to get it to write, (I'm still a Linux Noob, and might have got the device name wrong),
I'll try again with the supplied cards, to build the parallella's I need to assemble the third party cases I bought and do a bit of soldering, need to find a bit of wire for the shorting link first.
(I also have the Stock supplied cases from adapteva, five extra small blue heatsinks and loads of extra M3 Nylon bits and pieces, and tags that I bought separate in preparation for making the ABOpen case,
also a fan for the Pi in medium speed spec, (as opposed to the ABopen's kit's hi speed spec fan), need to drill it's case, and find 5volt points on the Pi for it yet)

Claggy

50

General Discussion / Re: Parallella: A Supercompute...

Last post by Jason G - May 06, 2014, 01:10:55 PM

Mine have arrived.

Claggy

Yay toys   how long till you can crack those puppies open and hopefully get GCC running ? Command line only, or some desktop GUI?  Will it build base and core wxwigdets libraries ?