Thats not a license condition, but a distribution condition (technicality, but still).

And it's not where I want to go anyway :o)

---

Donate to SETI@Home via PayPal!

Optimized SETI@Home apps + Information

EricVonDaniken,

to my knowledge he bought a license, and that's how :o)

Regards,
Simon.

A= can you verify that so we are sure of what thw truth is?

B= how much does a license cost?

License is found at Intel web site - I just purchased it, cost of about $600.00 USD for the compiler, distribution, and Primatives.

---

If you want to get in touch with me (for example to get sources and instructions how to compile them), contact me at simon <insert funny sign here> zadra.org.

Regards,
Simon.

---

Donate to SETI@Home via PayPal!

Optimized SETI@Home apps + Information

License is found at Intel web site - I just purchased it, cost of about $600.00 USD for the compiler, distribution, and Primatives.

Wow!

Have one on me:



Cheers :o)

Regards Hans

---

Second that :o)

---

Donate to SETI@Home via PayPal!

Optimized SETI@Home apps + Information

I will not release stuff that I know to be taking advantage of a legal technicality (requiring people to confirm an EULA that makes them promise to use it only until trial expiration and then delete would put me in the clear, legally...but not ethically).

Sounds like that might also conflict with the GPL for the original sources, which forbids the imposition of further conditions on licensees.

<edit>Let me add that although I’m a Mac-oriented person and therefore not particularly interested in Windows or Linux optimizations, I congratulate you on the circumspect and methodical manner in which you’ve been proceeding (according to what I’ve seen ‘from the sidelines’) with respect to both testing for validity (protecting the potential scientific results) and investigating legal issues (protecting the project & its volunteers).</edit>

Thanks.

You might say recent events have somewhat influenced that, but a methodical and public approach seems best in any case. So far, there has been an amazing lack of drama, and I'd like to continue that.

Regards,
Simon.

---

Donate to SETI@Home via PayPal!

Optimized SETI@Home apps + Information

Craziness.

The best way to solve the problem is for Berekeley and/or BOINC to get the right licensing.

Frankly, I'd bet Berkeley does have a site Intel license for these tools and we just do not know it.

At this point, this is really just for us fanatics: people who are willing to do the work to load an app. that is exactly suited to the CPU.

The current alpha test version of BOINC detects the various capabilities of the processor.

Once it knows what the specific CPU can do, it can tell that to the project servers. Those servers need to know how to interpret that.

Then the project(s) can deliver applications more closely matched to the CPU.

Then it makes sense for the project to officially produce clients that use something better than a 486.

Until then, the default client has to run on almost everything.

---

I'd like to see someone try and run Linux on a 6502 cpu with 48k ram. :D ;)

Easy.

Write an emulator for a more recent CPU (ARM, etc..) and use your disk drive as main memory :o)

Just install a tiny linux distro when you're done.

Regards Hans

---

I'd like to see someone try and run Linux on a 6502 cpu with 48k ram. :D ;)

Easy.

Write an emulator for a more recent CPU (ARM, etc..) and use your disk drive as main memory :o)

Just install a tiny linux distro when you're done.

Regards Hans

Easy? It would have to be all in Machine language, As the 6502 can only address 48k of ram and was a 1.79MHz cpu.

Showing my age here... It could actually address 64K RAM native (though early machines came with a whopping 4K RAM, like the original Apple ][, not the ][+ or even the //e... LOL). The 6502 was later tricked into addressing 128K of RAM by "bank switching". It was originally a 1.00 MHz CPU, though later iterations got up to a whopping 3.6 MHz (TransWarp Accelerator).

The Apple //gs used to run a C-Shell and programming environment based on unix with a 2.8MHz 65816 (16-bit offspring of the 6502). It was called GNO, for Gno's Not Orca. It could address 8 MB RAM I believe. There was even one accessible via telnet at one point. It actually compiled and ran Mines of Moria (old text-based mapping adventure game) quite well. I solved it and killed the Balrog and thus survived to rule the Mines. But yes, number crunching of the type we do with BOINC would have been years-long ventures for a single WU, if limitations of cache and memory addressing were worked around.

---

Kung Fu and Powerlifting

Showing my age here... It could actually address 64K RAM native (though early machines came with a whopping 4K RAM, like the original Apple ][, not the ][+ or even the //e... LOL). The 6502 was later tricked into addressing 128K of RAM by "bank switching". It was originally a 1.00 MHz CPU, though later iterations got up to a whopping 3.6 MHz (TransWarp Accelerator).

The Apple //gs used to run a C-Shell and programming environment based on unix with a 2.8MHz 65816 (16-bit offspring of the 6502). It was called GNO, for Gno's Not Orca. It could address 8 MB RAM I believe. There was even one accessible via telnet at one point. It actually compiled and ran Mines of Moria (old text-based mapping adventure game) quite well. I solved it and killed the Balrog and thus survived to rule the Mines. But yes, number crunching of the type we do with BOINC would have been years-long ventures for a single WU, if limitations of cache and memory addressing were worked around.

Of course the 6502 can go to 64k, Without an OS loaded that is and the Atari 400/800 OS was about 12k, The last Atari XE could go to 128k of course, But Apple was the only company to use the 65816 cpu, Atari never thought It was worth bothering with.

;-) Just responding to the stated clock-speed and address-space. Different OSes (and langs) installed of course affected the _available_ address-space.

Th 65816 was actually arguably useful in its incarnation in the //gs - the team working on GS/OS was the first to develop a color Finder (the desktop) and countless niceties that later made their way back up the chain to be used in MacOS. What's more, since we're interested in better-optimized code, the engineering team had to do it with such a slow processor that they actually coded in assembly to hand-tweak the workings for maximum speed, since the compilers were nowhere near up to that kind of optimization. In fact they were so good at it and UI ideas, many of them were 'stolen' away from the //gs development team and made to work on Mac dev. Andy McFadden is one notable example.

Ah, the good ol' days. LOL

The "parallel path" is that if Intel's stuff really is making code that is 2-3x faster for SWAR than g++/gcc, that's a Problem the FSF compiler folks should care a great deal about.

I don't think the difference is as large as that. Simon posted these:

testWU-2 (AR: 0.4437317022742)

Windows 32-Bit

Default 5.15 with graphics
27m 37s (1657 seconds)

Crunch3r 5.12 SSE2
13m 04s (784 seconds) - 52.7% quicker

My 5.15 SSE2
13m 10s (790 seconds) - 52.6% quicker

However, note carefully that 5.15 was running with graphics. Using a -nographics command line argument would have reduced its time. Even so, since it is built with i386 code there would be a significant lag compared to builds using SSE2 optimizations. When someone makes a DevC++/MinGW SSE2 build without graphics there will be a way to compare. I'm making slow progress toward that, but it will take a couple more days to see if I reach the goal.

                                                      Joe

Simon (KWSN), I've been following your work with great interest, but I only have Athlon XPs (so, no SSE2) or higher... Any thoughts on doing SSE or 3DNow! optimized apps sometime? Or are those somehow not applicable? Thanks

---

Kung Fu and Powerlifting

Josef,

it should be noted that the tests on Linux were with a client that had no graphics and DID go faster. Hence the smaller speedup of standard vs. optimized on Linux - see my benchmark posts.

I had no graphics-less Windows version to test with, so that's why the tests used this version - which I got via BOINC, so it's the one everyone is using.

Also be aware that these times do not scale to all ARs. On some the speedup vs. unoptimized is close to 3x, so that's not entirely untrue. On average, I'd say it's about 30-50% faster on most WUs.

Regards,
Simon.

---

Donate to SETI@Home via PayPal!

Optimized SETI@Home apps + Information

Josef (and others):

Benchmark posts
That one and the next one have some results you can use to compare. They're a bit tough to find in that long thread.

Regards,
Simon.

---

Donate to SETI@Home via PayPal!

Optimized SETI@Home apps + Information

I agree, Besides a 486 is old, Maybe not as old as a 6502 cpu, But It's old and I'd like to see someone try and run Linux on a 6502 cpu with 48k ram. I don't think crunching or what ever is even possible on something that old. :D ;)

There aren't that many differences (besides clock speed) from a 486 to an early Pentium, IIRC.

The cool stuff starts with the later K6's and PII's.

---

EricVonDaniken,

to my knowledge he bought a license, and that's how :o)

Regards,
Simon.

A= can you verify that so we are sure of what thw truth is?

B= how much does a license cost?

License is found at Intel web site - I just purchased it, cost of about $600.00 USD for the compiler, distribution, and Primatives.

This thread may interest you. It contains a link to detailed instructions for Windows (complete with Screenshots) and a source code package you can use to get started.

Regards,
Simon.

---

Donate to SETI@Home via PayPal!

Optimized SETI@Home apps + Information

EricVonDaniken,

to my knowledge he bought a license, and that's how :o)

Regards,
Simon.

A= can you verify that so we are sure of what thw truth is?

B= how much does a license cost?

License is found at Intel web site - I just purchased it, cost of about $600.00 USD for the compiler, distribution, and Primatives.

This thread may interest you. It contains a link to detailed instructions for Windows (complete with Screenshots) and a source code package you can use to get started.

Regards,
Simon.

merci for this very interesting link
seti_britta

De rien!

So far, the source package hasn't been downloaded, but I'm reasonably sure that will change. The Linux source package was downloaded 29 times already, the SSE2-optimized Linux client 205 times.

Regards,
Simon.

---

Donate to SETI@Home via PayPal!

Optimized SETI@Home apps + Information

Hi, KWSN-CHicken of Angnor!

I followed your link to the instruction for windows to make my own compiled client. So far no problem, but when I unpacked your file, containing boinc and seti_boinc a password was needed for some files ???

So, are these protected files necessary or what is about this password?

Edit: It's ok now, it was just a lag of diskspace...

---

Lol :o)

I was wondering...no, the file is not passworded, of course.

Good that you got it to unpack! I hope you can get it to work for you, the sources should compile if you install all the stuff.

I might have forgotten something with the MKL library - check the How-To again in a bit to see what I mean (it's the MKL FFTW wrapper library).

The same instructions as in the Linux version work, almost. It's just that you have to install or download parts of an SDK from Microsoft that has a program called "nmake" (free) and put them in your path somewhere, then go to "C:\\Program Files\\Intel\\MKL\\8.0.2\\examples\\fftw2mkl" and execute "nmake lib32" in a command window there. Then copy "_results\\ffwt2mkl.lib" to "C:\\Program Files\\Intel\\MKL\\8.0.2\\ia32\\lib\\".

Otherwise, it will probably give you a linker error (I'm reasonably sure I put that .lib file in the libraries it should include in the project file).

Regards,
Simon.

---

Donate to SETI@Home via PayPal!

Optimized SETI@Home apps + Information