Technology question

[Zoetstofzoetje]

Here's a question for the more technology inclined of us:

I'm interested in having an application built that does a series of complex calculations, based on information received through network packets with an RFC protocol. The calculations are based on complex if/then/else configurations by the user. This is a calculation and decision structure, which can lead to network packets (decisions) being sent back across the network. The program will have to maintain some kind of local database for speed. The user's configuration should be changeable on-the-fly.

The important aspects here are thus:

1) speed of calculations (nanoseconds matter!)
2) rapid adaptability

I've been told that the best would be a combination of C, and .NET.

What do you guys think, in terms of programming languages? Also, which sort of database would be the fastest? If I decide to move to a mirrored database (master, client, ghost) later on for data completeness and reliability purposes, would that be compatible with the single user configuration?

[loinburger]

C# and SQL Server. Stay away from C, you'll probably just break everything.

[Ari Rahikkala]

If nanoseconds really do matter, you might end up having to do native code generation. It's not too difficult if the source language isn't complicated. You can easily implement a translator that turns a bytecode with a couple of dozen instructions into C code (to be handed off to an optimising compiler) in a day, just ask most teams in the top 10 of ICFP 2009 Programming Contest.

Fortunately, any post where "maintaining a local database for speed" is mentioned isn't actually about a problem where nanoseconds matter. Nanoseconds are the timescale where you're thinking "how do I minimise cache misses (i.e. requests that have to hit main memory) here", not "I wonder if I should have the database on the local or a remote node". If they were, you could move the remote node a foot closer to win two ns per round-trip . So, just use whatever language and database you're least likely to mess up with horribly.

[Ari Rahikkala]

e: I can't believe how horrible this forum interface is

[Asher]

There needs to be a lot more information.

Certain databases are faster for certain things. Every database can be customized to be much faster at some things than others.

Programming languages are also not so cut and dry. While many people will tell you writing x86 is how you get the fastest code, that's actually not true in the vast majority of cases. If you're in the top 0.5% of developers worldwide with an expertise in x86 and a COMPLETE understanding of the CPU architecture you're targetting, that may be true. But this would mean knowing things about cache line sizes, how to avoid cache misses as much as possible, maintaining data locality, taking advantage of pipelining and multithreading effectively, etc. The vast, vast majority of the time, hand-written x86 will be slower than output from the high-end compilers with full optimization on (especially with profile-guided optimizations). When people start coding on the lowest level, they frequently omit high-level optimizations that the compilers can see.

Even the C vs C++ vs C# thing isn't cut and dry. C will virtually always be faster than C++, but C# can be faster than both. It may sound absurd, but it's true. The .NET CLR is actually extremely good at optimizing the code for your specific computer, taking advantage of all instructions available and not just the lowest common denominator like static code usually has to use. There are numerous examples online of C# outperforming C in some operations.

There's a whole ton of variables to consider here...

[loinburger]

C# or Java should be the default languages of choice for any long-lived application because they'll automatically manage the program resources - even if you manage to avoid coding any resource leaks into your C program then you've still got to contend with crap like memory fragmentation that the CLR/JVM GC can handle for you (IIRC the default behavior for the CLR is a 3 generation mark-sweep/copy/copy collector and the default behavior for the JVM is a 2 generation mark-sweep/copy collector, but I'm pretty sure you can swap out those mark-sweep collectors for mark-compact collectors if you're extremely paranoid about fragmentation although in practice this is rarely necessary - the copy collectors take care of almost all of the fragmentation). If you want to code a hybrid application then go with C#, because you can code a matrix multiplication (or whatever) subroutine in C and call it from C# with less overhead than you can from Java, and as long as you're smart about your resource allocations in the C subroutines you won't muck up the CLR too badly (i.e. the C subroutines should allocate to one contiguous region that can be immediately deallocated when the subroutine exits, so the subroutines behave just like any other large object).

[Zoetstofzoetje]

If nanoseconds really do matter ... Fortunately, any post where "maintaining a local database for speed" is mentioned isn't actually about a problem where nanoseconds matter. Nanoseconds are the timescale where you're thinking "how do I minimise cache misses (i.e. requests that have to hit main memory) here", not "I wonder if I should have the database on the local or a remote node". If they were, you could move the remote node a foot closer to win two ns per round-trip . So, just use whatever language and database you're least likely to mess up with horribly.

It's true that nanoseconds matter - but not always. There are two locations in this configuration - a 'local' server which executes the mouldable configuration, which is located nanoseconds away from where it matters, and a 'distant' client which creates the initial configuration, and sends instructions for alterations to the 'nanosecond-critical' device.

Because of this, I talked about a local database - so that the data which has to be processed is locally scrutinized. A user on the distant client will use non-time-critical inputs to decide how to alter the configuration. Yet, the 'local' server will need to execute those the instance that a variable in a calculation flips from 'false' to 'true', for example.

There's a whole ton of variables to consider here...

What might be of further interest is - there's going to be a million data points coming into the database every second, each of which needs to be stored, and some will be part of running analyses. Some of these analyses might trigger conditions that trigger further analyses, and ultimately might require a decision to be sent out within as short an amount as possible.

C# or Java should be the default languages of choice for any long-lived application

I'm not a programmer, but Java is not in my book of records for superfast. Longevity is not an issue. Five years from now this program will be obsolete.

[loinburger]

I mean "long-lived" as in "is meant to be online for more than a couple of hours." If you're running it for a few minutes and then shutting it down then things like memory fragmentation (hell, even memory leaks) don't matter, but if it's supposed to be up and running for a week at a time then you want to use C# for most or all of the coding.

[Asher]

It's true that nanoseconds matter - but not always. There are two locations in this configuration - a 'local' server which executes the mouldable configuration, which is located nanoseconds away from where it matters, and a 'distant' client which creates the initial configuration, and sends instructions for alterations to the 'nanosecond-critical' device.

Because of this, I talked about a local database - so that the data which has to be processed is locally scrutinized. A user on the distant client will use non-time-critical inputs to decide how to alter the configuration. Yet, the 'local' server will need to execute those the instance that a variable in a calculation flips from 'false' to 'true', for example.



What might be of further interest is - there's going to be a million data points coming into the database every second, each of which needs to be stored, and some will be part of running analyses. Some of these analyses might trigger conditions that trigger further analyses, and ultimately might require a decision to be sent out within as short an amount as possible.



I'm not a programmer, but Java is not in my book of records for superfast. Longevity is not an issue. Five years from now this program will be obsolete.

Java isn't as slow as people like to think it is, especially in a server environment.