Fun Stuff > CLIKC

Programing question

<< < (2/3) > >>

Catfish_Man:
Some random thoughts:

Fortran is still sometimes used for numerical code, iirc primarily because the lack of pointer aliasing makes it easy to optimize. If performance is truly critical, a) USE A PROFILER, b) see a, c) check your data structures and algorithms, d) investigate things like restrict, pure, and register, or getting out the inline asm.

POWER/PowerPC (RS/6000s are POWER based these days, no? If not, ignore me) has a fused multiply-add instruction, which is slightly higher precision and higher performance than a multiply then an add.

Higher level languages than C: It'll depend heavily on allocation patterns, amenability to JIT optimization, etc... impossible to say how it would perform without a great deal more information about its behavior. It's quite possible that garbage collection would actually be rather fast, since you don't need to use a non-pausing collector for noninteractive stuff like a simulation, and you could probably take advantage of the iterative nature (schedule a collection after each iteration or N iterations).

Be careful with the precision stuff; there are situations where higher precision isn't as important as matching the expected precision/behavior.

Functional languages (Haskell would be preferred to LISP derivatives imo): the main advantage you'll see from these is parallelization. If your algorithm is inherently serial I would not bother with them, although I admit Haskell does some really neat correctness checking with its type system. Certain types of problems are also just very easy/concise to express in functional languages (like, the code to say "make me a list of all the prime numbers" in Haskell is fairly trivial, and due to lazy evaluation does not actually use infinite memory). I still can't stand 'em in general. Hurts my object-oriented brain ;)

Scytale:
hmm cheers for the advice.

I've spent the last two days at work pouring over doccumentation and source code and I've just about got my head wrapped around it all now.

Being that most of the algorithms used were written by people a hell of a lot smarter then me I'll probably be leaving them alone, just porting them over wholesale (this model is pretty complicated, does stuff with fluid dynamics, gas kinetics and chemical equilibria etc). Luckily it's divided into a set of "sub modules", one part controlling temperatures, one part, chemical kinetics etc, means I can concentrate on porting it over 1 module at a time. C++ is looking like a good option at the moment as the OGS system it feeds into is also done in C++ theres a wrapper at the moment which handles the output for the fortran, theres a whole API set up for the OGS/Control room environment, complete with it's own 238 page manual :( !!! So by taking advantage of C or C++ I can leverage off that a bit, will make life a lot easier.

Fiddler:
Without spending a lot of time with all this legacy code myself its kind of hard to give much useful advice but I'd say using C++ is appropriate and its not like you cant implement using C lib's too if thats what you know. 

Catfish knows his stuff too because everything he said is true, and I completely agree that the functional languages, while cool at times, are just a head ache if you are used to OO. 

If at all possible convince them to move the data into SQL databases instead of .dat files because that would seriously speed things up.  I cant really think of any reasons why they would'nt want the input to be straight from a database in this case.  Its alot easier to put new data into the system that way.  If they already use databases for everything using .dat files would just mean you'll end up having duplicate copies of the data in separate spots and then when you back it up your saving both those files as well, its just a lot of wasted memory and time either way.

C++ code is more my thing though.  Most of my work has been coding with it so any problems you have in that department I can actually give more useful answers for haha.

Scytale:
I had a major breakthrough today I finally got the f%$# Fortran code to compile.

We had all these dramas in the office, the Fortran compiler we had (some insanely old POS) kept giving stack fault errors and wouldn't compile properly.

Work was prepared to buy me a new Fortran compiler, I protested, seemed like a waste of money for licensing etc.  A quick google search later and I have MinGW and the GNU Fortran compiler working, might I just say how much of a good idea MinGW is I've used Cygwin before but this is like 10* lighter only big drama was that posix signals aren't supported.  Another win for Free Software I say, i now have a working and free Fortran compiler and I can run Vi, so I have a nice IDE as well (I'd been using notepad to edit files for the last week  :x)...

Our IT department are incredibly anal and these PC's are locked the hell down so it virtually impossible to install any new software on them, going through official channels can take months, sometimes I just wish they'd let us have a few *nix boxes for development, would make things a lot easier imo...

Anyway now that Fortran version is working I have something to compare the output from the updated version of the model (which is comming along pretty well so far I think...) with.

Scytale:
I thought I'd bump this topic again, because the model is comming along pretty, well and I'm now working on the database side of it, trying to hook the "back end" of the model into our database.

I've got a bit of a question about resizing dynamic arrays in C++ and was wondering if anyone here has any experience with this sort of thing, I'm pulling recordsets out of the database, obviously  I don't know in advance how many recordsets the select query will return (it's a dynamically generated query, calls on user input for dates etc), I've set up a struct to hold each row of data in as it's returned and thats working fine, performance is pretty decent at the moment. I can access each field of the row by manipulating the struct.

What I want to do is store these structs in a collection somewhere so I can manipulate them etc, at the moment the struct with a row's data goes out of scope and is over written as soon as the while loop re-iterates.

I've got a bit of a hack setup at the moment involving a pair of static arrays and calls to "new". This of course introduces the dreaded buffer overflow error. I'm considering inserting some straight C calls and whipping up the C "realloc" verion of a dynamic array, but I've notice C++ has a "vector" class defined in the standard template library, anyone used this before, if so whats the performance like?

Also a guy a work suggested using a linked list or some other datastructure like that to store the recordsets, It's a good idea but before I try to re-invent the wheel I thought I'd ask around and see whats out there.

Navigation

[0] Message Index

[#] Next page

[*] Previous page