Budget Linux cluster suggestions?

The problem with a GPU solution is effectively using the compute power. Look at the top 5 machines on the TOP500 supercomputer list and compute the efficiency (Rmax/Rpeak). This gives an indication of how much of the potential compute power can actually used in applications.

The number 7 machine which uses the ATI Radeon HD 4870 doesn't do much better. It has an efficiency of 46.7%.

These benchmarks are just numbers that may be similar to your application or not. There is a lot that can be done wrong in simulations, and not exploiting the power points of the machine is one of them. Depending on the problem that is possible or not at all. For us, the CUDA is definitely worth having a look at, and we're going to test it for very little extra expense. We actually just took the next more expensive graphics card. It is a matter of how much bang we get for the buck. and if we reach these 43%, we're happy. The Tesla Card, I forgot which, is having in the order of 255 cores, and even if it is only half used still beats a PC by orders of magnitude.

Rene

SUN Microsystems has a deal where one can borrow hardware for evaluation purposes for up to 3 months.

Maybe you can evaluate their hardware with your algorithm??

On a sunny day (Mon, 16 Aug 2010 11:55:44 +0200) it happened Frithiof Andreas Jensen wrote in :

Sun was bought by Oracle. Not sure they give a s*it about what Sun did or promised.

OpenSolaris as their OS development leader is gone, now it'll follow Oracle's internal development.

Grant.

On a sunny day (Tue, 17 Aug 2010 05:21:52 +1000) it happened Grant wrote in :

Exactly. And they just sued Google for using Java without a license. $$$$$$

Well, Sun won against MSFT for sort of similar situation years ago.

Grant.

On a sunny day (Tue, 17 Aug 2010 07:43:17 +1000) it happened Grant wrote in :

Well, I think I do not like the way Oracle operates. And neither MS... But better even, I do not like Java, more for people who do not understand pointers in C, and like a snail speed. OTOH it seems to work OK on my cellphone.

Andreas

pointers in C,

Only claim to fame is that Java runs just about anywhere. But sometimes I wonder if the reuse, OO and stuff really does help in the longer term.

Grant.

More like, people who think that bounds checking is a good idea.

A Java interpreter will be significantly slower than native code, but most modern Java runtimes use JIT compilers, which can work out faster than C in some cases (the language's restrictions enable some optimisations which aren't safe in C).

I think it does. Java's stronghold is enterprise development, where you have large numbers of people working on massively complex systems, programmers coming and going on short-term contracts, software having to be maintained for decades. In this environment, you need the "management" which OO provides.

The question isn't about what OO will let you do compared to non-OO languages, but about what it will stop you from doing. A strict OO language such as Java forces you to "go through the proper channels" (i.e. use the public methods rather than manipulating the underlying data), which makes long-term maintenance a lot easier.

People who don't see the point of OO are typically "lone" programmers who write entire programs by themselves (or at least work on programs small enough for one person to understand it). In that situation, there usually isn't much point to OO (unless the task naturally lends itself to an OO approach). OO starts to matter when you need full-time test engineers and documentation managers, a suite of tools to keep track of all of the modules, and the rest of it.

My simulator is all object-oriented, primarily for extensibility. I can give some weird material its own set of updating equations, or some massively complicated model if I like, and the rest of the program doesn't care.

Cheers

Phil Hobbs

Simulation is one area which naturally lends itself to OO. As are systems which tend to have many structurally similar "components", e.g. filters in audio or image processing, widgets in a GUI toolkit, etc. Particularly if such systems are meant to be extensible.

A rough heuristic for whether OO makes sense is whether you actually create subclasses. If every class is free-standing (doesn't inherit from a superclass), then structs and functions would probably work just as well. Conversely, if you have a struct with a "type" field and many of the functions which operate upon it use "switch (p->type) {...}", OO may have been a better approach.

On a sunny day (Tue, 17 Aug 2010 01:05:35 +0100) it happened Nobody wrote in :

Well, if you need a shipload full of dummies I think. Think how Linux, and the Linux kernel, is maintained by hundreds, if not thousands, not to mention the zillions of other large Unix projects, all written in C. Stroustrup is an IT war criminal.

Linux actually published some figures recently indicating how many people contributed to one release version. Generally it's taken as over 4k people contributed overall (I'm in there :) But it's not just the names in CONTRIBUTORS file, you'd need to scan the source as well. Then pull out the duplicates due to old vs modern language char set for foreign language names (for example Joerg vs the four character native language version).

I don't recall seeing that done recently. Some really old code is being removed, so you'd have to account for the life on the source too. It is big.

Free, too. Apart from the time for learning commitment. I digress.

Works for some projects, I don't use Java since uni, but then, I don't use COBOL since uni either ;) That language has its place too, at least it doesn't suffer as many of the programming errors of modern languages, numbers are exact, no rounding errors for currency work. COBOL is like double entry bookkeeping, very structured source, yells at you 'cos it's mostly upper case.

I'm not the least bit sorry for what others spent their time on ;)

I'm sure some would argue it's a waste of time to write little PIC programs in assembler, but I enjoy that challenge. There's areas where the little chips continue to be appropriate.

Grant.

On a sunny day (Wed, 18 Aug 2010 06:56:03 +1000) it happened Grant wrote in :

What I remember from uni was Pascal :-) Anyways, I first did not want to reply, because this sort of discussion has no end, but this is what I thought: I grew up with hardware (tubes, later transistors), then flipflops, shift-registers, gates, and made little adders etc, then later build my own simple processor with TTL and some CMOS. I programmed some stuff in machine code (pencil and paper), then later assembler, BASIC, whatever came along. I sort of understand what the hardware does, and you could call it 'bottom up'. I know (well maybe not of the latest super processors) the building blocks well enough to build reliable stuff with it.

For the 'object oriented' view, it is my impression that the poor guys without

I agree, as long as it does not threaten me. An airplane that has fly by wire code written in some weird object oriented language is not something I would feel good about boarding.

Yup, bottom up, know the stones, then you can build anything. And it will be efficient, reliable, and fun, and also fun to use. I wrote the LC meter PC part in C in a few ?minutes? Did one correction so it would not hang if connected to something else than the LC meter (different serial port with who knows what on it). Source, < 14kB

-rw-r--r-- 1 root root 13819 2010-08-17 lcp.c Executable: -rwxr-xr-x 1 root root 10192 2010-08-18 lcp

You can write OO in C. GTK+ is probably the prime example of that. Xt is similar, but more messy (many of the core methods have "custom" inheritance semantics).

The Linux kernel makes more limited use of OO; e.g. there are abstract "classes" for devices, with subclasses for e.g. USB devices. Each driver implements a concrete (non-abstract) subclass, with individual devices being instances.

But the Linux kernel isn't particularly complex (in the strict meaning of that term). It can't be, as it has to be efficient and reliable (and much of it has to be re-entrant; if you want that to be reliable, the code has to be structurally relatively simple).

Even then, the amount of developer effort per line of code is much higher than most projects could tolerate. If you want to make a change to a core subsystem (as opposed to adding yet another driver), be prepared for a hundred-message discussion and ten revisions before anyone's even willing to beta-test your changes.

The irony is that C++ doesn't inherently produce bloated code. Much of the reason why C++ is so much more complex than C is that it adds high-level features without letting go of the bare-metal aspects.

Have you tried compiling "normal" C code for a PIC? Or writing C which will run on a PIC and an AVR?

Java turned out quite well; it's used on systems from mobile phones up to enterprise servers. It won't work on anything below a 32-bit CPU, but that was never a design goal.

You could look into 802.3ad

Cheers

shift-registers,

with TTL and some CMOS.

assembler, BASIC, whatever came along.

enough to build reliable stuff with it.

Hmm, I have similar background, though the machine code was paid work. On paper, using photocopies of the form in the back of the 6502 book :) So I learned to count forward and backwards in hex for work out branch offsets, fun stuff.

Did lots of assembler, BASIC, Pascal when Turbo Pascal was the go. But my work was electronics back then, I moved to embedded controllers because they were smaller and 'easier' than the hard wired finite state controllers I was designing at the time.

little wooden cubes as a kid,

whatever of the many

I see a different picture, the uni turn out 'programmers' from anybody who chooses the course, they get taught the concepts with the easiest languages the lecturers can handle. But the teaching is done mostly by people with little or no industry experience.

So when I wanted to add a widget (beyond the requirements) to a C++ assignment (knew what I wanted, but not how to express it), it wasn't the lecturer or tutor who had the answer, was the unix sys-admin guy ;)

I went to uni *after* a couple decades in the workforce.

So I imagine all these graduate but clueless programmers being snapped up by the big companies and told to go write this part of the code for a tightly defined whatsit. In that scenario, OO seems to make some sense. They have to run business like the 100 monkeys setup, then fixup the worst of the problems. Projects don't scale by simply adding people. But I guess 90% of the crud work can be done by fresh graduates. With experts looking after the magical bits.

the bricks and the concrete and anything.

cubes paradigm,

that, had to also learn C, but not the underlying

got in big trouble,

longer agree on what C++ was about :-)

only way to do large projects with many programmers,

programmers, they impose a huge burden.

like that idiotic thing in CERN,

with more force.

humanity.

Well, efficiency of operation in other than economic terms is all that matters at this time. Later, they'll take more care of resources 'cos they'll be expensive.

language is not something

would not hang if connected to

it).

I'm sure if you had a math library and a good set of calling macros in assembler, you'd do the lot in assembler. That's what the C coders forget, or never learned. Programming in assembler is not the same as writing machine code.

I haven't worked with the PIC long enough to build a macro library yet, as I'm still defining the 'libraries', or functional modules.

Besides, I'm retired, no more deadlines to work to :)

Grant.

Yes. The deadlines are different too, there's always the next release to wait for. No boardroom decision to ship product Friday week no matter what, for example.

Me? Not yet. It would only be for library access or some aspect not accessible in assembler. I've done systems where the magical stuff (measurement an signal processing) was done in assembler, but the system control stuff was in tiny basic so they could easily customise the box's site interface to the customer's industrial process controllers.

Not used it 'for real', most of my experience is down in the land of 8 bit and small memory sizes. Lately the easy land of unix shell scripting and awk, perl.

Grant.