Posts by ebahapo

21) Message boards : Number crunching : app v12 (Message 8779) Posted 20 Jan 2009 by ebahapo Post: along with the fact that you don't leave much history in the database (I know, other problems, but it makes it hard to go back and calculate a real time average) ... Indeed. I wish that Travis would increase the time that a WU lingers on at least while all these tests are being made. TIA
22) Message boards : Application Code Discussion : Recompiled Linux 32/64 apps (Message 8756) Posted 20 Jan 2009 by ebahapo Post: It seems they don't run well on AMD, so it might better for AMD users to try a testfile in standalone mode --> look here Well, of course not. The Intel compiler runs degraded code when run on AMD processors. The highest SSE level that it runs on AMD processors is SSE2. HTH
23) Message boards : Number crunching : app v12 (Message 8755) Posted 20 Jan 2009 by ebahapo Post: Other hint for compiling : I doubt that my old Opteron (server version of the socket 939 Athlon 64 x2) could beat my Quad 6600 (both @ stock clock). I know, architecture are not the same, but the gap is not normal. The Linux 64 version lacks optimizations. The problem is that Intel has ignored GCC and has not contributed to its development until recently. In particular, up to GCC 4.1, Intel had not contributed a single line of code to it. Intel finally started contributing for GCC 4.2, but only enough to make catch up with AMD processors. In other words, up to GCC 4.1, the x86-64 compiler is pretty much tuned for AMD processors. From 4.2 and on, the outcome is more balanced, with barely any difference when run on either Intel or on AMD processors. Of course, your mileage may vary from application to application. HTH
24) Message boards : Application Code Discussion : source v11 released (Message 8678) Posted 19 Jan 2009 by ebahapo Post: I see a problem at line 16: -O here will undo -O2 later on. It's not necessary to specify SSE2 for x86-64 because it's the default and since x87 doesn't support vectors, it's useless to specify -ftree-vectorize for x86. May I propose this patch against make.linux? --- makefile 2009-01-19 14:40:07.085583200 -0600 +++ make.linux 2009-01-19 14:54:06.593926700 -0600 @@ -13,17 +13,17 @@ VARIANTFLAGS = -DGMLE_BOINC -DBOINC_APP_ CXXFLAGS_ALL = $(VARIANTFLAGS) \ -funroll-loops \ -g \ - -O \ -I$(BOINC_DIR) +LDFLAGS_ALL = -static-libgcc CXX_i686 = g++ -CXXFLAGS_i686 = -m32 -O2 -ftree-vectorize $(CXXFLAGS_ALL) -LDFLAGS_i686 = -L/usr/X11R6/lib -L../../linux32_libboinc +CXXFLAGS_i686 = -m32 -O2 $(CXXFLAGS_ALL) +LDFLAGS_i686 = -L/usr/X11R6/lib -L../../linux32_libboinc $(LDFLAGS_ALL) #LDFLAGS_i686 = -L$(BOINC_LIB_LINK_DIR) -L$(BOINC_API_LINK_DIR) CXX_x86_64 = g++ -CXXFLAGS_x86_64 = -O2 -msse2 -ftree-vectorize $(CXXFLAGS_ALL) -LDFLAGS_x86_64 = -L/usr/local/lib +CXXFLAGS_x86_64 = -O2 -ftree-vectorize $(CXXFLAGS_ALL) +LDFLAGS_x86_64 = -L/usr/local/lib -static $(LDFLAGS_ALL) #LDFLAGS_x86_64 = -L/usr/local/lib -L/usr/X11R6/lib #LDFLAGS_x86_64 = -L$(BOINC_LIB_LINK_DIR) -L$(BOINC_API_LINK_DIR) @@ -59,12 +59,12 @@ all: $(PROGS) app_i686: OBJ_CXX = $(CXX_i686) app_i686: OBJ_CXXFLAGS = $(CXXFLAGS_i686) app_i686: $(APP_OBJS) $(SEARCH_OBJS) $(UTIL_OBJS) $(BOINC_API_LINK_DIR)/libboinc_api.a $(BOINC_LIB_LINK_DIR)/libboinc.a - $(CXX_i686) $(LDFLAGS_i686) $(CXXFLAGS_i686) -Wl --export_dynamic -o milkyway_$(APP_VERSION)_i686-pc-linux-gnu $(APP_OBJS) $(SEARCH_OBJS) $(UTIL_OBJS) -lm -lboinc_api -lboinc -pthread + $(CXX_i686) $(LDFLAGS_i686) $(CXXFLAGS_i686) -o milkyway_$(APP_VERSION)_i686-pc-linux-gnu $(APP_OBJS) $(SEARCH_OBJS) $(UTIL_OBJS) -lm -lboinc_api -lboinc -pthread app_x86_64: OBJ_CXX = $(CXX_x86_64) app_x86_64: OBJ_CXXFLAGS = $(CXXFLAGS_x86_64) app_x86_64: $(APP_OBJS) $(SEARCH_OBJS) $(UTIL_OBJS) $(BOINC_API_LINK_DIR)/libboinc_api.a $(BOINC_LIB_LINK_DIR)/libboinc.a - $(CXX_x86_64) $(LDFLAGS_x86_64) $(CXXFLAGS_x86_64) -Wl -static -static-libgcc -o milkyway_$(APP_VERSION)_x86_64-pc-linux-gnu $(APP_OBJS) $(SEARCH_OBJS) $(UTIL_OBJS) -lm -lboinc_api -lboinc -pthread + $(CXX_x86_64) $(LDFLAGS_x86_64) $(CXXFLAGS_x86_64) -o milkyway_$(APP_VERSION)_x86_64-pc-linux-gnu $(APP_OBJS) $(SEARCH_OBJS) $(UTIL_OBJS) -lm -lboinc_api -lboinc -pthread .C.o: $(OBJ_CXX) $(OBJ_CXXFLAGS) $(INC) -Wall -x c++ -c $< -o $@ HTH
25) Message boards : Application Code Discussion : milkyway code license (Message 8619) Posted 18 Jan 2009 by ebahapo Post: I dislike the way that GPL is going with v3 (even Linus Torvalds stayed away from it), favoring instead the Apache or the Modified BSD. For more info, see http://www.gnu.org/licenses/license-list.html. HTH
26) Message boards : Number crunching : Vote for the MilkyWay favicon! (Message 8197) Posted 5 Jan 2009 by ebahapo Post: #9
27) Message boards : Number crunching : post milkyway_i686-pc-linux-gnu problems here (Message 7978) Posted 24 Dec 2008 by ebahapo Post: My Linux boxen have always run at full speed for many years and there is no throttling at all. Your "boxen" have up-to-date processors and kernel, so you should be able to type "powersave -r" from the command-line when the system is idle to check the effective CPU frequency. Most current standard Linux set ups come with default power management that's more sophisticated than old throttling. HTH
28) Message boards : Number crunching : post milkyway_i686-pc-linux-gnu problems here (Message 7797) Posted 16 Dec 2008 by ebahapo Post: Just curious (and this has probably been stated before, maybe even by me in a thread I can't find), why does my Linux Opteron 285 machine take over 10 minutes longer to process a MilkyWay work unit than my Windows Opteron 285 machine ??? On average my Windows machine takes around 2,600 seconds but my Linux box takes around 3,300 seconds. They are the same specifications bar different hard drives. Is it just a compiling thing, as in a compiler more suited to Linux might change things ?? True, different compilers, different results. But most importantly, Linux keeps the CPU at the lowest frequency when just running low-priority BOINC applications, whereas Windows throws the CPU at the highest frequency for them too. See more details here. HTH
29) Message boards : Number crunching : post milkyway_windows_intelx86 problems here (Message 7512) Posted 6 Dec 2008 by ebahapo Post: It seems that the application remains in memory after the WU is finished, confirmed by BoincView which shows the system running other projects, not Milkyway any longer. TIA
30) Message boards : Number crunching : post milkyway_i686-pc-linux-gnu problems here (Message 7433) Posted 4 Dec 2008 by ebahapo Post: ... which you don't want to use unless you don't care about losing those systems with a Pentium III or an Athlon XP. I got some statistics about this based on POEM's volunteer Linux systems: 13% support only SSE1, 70% support up to SSE2 and 17% support up to SSE3. More details here. HTH
31) Message boards : Number crunching : post milkyway_i686-pc-linux-gnu problems here (Message 7432) Posted 4 Dec 2008 by ebahapo Post: - you must remove the lone -O or it will turn off the optimizations you wanted from -O2. - you don't need -Wl -static before -static-libgcc. - move -Wl,-Bstatic `gcc -print-file-name=libstdc++.a` -Wl,-Bdynamic to right before -lm or at the end of the command-line. I should add that you don't -msse2 either. That's because for 32 bits it's innefective without -mfpmath=sse, which you don't want to use unless you don't care about losing those systems with a Pentium III or an Athlon XP. Finally, -msse2 is implied for 64 bits, as well as -mfpmath=sse. However, since all x86-64 systems are required to have SSE2, you can also enable -ftree-vectorize (which is implied in -O3 for GCC 4.3 and later) when building the application for such systems. HTH
32) Message boards : Number crunching : post milkyway_windows_intelx86 problems here (Message 7431) Posted 4 Dec 2008 by ebahapo Post: Now, in the applications section from the home page, says that the current app for windows is the 0.07 but attaching a new computer the project downloads 0.06. That's because there are probably WUs in the queues which were created when 0.6 was the latest version. As these drain out, those WUs created for 0.7 should kick in. HTH
33) Message boards : Number crunching : post milkyway_i686-pc-linux-gnu problems here (Message 7391) Posted 3 Dec 2008 by ebahapo Post: - you must remove the lone -O or it will turn off the optimizations you wanted from -O2. - you don't need -Wl -static before -static-libgcc. - move -Wl,-Bstatic `gcc -print-file-name=libstdc++.a` -Wl,-Bdynamic to right before -lm or at the end of the command-line. IOW: g++ -L/usr/local/lib -O2 -msse2 -ftree-vectorize -funroll-loops -DGMLE_BOINC -g -I/software/boinc-6.3.14-0/pkg/include/boinc -static-libgcc -o milkyway_0.7_x86_64-pc-linux-gnu ../astronomy/boinc_astronomy.o ../astronomy/atSurveyGeometry.o ../astronomy/numericalIntegration.o ../astronomy/parameters.o ../astronomy/probability.o ../astronomy/stCoords.o ../astronomy/stCnum.o ../astronomy/stMath.o ../astronomy/stVector.o ../astronomy/star_points.o ../astronomy/evaluation_optimized.o ../astronomy/evaluation_state.o ../searches/search_parameters.o ../util/io_util.o ../util/settings.o -Wl,-Bstatic `gcc -print-file-name=libstdc++.a` -Wl,-Bdynamic -lm -lboinc_api -lboinc -pthread Or: g++ -L/usr/local/lib -O2 -msse2 -ftree-vectorize -funroll-loops -DGMLE_BOINC -g -I/software/boinc-6.3.14-0/pkg/include/boinc -static-libgcc -o milkyway_0.7_x86_64-pc-linux-gnu ../astronomy/boinc_astronomy.o ../astronomy/atSurveyGeometry.o ../astronomy/numericalIntegration.o ../astronomy/parameters.o ../astronomy/probability.o ../astronomy/stCoords.o ../astronomy/stCnum.o ../astronomy/stMath.o ../astronomy/stVector.o ../astronomy/star_points.o ../astronomy/evaluation_optimized.o ../astronomy/evaluation_state.o ../searches/search_parameters.o ../util/io_util.o ../util/settings.o -lm -lboinc_api -lboinc -pthread -Wl,-Bstatic `gcc -print-file-name=libstdc++.a` -Wl,-Bdynamic HTH
34) Message boards : Number crunching : post milkyway_i686-pc-linux-gnu problems here (Message 7388) Posted 3 Dec 2008 by ebahapo Post: The new version of the linux binaries should have llibstdc and libstdc++ linked statically as per the above instructions (i hope). Let me know how they work out. No dice: $ ldd ~/milkyway_0.7_* milkyway_0.7_i686-pc-linux-gnu: linux-gate.so.1 => (0xffffe000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x5556d000) libm.so.6 => /lib/tls/libm.so.6 (0x55661000) libpthread.so.0 => /lib/tls/libpthread.so.0 (0x55683000) libc.so.6 => /lib/tls/libc.so.6 (0x55694000) libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x557ae000) /lib/ld-linux.so.2 (0x55555000) milkyway_0.7_x86_64-pc-linux-gnu: libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00002b2f8cbb7000) libm.so.6 => /lib64/tls/libm.so.6 (0x00002b2f8cdb4000) libpthread.so.0 => /lib64/tls/libpthread.so.0 (0x00002b2f8cf0c000) libc.so.6 => /lib64/tls/libc.so.6 (0x00002b2f8d020000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00002b2f8d248000) /lib64/ld-linux-x86-64.so.2 (0x00002b2f8caa0000) As you can see, libstdc++, libc and libgcc are still being dynamically linked. Since you're having some trouble, try static linking by specifying the GCC option -static then. HTH
35) Message boards : Number crunching : post milkyway_i686-pc-linux-gnu problems here (Message 7292) Posted 2 Dec 2008 by ebahapo Post: Maybe that's the problem. Should there be any problems with the linux app if i link everything statically? Hardly, but instead of such a brute-force approach, it's not that difficult to link only selected libraries statically. HTH
36) Message boards : Number crunching : post milkyway_i686-pc-linux-gnu problems here (Message 7287) Posted 2 Dec 2008 by ebahapo Post: Uh... If he's missing libstdc++.so, he won't be able to run any programs written in C++ and dynamically linked, which is impossible. More than likely, this is a problem with that the MilkyWay app is dynamically linked when it should statically linked. Travis? Actually, more than likely he has an older version of the library, probably libstdc++.so.5. Here's how to link that library statically: http://milkyway.cs.rpi.edu/milkyway/forum_thread.php?id=488&nowrap=true#6784. HTH
37) Message boards : Number crunching : post milkyway_i686-pc-linux-gnu problems here (Message 7174) Posted 1 Dec 2008 by ebahapo Post: I'll give it a shot. Although I'm not sure why you wouldn't want to update your gcc.... :P Simply because they're production systems for which I don't have root access. Thanks.
38) Message boards : Number crunching : post milkyway_i686-pc-linux-gnu problems here (Message 7140) Posted 1 Dec 2008 by ebahapo Post: And what with linux machines with gcc libs older than 4.2.0? Is it too much to ask that the application be linked with the GCC option -static-libgcc in order to avoid this issue? TIA
39) Message boards : Number crunching : post milkyway_i686-pc-linux-gnu problems here (Message 7138) Posted 1 Dec 2008 by ebahapo Post: AMD Opteron 285 Linux FC6....'stripe79_1' WU...3,652 sec, Op App..389 sec AMD Opteron 285 Windows XP...'stripe79_1' WU...2,837 sec, Op App..351 sec As you can see run times on near identical machines is slower with Linux. It might be because Linux manages power differently from Windows, running BOINC applications at a slow CPU frequency in order to save energy. See more details here. HTH
40) Message boards : Number crunching : post milkyway_x86_64-pc-linux-gnu problems here (Message 6821) Posted 26 Nov 2008 by ebahapo Post: I was looking for powersave options but I can't find them. I'm a Linux noob so I need "step by step" instructions. grin From the link above: However, Linux can be told to not ignore low-priority processes by setting the option POWERSAVED_CONSIDER_NICE to "yes" in /etc/powersave.conf (or in a similar file, depending on the distro). This is a better approach than disabling power management forthright. HTH

Previous 20 · Next 20