Zombie67 where are you???

OK, I'll ask. It's my turn I should think but you are nearly always here first.

PLEASE can we have an OSX version of the app. Please.

Thanks in advance!

Steve

Hello,

We will improve the application code and is possible,and when we improve it we develop MAC OSX version. First of all we have to solve server problems, but before that we will port the application to MAC OS X. We are searching an OSX machine to compile it and make the test.

Thanks for your attention. Joel.

Zombie67 where are you???

Sorry, there was the email problem. But now I am in and ready to crunch with my Macs too.

---

Dublin, California
Team: SETI.USA

Hi!

We have compiled a MAC OS X Version of the app. We are testing it now. In the launch of the new version of the app, it will be included.

When is this launch expected?

Hi, tomorrow, like in 12 hours aprox.

Hi, tomorrow, like in 12 hours aprox.

Thank you!!

S.

I am using OS X and have a very high error rate. I also have windows machines with no errors. I have just removed and reloaded the application. Will let you know if it works.

I am using OS X and have a very high error rate. I also have windows machines with no errors. I have just removed and reloaded the application. Will let you know if it works.

(Sorry this came through twice)

I am using OS X and have a very high error rate. I also have windows machines with no errors. I have just removed and reloaded the application. Will let you know if it works.

Hi!

The error code says that is related to saving or restoring from checkpoint file. I have also notice that the error didn't appear with smaller tasks ( 300 cycles simulations). This is why we think that could be related to a some kind of overflow. We will try to reproduce the error in our machines.

Thanks for the info, we will try to solve it as soon as possible.

I am wondering WHY the DARWIN OS (mac OSX?) does tasks so much faster than Linux or Winderz...

Seems to me, everywhere I look in statistics, Darwin does things faster on lesser CPU setups...

Is it real or a time recording error or what? The points these machines make seem to support faster processing speed...

(scratching head)

8-)

I am wondering WHY the DARWIN OS (mac OSX?) does tasks so much faster than Linux or Winderz...

Seems to me, everywhere I look in statistics, Darwin does things faster on lesser CPU setups...

Is it real or a time recording error or what? The points these machines make seem to support faster processing speed...

(scratching head)

8-)

We think that is related to the compilator. In MAC OSX we use a propietary one from apple, and in the other platforms we use it one from comunity.

Best regards, Joel.

We think that is related to the compilator. In MAC OSX we use a propietary one from apple, and in the other platforms we use it one from comunity.

Best regards, Joel.

Well, seems there could be something to improve somewhere...

For instance, check this out...

http://denis.usj.es/denisathome/workunit.php?wuid=2953065

That supposed 3770 is in a laptop (computer #3270) and no way is it faster than my 4.5GHz 1866MHz Mem setup (computer #4416).

3270:
Measured floating point speed 4583.16 million ops/sec
Measured integer speed 12064.15 million ops/sec

4416:
Measured floating point speed 5726.15 million ops/sec
Measured integer speed 30458.46 million ops/sec

That task took my setup 22.3 minutes and the Darwin setup took 17.9 minutes.

THAT is a HUGE 25% difference, yet, my setup is 25% faster!!

There MUST be a better compiler out there to use...

One point I would like to make is I have seen this before on another project and it turned out a loop count in the software was wrong causing a huge speed difference... the output seemed okay, but close examination determined that the output wasn't 100% the same.

Anyways, I think this needs to be looked into a bit closer...

8-)

In my day, I wrote code for DSPs and CPUs in assembly language, long before the C language was invented.

I used PASCAL and FORTRAN and others and at times I looked into the code generated with a debugger and discovered a lot of major differences on how functions were treated.

Are you using GCC 5.2 for Linux? Would another work better?

Have you looked into code optimizations or looked at what is being generated at the assembly level?

Simple things such as calling the OS too often can slow things down tremendously...

To be fair, I notice this on many BOINC projects and it suggests two things:

1) YOU the BOINC project would do better to make a Linux or Windows Wrapper and run Apple compiled tasks in it...

2) A detailed analysis of what the real differences could be might improve your overall project speed up to 50%.

Another problem I heard discovered on a new project was the code was checking if it was time to checkpoint far too often causing a similar slowdown...

A simple thing like using Macros or Inline Code could adjust for the compiler idiosyncrasies... one never knows without deep checking...


8-)

PS: If DENIS could figure this out, I am sure other projects would benefit... There is absolutely NO WAY an old iMac or Macbook should beat my 4.5GHz 3570K setup... or many other setups people run for that matter!!!

I find it completely weird that a i7-3770 Macbook (or whatever) can go faster and take 1/3 the time as a Xeon X5680...

http://denis.usj.es/denisathome/workunit.php?wuid=3008079

This really makes me think some special optimization or special intrinsic instruction is being used on the 3770 that isn't available or not coded for on the Xeon X5680

I would REALLY like to understand this. I can guess at a lot of things, like SSE2 being used on Mac and not on X5680 or some such thing...

Maybe the AVX or F16C instruction that the X5680 doesn't have? Anyway, that wouldn't explain the huge difference compared to my 4.5GHz i5-3570K setup since it has the same instructions (except SSE4) as 3770...

Anyways, still scratching head...

8-)

Hi!

We are an small team and there are some problems that are hard for us to solve. We have develop the DENIS app with the guidelines of BOINC. The GCC compiler is old one to avoid compatibility problems ( as suggested by BOINC Dev Guide).

Our knowledge about compilators and different optimization is growing day by day, so we will research more about how to optimize the non-OSX versions to make them faster in the future.

The code is free and open in our github account you can see it if you want:
https://github.com/DENISproject/denis-boinc-baseapp

best regards, Joel.

WOW! That data processing stuff is actually an order of magnitude (at least) more complicated than the machine control I spent most of my life developing.

Seems my basic idea's on the subject in terms of optimizations will have to be in the structure and not content unless "I" dive deep into your project. I assure you, I am not qualified to do that.

But, for the sake of mental exercise, how would I test things if I decided to try some optimizations or different compilers myself?

8-)

PS: Keep up the great work! As it turns out, I may put together a "Hackintosh" later to play with because of this issue...

Hi!

The whole explanation of how to do it is inside this page: http://boinc.berkeley.edu/trac/wiki/CompileApp

If you want a brief introduction, the way we work is downloading BOINC source code from github, after that we compile the libraries of boinc on each architecture, and later, we compile the app with a make file that include those libraries (BOINC API)

The applications can be uan in standalone mode, but you can't test things like checkpoint, this is why checkpoint have caused so many problems in this project.

To test those things, we have a Virtual machine with a server of boinc that serves the application to LAN computers. You can download one here:

http://boinc.berkeley.edu/trac/wiki/VmServer

At the begining it's a bit confusing, but when you got the things compiled and compilation automatized, you could start to optimize the code.

Best regards, Joel.

Thanks for your patience and understanding and help!

In the (further) future, I hope to do that as a retirement exercise...and for fun.

Thanks again!


8-)