Posts by QuantumEthos

1) Message boards : Cafe : Hack4Change - robo wars - using robotics to enhance the web & cyber security - & do boinc HPC projects! (Message 1443)
Posted 4 Jun 2018 by QuantumEthos
Hack4Change - robo wars - using robotics to enhance the web & cyber security - & do boinc HPC projects!

Network,HPC - data science - configuration and recommendations (c)RS - for NGO - HPC - Universities & Schools. -
2) Message boards : Number crunching : LHC GPU Code study ! and gpu comparison. (Message 1300)
Posted 29 Jul 2017 by QuantumEthos
LHC GPU Code study ! and gpu comparison.
3) Message boards : Number crunching : boinc - enhancing research workloads for the benefit of mankind & humanity - Computer Optimisation - CPU , GPU & RAM - PC, Mac & ARM development (Message 1293)
Posted 16 Jul 2017 by QuantumEthos
boinc - enhancing research workloads for the benefit of mankind & humanity - Computer Optimisation - CPU , GPU & RAM - PC, Mac & ARM development

HPC - High Performance Computation for beneficial goals and obvious worth.

(Guide, experimentation, developer kit's and manuals)

Observing the workloads of many beneficial projects we find that commonly the workload data set is small,
In addition to the memory set being smaller or larger than a machine can compute optimally; we find that feature sets such as fae and avx have commonly not been implemented,

Some projects like asteroids at home and the seti project are using enhanced computation instruction sets ... like avx and memory loads that benefit from the 4gb or more ram that is available on decent gaming and home laptops.

Not all modern machines have loads of ram; However research and or university establishments use sufficiently powerful machines that can glow on the boinc record in full glory with a 256mb to 768mb workload,

In addition the machines are operand,xen ... commonly and servers may have such as Sparc or power pc specific hardware and instruction sets,

In order to examine examples .. below we can see workloads include small data arrays; in the 40mb to 79mb range..

In line with servers and gaming rigs .. we have 1gb of ram per core, of course not all issues require a larger array in the workload and some machines have 256mb per core !

However much Ram you allocate to the projected workload; small memory loads can and will be sufficient for data swapping and or paging (like DNA Replicators)...

Some task can sufficiently benefit from larger thread and data models, to my mind DNA and mapping data are fine examples of specific workloads; Where memory counts,

In addition thread count can be 4 or other numbers and i suggest that a single task can use more than one core and instruction set (neon for example or Symmetric threading FPU, SMT)

Specific workload optimisation, or rather generic with SSE and AVX and FPU threading and precision optimisation would be very cool while we deal with the workload running app

In particular the Ryzen multi-core is a new and exciting product,

So take care to read the guides in the lower half of the document, AVX2, RDSEED, ADX and additional encryption formats are some of the most exciting changes to the AMD Ryzen Arch.

Further thought ... Efficiency :

add a MHz/Dhrystone's/MIP'S performance per watt to each system ...
then projects will further optimise workloads to improve upon workload energy & environmental efficiency versus work carried out.

Work Hours x Mhz / (efficiency per watt)
Hours / % of projects finished with work completed

Also bear in mind that GPU's need watt efficiency and task management to optimise power used versus work done....

worker priority should always be :

efficiency + merit of the work
time / % necessity

Please examine the issue further.

Rupert S

HPC Computing work load Photos - with links - we need Chaos Seeds : Random seeds for our work - Optimizing HPC Service Delivery by a life time super computing tec - Scaling and Optimizing Climate and Weather Forecasting Programs on Sunway TaihuLight - very exciting

HPC Best Practices..

AMD Platform Optimization - please read for all developers - particular instruction differences for microcode optimisation - code optimisation a few very important lessons... may seem simple to some but obviously is not to be taken for granted. - AMD64 Architecture Programmer’s Manual Volume 2: System Programming

CPU Optimisation - utility and function. - CodeXL is a code efficiency analyser optimiser debugger for GPU and CPU and system. - CodeXL in action photos

Update 2:

for a comparison of Gflops/Mips throughput of various Boinc Tasks ..

here we show the relevance of the code or function used ... AVX for example is multi threaded ! and so is the FPU pipeline of the AMD FX & Ryzen processor..... (original non edited photos ...)

and set 2 (newer) ....

see the work throughput GFlops compared to code efficiency per task !

sometimes entropy is needed to for-fill the task one would imagine (for example on android)

the improvement of the boinc and worldcommunitygrid projects has been observed, noted and one feels improved upon, ..

further improvement should be implemented as soon as possible; To improve work versus output efficiency.

thank you kindly programmers/Workers & scientists for your perseverance & effort.


Update 3 Q & A:

"In reference to the use of virtual box there is a new product by berkley > called singularity that handles repeatable condition containers... and has low overhead for virtualisation data-set.

As to the particle spread one should possibly consider the multiple core and threaded core model specific to the Ryzen and intel sets...

One could imagine that the multi-threaded nature of arm server cores combined with the nature of multi-threaded and headed arm CPU's and GPU Run-script environments is a new and uncompromising land of opportunity and challenge.

Many of the instructions on the FMV4 and Vector instruction sets have multi-threaded en-action at lower precision..."



Eric Mcintosh accredited scientist Cern
Project administrator
Project developer
Project tester
Project scientist

"Well we are far from trying to optimise GPU code.

First let me explain that we have a tracking loop over turns
(up to 1,000,000 hoping for 10,000,000 soon) which contains
a large number of inner loops over particles, currently up to 64.

Luckily these loops over particles can be paralleled as each
particle is totally independent. In addition the original author F. Schmidt
pre-calculated everything possible before entering the tracking loop.
Each turn involves some 10,000 steps over a varying number of inner loops,
e.g. straight section, quadruple, beam-beam interaction, power supply ripple, etc etc

Of which there are about 50 different possibilities. A straight section is really just
a multiply and add, whereas beam beam involves hundreds or more FLOP's.
The first idea would be to use a much larger number of particles to best
utilise the GPU. This however would produce a large amount of I/O and
use a lot of disk space, but maybe not insurmountable,

However all the code is FORTRAN, the outer loop calls subroutines (could inline), and has many tests/branches.
It would be great if the main loop fitted entirely into the GPU and we would have
rare Host access for I/O or BOINC checkpoint and progress calls or when
one or more particles are lost.

My colleague Ricardo is actively looking at redoing in C which would also allow
much more portability and also allow to be parallel on multi-core systems.
For the moment we just run tasks in parallel, which works rather well (apart
from some current infrastructure problems). I hope to come up with
some numbers next week on GPU testing.

The code itself has been regularly measured and optimised; for example we
re-ordered array indices to optimise memory access and rewrote the Error Function
of a Complex Number to be faster but with adequate precision.

Portability does come at a price but ensures accuracy of results. I shall publish
measurements in an upcoming paper. I am sure we gain much more from being portable
and being able to use almost any IEEE 754 compliant processor.

On the issue of SixTrack and/or experiments this will shortly be under discussion at
CERN I am sure. Currently SixTrack has many more Hosts/volunteers, is simple to install,
and has been around for 13 years. Not everyone loves VMbox. Not a big deal at
present as we rarely have enough SixTrack work to keep all volunteers busy.

I hope to re-address all this in some weeks after current BOINC infrastructure issues
are resolved and we have the new "super" sixtrack with much broader application
e.g.collimation studies and we support a much wider range of platforms MacOS ARM
and use features such as AVX.



Update 4 : Virtualisation

QEMU is obviously be of use on many projects because of machine emulation and virtualisation..
Comes in flavours including Windows, Mac and Linux. - with links to SDK's and tools and photos