Author Topic: DB ports  (Read 5265 times)

Offline jknilinux

  • Bot Destroyer
  • ***
  • Posts: 468
    • View Profile
DB ports
« on: November 20, 2009, 01:30:32 PM »
Hey everyone,

I once heard there was a Cpp port of DB2... Is this true? Are there other ports? Why hasn't this become the main DB2 program?

Offline Peter

  • Bot God
  • *****
  • Posts: 1177
    • View Profile
DB ports
« Reply #1 on: November 20, 2009, 01:39:28 PM »
I believe it failed.
Oh my god, who the hell cares.

Offline jknilinux

  • Bot Destroyer
  • ***
  • Posts: 468
    • View Profile
DB ports
« Reply #2 on: November 20, 2009, 03:34:37 PM »
oh... Also, how hard is it to port a C# program to another language, like java? Is there some sort of automated converter available for anything?

Offline Numsgil

  • Administrator
  • Bot God
  • *****
  • Posts: 7742
    • View Profile
DB ports
« Reply #3 on: November 20, 2009, 05:01:51 PM »
There was a C++ port (far more a straight port than DB3 is).  It was mostly finished (feature complete for the most part, but really buggy), but I abandoned it after realizing that I had inherited lots of the problems from the VB source, so the port wasn't really worth the effort.  That was early to mid 2006.  I then played around with .NET to get used to it (wrote the DNA system late 2007, for instance), and played around with a physics engine attempt in C++, before starting the current DB3 effort in earnest in early July 2008 (4th of July weekend).

The C++ code still exists.  You can browse it here, but it's a weird hybrid between the VB source and some new inventions.  I think you had worked a bit on the code, jknilinux, right?  It's been a few years so I don't quite remember.  Basically I had not really thought about architecture when I started the C++ source, and I was a pretty green programmer in general.  The current C# source for DB3 is built with more best practices in mind.  It's unit tested, strictly modularized, and I'm especially careful to favor readability, maintainability, and big O over "performance" and low level optimizations.

All .NET code from one language can be converted to any other .NET language, as long as the languages in question implement the entire .NET feature set.  C# doesn't quite implement all of it, but I think it does most of it.  So if there's a Java compiler that compiles to CIL, there's probably something there to convert the C# code to Java.  From a practical standpoint, the C# language and Java are all but identical, but they target different runtime libraries.  This guide might be helpful.  It's far easier to approach C# from Java than from C++.  Most of the learning curve is learning the .NET libraries, not the language.  You can think of C# as Java targetting Microsoft's .NET libraries.  I think that's basically how the language started.  There are some new features in C# from about 3.0 onward that have no analog in Java (LINQ, Lambda expressions, dynamic typing, var, to name a few), but for the most part it would feel very familiar to a Java programmer.

Also, because the code targets the .NET platform, the different modules don't have to be in the same language, even.  There's not extra overhead to interface VB.NET code and C# code, for instance.  Although for consistency (and the ability to target the XBox through XNA) I'll probably insist that core modules be written in C#.  But side modules (graphics, different DNA languages, etc.)  could easily be written in different .NET languages.

Offline jknilinux

  • Bot Destroyer
  • ***
  • Posts: 468
    • View Profile
DB ports
« Reply #4 on: November 20, 2009, 05:15:56 PM »
Sorry to keep bringing this up, but would running the java version on unix be faster? I think that in order to evolve interesting behaviors, we may need to run an order of magnitude more cycles than even the longest-running DB sims we've made. So speed is my main concern.

Also, isn't there such a thing as an optimizer for C# code? Could we use that?

And finally, can we convert it into a really low level language, like C, easily?

Offline jknilinux

  • Bot Destroyer
  • ***
  • Posts: 468
    • View Profile
DB ports
« Reply #5 on: November 20, 2009, 06:01:30 PM »
I mean, an algorithm optimizer?

Offline Peter

  • Bot God
  • *****
  • Posts: 1177
    • View Profile
DB ports
« Reply #6 on: November 20, 2009, 06:30:09 PM »
Quote from: jknilinux
Sorry to keep bringing this up, but would running the java version on unix be faster? I think that in order to evolve interesting behaviors, we may need to run an order of magnitude more cycles than even the longest-running DB sims we've made. So speed is my main concern.

Also, isn't there such a thing as an optimizer for C# code? Could we use that?

And finally, can we convert it into a really low level language, like C, easily?
I get the concern for speed. But besides that I think we need to look at the parameters used in a evolution sim will get a load of time win. Some setups will never succeed.

I believe you're talking about DB3, whole thing is being written in C#. First finish it, then look how to improve it. If it was done purely for speed, it was written in C. But would take more time to finish as well.

I'm far from a expert on coding, but what could the percentage difference be between optimal C# and optimal C++. Or java and C++. Is the difference between object-orientated and "normal" that big.
I doubt the performance difference between java and C# would be big. I think there is more to win is optimizing the C# code instead of translating it.
Oh my god, who the hell cares.

Offline Numsgil

  • Administrator
  • Bot God
  • *****
  • Posts: 7742
    • View Profile
DB ports
« Reply #7 on: November 20, 2009, 06:55:56 PM »
Quote from: jknilinux
Sorry to keep bringing this up, but would running the java version on unix be faster? I think that in order to evolve interesting behaviors, we may need to run an order of magnitude more cycles than even the longest-running DB sims we've made. So speed is my main concern.

 Not an order of magnitude faster.  I did a test recently and my math-driven CPU bound algorithm runs 5 times slower under Mono than under .NET.  So at the worst case that would be the difference.  I think (hope) there's some performance work on Mono that will make that number far lower when an actual program is released.
 
 Under windows, the difference in speed between C# and C/C++ code is usually about 10% in C++'s favor.  Unless SSE instructions are used, and then it's more like 70-80% in C++'s favor, just because C++ has intrinsics for SSE and C# does not.
 
 On point, Java probably would be faster on linux, just because there's a better open source JIT for Java bytecode over CIL (the .NET's version of bytecode).  But language choice isn't going to make or break any performance comparisons.  At best you're talking about a range of a constant order of magnitude faster.  Considering hardware is still doubling horsepower every 18 months, I'm not worrying much about constant factors.
 
 The core engine is going to achieve significant speedups algorithmically.
 
 
Quote
Also, isn't there such a thing as an optimizer for C# code? Could we use that?

 Yes, it's called the JIT compiler.  The one for Microsoft's implementation (.NET) is quite good.  Mono's is slightly less so at the moment, but I think that gap should close soon.

 
Quote
And finally, can we convert it into a really low level language, like C, easily?

 Not easily, no.  If nothing else I make heavy use of features that just aren't available in C, like the extensive real time reflection system.

More to the point on speed concerns: this really is a case where big O trumps any constant order overhead you can throw at the problem.  There will be a few core routines that will bottleneck the entire program.  When we get that far, I can play with swapping out our matrix routines for LAPACK and BLAS, for instance.  But you're still talking constant order speed ups.  I'll be spending far more time investing in things like a sparse matrix decomposer, which would change a part of the program from O(n^3) to O(n^2) or maybe even O(n) (I'm unclear about the order of complexity of sparse routines).

I have a list I can present of math intensive areas of the program where someone smart can spend some time implementing better algorithms, if anyone's interested.  Effort here can give something like a 1000x speedup over a measly 5x speedup, with that number getting even bigger as you add more bots.

Quote from: jknilinux
I mean, an algorithm optimizer?

That's what programmers are for, and why we get paid the big bucks.

Quote from: Peter
I get the concern for speed. But besides that I think we need to look at the parameters used in a evolution sim will get a load of time win. Some setups will never succeed.

I believe you're talking about DB3, whole thing is being written in C#. First finish it, then look how to improve it. If it was done purely for speed, it was written in C. But would take more time to finish as well.

I'm far from a expert on coding, but what could the percentage difference be between optimal C# and optimal C++. Or java and C++. Is the difference between object-orientated and "normal" that big.
I doubt the performance difference between java and C# would be big. I think there is more to win is optimizing the C# code instead of translating it.

I don't have numbers for Java vs. C#, but generally speaking, each level of abstraction adds a 10% slowdown over equivelant expertly written code.  So C vs. Assembly, you're talking something like 10%.  C++ vs. C, something like 10%.  JIT vs. C/C++, something like 10%.  Those are rough numbers, of course.  Actual numbers vary quite largely.

Why do we accept this performance/memory loss?  The increased productivity and maintainability at higher levels tends to offset the losses.  Writing a large program is assembly is almost impossible.  Writing one in C is possible, but it can easily become a maintenance nightmare.  C++ helps by introducing object oriented programming as a first class language feature.  C# helps by giving access to the .NET framework as a first class language feature, and allowing for the JIT to handle per-client optimizations.
« Last Edit: November 20, 2009, 06:57:52 PM by Numsgil »

Offline jknilinux

  • Bot Destroyer
  • ***
  • Posts: 468
    • View Profile
DB ports
« Reply #8 on: November 20, 2009, 08:32:13 PM »
OK, how long could it be before we create a fully-optimized version of DB3? Also, since linux is probably less bloated, could running DB3 on mono with a 5x slowdown on an extremely streamlined linux OS be faster than running DB3 on, say, 7? what about win2k?

Offline Numsgil

  • Administrator
  • Bot God
  • *****
  • Posts: 7742
    • View Profile
DB ports
« Reply #9 on: November 21, 2009, 02:10:56 AM »
Quote from: jknilinux
OK, how long could it be before we create a fully-optimized version of DB3? Also, since linux is probably less bloated, could running DB3 on mono with a 5x slowdown on an extremely streamlined linux OS be faster than running DB3 on, say, 7? what about win2k?

No.  Again, don't overestimate performance cost of windows.  I doubt it's even approaching 1%.

And again, the 5x slower figure is from an isolated test case.  The real number would probably be much lower.

Offline jknilinux

  • Bot Destroyer
  • ***
  • Posts: 468
    • View Profile
DB ports
« Reply #10 on: November 21, 2009, 02:22:31 AM »
OK, makes sense. WIndows seems to be the best way to go for now.

Offline Botsareus

  • Society makes it all backwards - there is a good reason for that
  • Bot God
  • *****
  • Posts: 4483
    • View Profile
Re: DB ports
« Reply #11 on: November 02, 2010, 06:35:29 PM »
Quote
All .NET code from one language can be converted to any other .NET language, as long as the languages in question implement the entire .NET feature set. 

well, there are some exceptions:

For example:

VB.NET --> C#

You can not "declare function" in c# w/o importing the dynamic link library, and the code for that looks completely different.

Also, try doing:

C# --> VB.NET

byte a = 255;
a++;

in vb... good luck!

Offline Numsgil

  • Administrator
  • Bot God
  • *****
  • Posts: 7742
    • View Profile
Re: DB ports
« Reply #12 on: November 03, 2010, 01:10:40 PM »
Those are language differences.  But the core byte code (what the human readable files get converted in to when you build an executable) are identical for either language.  There's basically a 1:1 mapping between the two languages.  You can't say that for C# and C, for instance.