In another thread, several Setizen's have been discussing the need for a new generation of Windows developers to provide additional development and troubleshooting for Windows-based gpu and cpu applications.

It may break down into four focuses.

Windows-based cpu work that takes advantage of the AVX ops that are now available in both Intel and Amd cpus.

Windows-based GPU work to migrate the ideas tested under Linux with the Petri/Tbar AIO. This is a non-trivial challenge based on what I have read. This is specific to the Nvidia gpu.

Windows-based GPU work to re-design and re-develop Amd tasks to allow the newest generations of Amd GPUs to become competitive in processing speeds with Nvidia.

Windows-based GPU work for the Intel discrete video cards that are on the horizon.

Tom

---

A proud member of the OFA (Old Farts Association).

For me, the first question(s) I have are?

1) A low-cost but supportive Windows development environment?
2) What are the target languages? C, C++. C#. Python, Assembler?
3) What is a good starting point for gaining some basic competence that will allow a programmer to read/understand the code?

Where exactly is the developer community for Seti@Home? There are references to the developer community on the Seti@Home developer community on this website. But "where are they"?

I do have a Windows 10 box with an under-utilized HD which given that it has two Nvidia GPUs and an Amd 2600 CPU, should be stout enough to both process Boinc/Seti@Home/WCG tasks and let me begin to try to get my head around becoming a Seti@Home developer.

I also have an elderly/small/slow Intel cpu box that I could finish resurrecting for regression testing. And a late model I3 with 2 cores and hyperthreading. So I probably have sufficient test hardware for at least 1 or 2 of the focuses I have proposed.

Tom

---

A proud member of the OFA (Old Farts Association).

This is a very welcome proposal, and I certainly support it - including financially, if it requires a special fundraiser in due course.

But I think we should define our terms more closely.

I speak as a (now retired) Windows developer, towards the bottom end of the scale. But SETI's needs are rather different from the utilitarian office automation programs I was involved in.

SETI's primary needs are for complex, accurate, and fast mathematics. The "Windows" part of the code is actually quite trivial, because the SETI applications don't have any on-screen user interface: screen design and layout took up most of my time when I was programming. Most of the actual computational grunt in my programs had been written for MS-DOS before Windows hit the mass market, and I could bring it behind the Windows front-end wholesale.

And the same is true for SETI. Our actual scientific code has been evolving since 1999, and most of the pips have been squeezed out of it already. There is accepted, proven, code already in existence. The toughest part for a new programmer will probably be to learn their way around the somewhat complex spaghetti of previous code, and decide what to keep and what to throw away. It will be especially important to keep the 'accuracy' components which have been improved over the years: unless any new application adheres to the same standards of accuracy as the existing apps, the results will not validate and the app will be discarded.

Where exactly is the developer community for Seti@Home?

All over the place - from San Francisco to Australia via Russia. A starting point is the 'authors' file distributed with all app versions under the GNU General Public License. Here's the one I circulated in the Lunatics installer:

Authors of SETI@home:
Eric J. Korpela <korpela at ssl.berkeley.edu>
Jeff Cobb <jeffc at ssl.berkeley.edu>
Matt Lebofsky <mattl at ssl.berkeley.edu>
David Anderson <davea at ssl.berkeley.edu>
Charlie Fenton <cf at cfenton.com>
Rom Walton <rwalton at ssl.berkeley.edu>
Tetsuji Rai <t-rai at umin.ac.jp>
Eric Heien
Hiram Clawson
Alex Kan <alexkan at tbp.berkeley.edu> 
Ben Herndon
Josef Segur RIP
Simon Zadra
Jason Groothuis
Raistmer

Additional authors of Astropulse:
Joshua Von Korff <vonkorff at ssl.berkeley.edu>
Paul Demorest <demorest at astro.berkeley.edu>

CUDA development by:
Przemyslaw Zych (NVIDIA)
Scott Le Grand (NVIDIA)
Bob Johnston (NVIDIA)

OpenCL development by:
Raistmer
Urs Echternacht
Frizz

Authors of FFTW (reachable at fftw at fftw.org):
Matteo Frigo <athena at fftw.org>
Stevenj G. Johnson <stevenj at alum.mit.edu>
Stefan Kral <skral at fftw.org> wrote genfft-k7/*.ml*

Authors of fft8g.[cpp,h]:
Takuya Ooura <ooura at kurims.kyoto-u.ac.jp>
Eric J. Korpela <korpela at ssl.berkeley.edu>
Jeff Cobb <jeffc at ssl.berkeley.edu>

Author of ASMLIB:
Agner Fog

Porting and/or Optimized Source Code:
Josef Segur RIP
Jason G
Raistmer
JDWhale
Urs Echternacht
with support of Lunatics.kwsn.info team.

To which should now be added Petri33, TBar, and possibly others.

Notice, in particular, that none of the GPU coders have an ssl.berkeley.edu email address. The project has never had the reserve of personnel needed to take that skill in-house. Although I'm sure Eric will consider and accept volunteer contributions with open arms, he can't actually help any programmer with the GPU practicalities. That has to come from the outside, or from the volunteer's own previous experience.

I'm not too sure about the environment, but I think it is a version of MS Visual Studio. While any development environment should work and should produce code that ends up with the same accuracy as the stock applications I know from bitter experience this is not always the case. Again, from memory, much of the code is C and C++ possibly with a little bit of assembly for some of the library routines. That lot will give you the CPU application, but nothing for any GPUs. For the GPUs you will need to add the to that the appropriate GPU development toolkits (CUDA and OpenCL at the very least).
One thing to note is that not every "Windows programmer" has the necessary knowledge to work on a scientific calculation, and SETI is near the fore-front of signal analysis. That said we have been very fortunate over the years with the likes of Joe, Jason Raistmer and the others Richard lists who have been able to cross the boundaries with great effect.

---

Bob Smith
Member of Seti PIPPS (Pluto is a Planet Protest Society)
Somewhere in the (un)known Universe?

2) What are the target languages? C, C++. C#. Python, Assembler?

I thought compiled-Python and/or Rust were the hot science languages of favour at the moment?


Happy fast crunchin',
Martin

---

See new freedom: Mageia Linux
Take a look for yourself: Linux Format
The Future is what We all make IT (GPLv3)

I thought compiled-Python and/or Rust were the hot science languages of favour at the moment?

They might be if you were starting a new project from scratch, but if you're trying to extend the existing SETI project, you would have to be able at least to read and translate the existing C++ code. Also, I haven't a clue if those languages can be integrated with the CUDA and OpenCL toolkits.

The scientific work done at Berkeley back with SETI Classic in 1999 was almost certainly done on Linux with the royalty-free GPL compilers. Jason did for a while supply apps compiled with the commercial Intel compiler (and damn fine apps they were too), but the licence terms were incompatible with GPL and they were withdrawn.

It's probably worth adding "familiar with Open Source programming conventions and obligations" to the job description.

And the same is true for SETI. Our actual scientific code has been evolving since 1999, and most of the pips have been squeezed out of it already. There is accepted, proven, code already in existence. The toughest part for a new programmer will probably be to learn their way around the somewhat complex spaghetti of previous code, and decide what to keep and what to throw away. It will be especially important to keep the 'accuracy' components which have been improved over the years: unless any new application adheres to the same standards of accuracy as the existing apps, the results will not validate and the app will be discarded.

I think one of the harder parts will be learning how to dig through the code. I minored in CS, and I put comments everywhere, basically explaining every step along the way. I've casually browsed through the BOINC code (I know, its different than Seti), and I haven't been able to find many comments in the code, if at all. I'm also having a hard time seeing how some of the code is divided in different directories, and what that all means. Now, I've only browsed briefly, so I could be missing something. I'm also willing to concede that my CS knowledge is minimal, and since I haven't practiced in fifteen years, I may not have the foggiest idea what I am doing.

The point that I'm leading to is if the reality is that the code isn't well documented, perhaps that is the first step? I could see that being a benefit for both new and experienced coders.

---

Seti@home classic: 1,456 results, 1.613 years CPU time

Maybe I need to turn towards "machine learning" to do the heavy lifting while I just pour in the electricity?

---

A proud member of the OFA (Old Farts Association).

Here is a question.

Would it be useful if a Seti@Home CPU/gpu task could run in the tab of a Windows web browser? Perhaps.

You wouldn't really "install" anything but you would have to a Seti@Home userid.

The possibility of doing something like this came up because I remember reading about bitcoin (type) processing being stolen via Web browser installed Malware. So it should be possible, with permission, to do the same easier to install with Seti@Home?

Tom

---

A proud member of the OFA (Old Farts Association).

Lots of people talk about "machine learning" as a way of solving a problem, but first one has to teach the machine how to learn about the particular problem, and that means defining the problem in a manner that the machine can understand, which is no easy task. Thus more a case of pour the money in to teach the machine so you can pour the money in to rent the machine to do what is being done today.

---

Bob Smith
Member of Seti PIPPS (Pluto is a Planet Protest Society)
Somewhere in the (un)known Universe?

Are you suggesting that one uses a web browser to act as the interface between the servers and the application or what?
I think you are suggesting something that acts as the application, which is something that web browsers are very poor at doing - just think, you would have to have that tab/window open all the time one wanted to process data, and then be working through an API that isn't really designed to do such things. Also there is the issue of which browsers and operating systems are going to be supported.
It would be far better to concentrate on getting the most from the Windows application before diving off into all the complexities of trying to get other computer infrastructures working.

---

Bob Smith
Member of Seti PIPPS (Pluto is a Planet Protest Society)
Somewhere in the (un)known Universe?

Are you suggesting that one uses a web browser to act as the interface between the servers and the application or what?
I think you are suggesting something that acts as the application, which is something that web browsers are very poor at doing - just think, you would have to have that tab/window open all the time one wanted to process data, and then be working through an API that isn't really designed to do such things. Also there is the issue of which browsers and operating systems are going to be supported.
It would be far better to concentrate on getting the most from the Windows application before diving off into all the complexities of trying to get other computer infrastructures working.

Since I haven't really studied exactly how that Malware ran on the computer it was stealing from I assumed that something where you kept your browser engaged might be an "easier" install?

Oh, well. Back to the "learn how to program in C/C++ in Windows mine".

Tom

---

A proud member of the OFA (Old Farts Association).

Now if I remember right I heard two things.
1) The cpu tasks for windows are pretty much optimized as far as they can (subject to no massive change in cpu architecture).
2) Gpu programming for windows is VERY tricky.

But how hard would it be to do cpu programming on the Android OS?

We have ample evidence that the Seti@Home app for Android will not run on late model Android OS's.

So what about doing cpu programming on the Android?

Tom

---

A proud member of the OFA (Old Farts Association).