log in |
61)
Message boards :
Number crunching :
Sudden credit loss
(Message 5682)
Posted 22 Feb 2020 by Dirk Broer Thanks for all the good work, rebirther! |
62)
Message boards :
Number crunching :
Sudden credit loss
(Message 5666)
Posted 22 Feb 2020 by Dirk Broer I would hope Bok at Free-DC would be able to give you the delta values from the last good stats to what was lost. The total scores that you corrected are given in user.gz, the sub-project scores that hopefully can be corrected too are given in user_work.gz. Bok of FreeDC has the data you need, I hope. He can show today what you lost yesterday per subproject on your usersubprojects page. |
63)
Message boards :
Number crunching :
Sudden credit loss
(Message 5653)
Posted 22 Feb 2020 by Dirk Broer I would hope Bok at Free-DC would be able to give you the delta values from the last good stats to what was lost. Any chance of getting the lost SRBase data restored too? And please note that our subproject credits are still not re-adjusted, hopefully Bok has those too. |
64)
Message boards :
Number crunching :
Sudden credit loss
(Message 5641)
Posted 21 Feb 2020 by Dirk Broer My credit went down some 60k in one manual update, from 9,864,194 to 9,805,814 ? |
65)
Message boards :
Number crunching :
Raspberry Pi
(Message 2496)
Posted 18 Apr 2016 by Dirk Broer RaspberryPi has this http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0301h/index.html (section 1.5.9) In the meantime the Raspberry Pi 2 has come out, using an ARM Cortex-A7 with ARMv7 architecture/instruction set and that has been followed by the Raspberry Pi 3, using an ARM Cortex-A53 with ARMv8 architecture/instruction set. Biggest problem for the Raspberry as a crunching platform is the small amount of RAM: 1 GB. |
66)
Message boards :
Number crunching :
Feeder not running
(Message 2330)
Posted 2 Feb 2016 by Dirk Broer 3-2-2016 00:37:47 | SRBase | update requested by user 3-2-2016 00:37:51 | SRBase | Sending scheduler request: Requested by user. 3-2-2016 00:37:52 | SRBase | Scheduler request completed 3-2-2016 00:37:52 | SRBase | Server error: feeder not running |
67)
Message boards :
Number crunching :
Too long calculation for the Sierpinski/Riesel Bases - long
(Message 1641)
Posted 9 Jul 2015 by Dirk Broer Ever watched in the debugger whether an AMD CPU actually uses the AVX part of the code? the Intel compiler-made Assembly seeks a when running on a non-Intel CPU. Well, Mr. Frankhagen, just for you: the same Motherboard (ASUS AM1I-A), SOC (AMD Athlon 5350) and amount of memory (16GB), plain install of OS and BOINC, nothing further: Under Windows 10 Under Linux Look especially at the given integer performance.... How do you explain that, other than with AMD systems being artificially crippled by compilers and/or libraries favouring Intel? An Intel CPU or SOC does no give this dramatical differences -in fact almost none at all. |
68)
Message boards :
Number crunching :
Too long calculation for the Sierpinski/Riesel Bases - long
(Message 801)
Posted 29 Jan 2015 by Dirk Broer That's not completely true. It is true for those CPUs that are based upon the Bulldozer architecture -The FX series CPUs and Opterons based upon the same archtecture and the Trinity, Richland and Kaveri APUs. It is not true for Llano (still K10 based) and not true for the AM1 SOCs (Jaguar based). Most amazing in the floating point vs Integer discussion is the BOINC benchamrks for the APUs: A8-3870K (Llano, 1st generation APU), running Ubuntu 13.10, benchmarks via BOINC Manager: 2461 floating point MIPS (Whetstone) per CPU 15793 integer MIPS (Dhrystone) per CPU This Llano is made out of four K10 cores, each having both a FPU (Floating Point Unit) and an ALU (Arithmetic Logic Unit) A10-5700 (Trinity, 2nd generation APU), running Lubuntu 13.10, benchmarks via BOINC Manager: 2450 floating point MIPS (Whetstone) per CPU 9513 integer MIPS (Dhrystone) per CPU This Trinity is made out of two Piledriver modules, each having two integer cores and a shared floating point unit. For some reason the integer performance of Bulldozer, Piledriver -and now Steamroller too- leaves much to be desired as compared to the older K10 integer units....and quite a lot of BOINC projects make heavy use of the integer performance of your CPU core(s). It almost looks like a Bulldozer module isn't made out of two integer cores and a shared floating point unit, but the other way around: Two floating point units and a shared integer unit! |
69)
Message boards :
Number crunching :
Too long calculation for the Sierpinski/Riesel Bases - long
(Message 791)
Posted 28 Jan 2015 by Dirk Broer Perhaps interesting to observe, AMD-performance wise: I've run the Sierpinski/Riesel Base - long so far on five AMD systems, in order of architectural age: [1.] Three using FM1 APUs (A8-3820, 3850 and 3870K), K10 based, four discrete cores (no shared resources), not using AVX. [2.] One using a FM2 A10-5700 APU, Piledriver based, two Bulldozer modules that feature two integer units and one floating point unit each, using AVX. [3.] One using an AM1 Athlon 5350 SOC, Jaguar based, four discrete cores (no shared resources), using AVX (amongst others).
[1.] 58,000-68,000 sec. [2.] 85,000 sec. [3.] 150,000 sec.
|
70)
Message boards :
Number crunching :
Too long calculation for the Sierpinski/Riesel Bases - long
(Message 790)
Posted 28 Jan 2015 by Dirk Broer You claim AMD's way of implementing and cite the architecture of the FX and present Opteron CPUs "they have a single AVX ALU for each pair of CPU cores", while I have problems with the performance of my AM1 Athlon, using the Jaguar architecture that does *NOT* share its ALUs with other cores. I just want to know wheter the present application really uses the AM1 Athlon's architecture to the fullest and therefore asked whether you have run an AM1 Athlon through the dubugger to see if AVX is used or not. |
71)
Message boards :
Number crunching :
Too long calculation for the Sierpinski/Riesel Bases - long
(Message 784)
Posted 28 Jan 2015 by Dirk Broer Ever watched in the debugger whether an AMD CPU actually uses the AVX part of the code? According to Agner Fog the Intel compiler-made Assembly seeks a different, inferior path when running on a non-Intel CPU. I wouldn't be surprised that there is no difference as compared to SSE4 because it is the exact same code that has been running. Who wrote the MicroSoft compiler actually? |
72)
Message boards :
Number crunching :
Too long calculation for the Sierpinski/Riesel Bases - long
(Message 781)
Posted 28 Jan 2015 by Dirk Broer The massive difference is due to the AVX instruction set in the intel cpu's. You will see the same result if you crunch on Primegrid. NeoAtP The massive difference could very well be due to the use of code that excludes CPUs of other make than Intel from using the afore mentioned AVX instruction set. AVX is included in all current AMD CPUs, with the exeption of the FM1 APUs (Llano). All AM3+, FM2, FM2+, AM1 and FT3 CPUs, APUs and SOCs can use AVX. |
73)
Message boards :
Number crunching :
Too long calculation for the Sierpinski/Riesel Bases - long
(Message 778)
Posted 27 Jan 2015 by Dirk Broer Nothing wrong with the instruction set of the Athlon 5350...it includes AVX (but when the application is compiled using an Intel compiler it may not be able to use it because the Intel compiler checks on vendor string instead of capabilities). |
74)
Message boards :
Number crunching :
Too long calculation for the Sierpinski/Riesel Bases - long
(Message 770)
Posted 27 Jan 2015 by Dirk Broer Want to see long calculation time? My Athlon 5350 (AM1 socket) 3979288 1186 22 Jan 2015, 16:41:56 UTC 26 Jan 2015, 13:24:00 UTC Voltooid en gecontroleerd 167,366.05 159,487.70 1,100.00 Sierpinski / Riesel Base - long v0.01 Most of the times it is not finished before the deadline, it takes more than 40 hours to calculate the long WUs... |
75)
Message boards :
Number crunching :
Raspberry Pi
(Message 621)
Posted 12 Jan 2015 by Dirk Broer RaspberryPi has this http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0301h/index.html (section 1.5.9) And the RaspberryPi just has to do with a ARMv6 CPU. BananaPi and others based upon the Allwinner A20 SOC do it with an ARMv7, which is more powerful. |
76)
Message boards :
Number crunching :
Raspberry Pi
(Message 582)
Posted 9 Jan 2015 by Dirk Broer Fair enough: http://www.arm.com/products/processors/technologies/vector-floating-point.php |
77)
Message boards :
Number crunching :
Raspberry Pi
(Message 578)
Posted 9 Jan 2015 by Dirk Broer Did I anywhere said "current ARM CPU" in my message? |
78)
Message boards :
Number crunching :
Raspberry Pi
(Message 573)
Posted 9 Jan 2015 by Dirk Broer The LLR application uses "gwnum code". This code is written for INTEL processors. Therefore you cannot compile the LLR application for ARM based OS's ..... until there is "gwnum code" available for ARM processors. "gwnum code" is *NOT* written for Intel CPUs but for CPUs using the x86 and x86-64 archtecture, so AMD CPUs and VIA CPUs can be used ass well. And as Arthur C. Clarke once said: "Any sufficiently advanced technology is indistinguishable from magic". The mere fact that NOW there is no arm-design that is IEEE 754 compatible says nothing about the future. We are just waiting for a programmer to eable it, one way or another. |