Budget Linux cluster suggestions?

On a sunny day (Wed, 18 Aug 2010 01:31:33 +0100) it happened Nobody wrote in :

I do not think C++ is more complex, only stupid.

Yes, I actually had a go with sdcc, it does PIC16, now also PIC18, and avr. I do not like the constructs needed in C to make it work. Also C isolates you from the hardware. If you really want to use the hardware you will have to read the data sheets very precisely, and then do it register by register, and then it is easier and faster and more reliable (as you know what you do, in the compiler you would have to constantly check the generated asm), to do it in asm. I guess the exception would be if there was a lot of floating point math, but exactly that part did not link in very well in sdcc. Microchip has their own C compiler for PIC, I played with it for a short while., but with so little memory, and simple PICs are not very suited for C, and I burned my xp disk freeing up much of my time to do something more useful then watching MS commercials while re-installing it for the so-manyest time.. Huh? I wanted to say: asm is much better in small chips like a PIC that have a lot of build in special hardware.

On a sunny day (Wed, 18 Aug 2010 01:31:33 +0100) it happened Nobody wrote in :

Of course, you can write ANYTHING in C. Here I sort of write object oriented code in C:

GTK+ is probably the prime example of that. I do not like GTK (the way it looks).

QT looks slightly better, but is written in C++, and immediately took the 'road to bloat'. Man the Qt4 took hours to compile, did not add anything useful, and I finally removed it. IIRC Nokia bought it from Trolltech, and it must have killed the minds of their software guys, because they are losing market share now in a big way. The Trolls were VERY clever to get rid of that top weight thing, that anyone actually was stupid enough to pay for it... I would charge to get rid of it..

Why does anyone always try to imitate that stupid MS windows with those GUIs?

I still run fvwm (the original) on X.

It is so much easier to type the name of the application than to works yourself through menus, even if you knew where it was in those menus. And if you do not know the name of the application, or have no clue, type: apropos subject ... blah blah blo blo

select something, then do: man blah

Want audio interface? connect it to the command line via some speech to text utility. Shell scripting connects the world together, a simple application I came up with for the PIC LC meter: Make a key with 123 uH in it, now let the PC test for 123 uH (plus or minus so many percent) from the output of the LC meter, before it allows you to log in. Access control :-)

The only way to minimize latency is to remove unnecessary packet layers (i.e. ethernet). If I were to design the hardware, I would hang 16 co-processor off 16 2.5Gb/s PCIe bus directly. You can do it with 32, but I think 16 is enough.

be

e,

And we can build it with 5K budget.

------------------------ 2000

Host 1000 NRE 2000

------------------------ Total 5000

Thanks, that's interesting. I need about 3 to 6 times that much memory though (50-100 gig), if I can afford it.

Current front-runner is an ASUS RS500A-E6/PS4 barebones 1U rack chassis ($800) with two Opteron 6172 12-cores ($1k each), 12 Kingston 4GB DDR3

Plus it'll fit in my instrument rack and not take up any floor space. Probably a bit on the noisy side though.

Thanks

Phil Hobbs

Yes, you can still put 100G on the host, or use more expensive local memory chips. There are 4G bits SDRAM available. Host memory will be almost as fast as local, via PCIe bus.

But 24 cores flighting for a single memory bus?

You can fit all the co-processors in 1/2U rack.

This is a 32 cores solution. Mount 4 boards of 4 dual core atoms on a thin rack. Run it up to 5m away, not that you have to. PCIe signals run between 2.5Gb/s and 80 Gb/s. Latency is less than a microsecond.

----------------------------------+ |||| |||| 5M PCIe cable ||||

----------------------------------+ |||| 1U PCIe cable adapter |=3D=3D=3D=3D||

---------------------------+ |=3D=3D=3D=3D=3D=3D +------+

Atom: Intel Atom N270 $44 Bridge: Pericom PI7C9X130DNDE $28 SDRAM: Micron MT46H64M32L2JG $27 uSD: Sandisk 1G MicroSD boot drive $5

PCIe PCB (x4) Atoms (x4) 176 PCIe to PCI (x4) 112 2G DRAM (x4) 108 Misc 100 PCIe adapter 40 -------------------- 500

------------------------ 2000

On Wed, 18 Aug 2010 14:41:52 -0400, Phil Hobbs wrote: ...

...

Yes, an Opteron 6172 can access up to 12 DIMM slots, but that dual-G34-socket motherboard has only 16 DIMM slots. It can hold 64GB RAM, not 100GB.

Do you actually *know* C++ (or another OO language)? Programmers tend to have an inherent "the grass is always greener on *this* side" bias, i.e. anything new is measured against what they already know, and against that yardstick, what they already know usually wins.

IMHO, C doesn't make sense on anything below a PIC18, for many of the reasons which you hint at. Even on a PIC18, you will be writing "PIC C" rather than real C.

I was quite unimpressed with SDCC; their pointer model is incompatible with Microchip's libraries (the only reason for using C was to use Microchip's USB stack), and I don't think that it makes sense to stick rigidly to ANSI/ISO C for such systems. Specifically, if RAM and flash are entirely separate, down to needing to use different instructions to access them, then distinct code/data pointers make more sense than a single pointer type.

The mobo can take up to 256 GB (16 x 16 GB). Those ones are $340 each, so the total for the system I really want is

Total $6220 plus 7% tax = $6655

Complete with 6 months' worth of bragging rights. ;)

Cheers

Phil Hobbs

Only in the same sense as you can write anything in assembler. But just as porting to another platform is easier for C than assembler, some things are vastly simpler in high-level languages than in C.

E.g. for large applications, memory management starts becoming a real problem. Large C/C++ applications often end up using more memory than an equivalent program in a language with garbage collection, because they either have to copy anything which might possibly be freed while they're using it, or hold onto memory which could have been freed simply because they cannot determine that it could have been freed.

Add-on garbage collection libraries for C/C++ tend to leak memory, as they can't reliably tell what is still referenced (they can't distinguish between a pointer to malloc'd memory and and int that looks like a pointer to malloc'd memory).

Appearance isn't the issue here. The issue is the programming interface. All non-trivial GUI toolkits use an OO model, whether in C, C++, or some other language.

gcc's C++ compiler has always been much slower than its C compiler. Probably because it's not such a high priority when most open-source code is written in C. MSVC is much faster than gcc for C++ but about the same as gcc for C.

Till the next Windows OS is released. :(

at

$6220 =A0plus 7% tax =3D $6655

Not for the amount of money.

AMD is honest about the performance. I guess people made them. The Opteron (x12) is about 50% faster than the Xeon (x4). I think the Xeon (x6) is close to 80% of the Opteron (x12).

Opteron (x12) 312 Opteron (x12) 340 Opteron (x8) 290 Xeon (x4) 209 Xeon (x4) 217

On a sunny day (Wed, 18 Aug 2010 21:58:34 +0100) it happened Nobody wrote in :

Oh, yes, I was sort of required to learn it for my job, had to read Stroussup's book (that is how I found out he cannot program), and had to write stuff with that MS visual studio product.. What a joke. Nevertheless I got it all working.

Yep, my reason for looking at C on the PIC 18F14K22 was the Microchip (or any other for that matter) TCP stack, but that sdcc C sucked so much that I decided to write that stack myself in asm, only did the UDP part though, all I needed, see

PIC18 is a lot easier than PIC16, as you do not have to use banksel all the time. For the rest I do not care to much as long as the thing does what it says it does, not always the case with Microchip, hardware SPI did not work in the 18F14K22, had to do it in software, a speed penalty.

On a sunny day (Wed, 18 Aug 2010 22:17:41 +0100) it happened Nobody wrote in :

Just one remark, you repeatedly mention very big programs. In the Unix world the solution is small programs that do a specific task, combined together maybe in a script, or executed from an other program, like bricks make up a building. Pipes is the word, great for video processing,. just chain everything together, I do that all the time with YUV video. It means you can use modules (filters, whatever you like to call them) written by various people who all have a very clean interface (mjpeg tools YUV in this example), and the reliability goes way up, no problems with garbage collection or whatever, can be networked too (I do it via WiFi for example), what not. Big pieces of program code with a huge GUI with many options is the WRONG way to do signal processing. It seems faster for dummies, as they can see the manual with the pictures of what button to click or what menu to traverse, but for professional work you always want to script. I keep the old scripts so I can redo a production if I need to.

Whee! Yeah, that would be fun.

Of course, there's always the risk that someone will walk in the door and instruct it to "Compute, to the last significant digit, the value of pi" and you'll end up with a very expensive and power-hungry brick :-)

sis

R3

That

h,

=A0 $6220 =A0plus 7% tax =3D $6655

The rest of the system design is more important than pure number of cores. If you want best performance, go with the quad chip octo core (4x8) PPC server (but not for $5k).

PPC (4x8) 1010 IBM Power 750 Express (3.3 GHz, 32 core, SLES) Xeon (4x8) 663 Fujitsu PRIMERGY RX600 S5, Intel Xeon L7555, 1.87 GHz Xeon (2x6) 362 Fujitsu PRIMERGY RX200 S6, Intel Xeon X5670, 2.93 GHz Opteron (2x12) 340 Model 6136 in =93Dinar=94 reference design kit Opteron (2x12) 312 Model 6136 in =93Dinar=94 reference design kit Opteron (2x8) 290 Model 6136 in =93Dinar=94 reference design kit Xeon (2x4) 217 Supermicro SuperServer 6026T-NTR+ server Xeon (2x4) 209 FujitsuModel PRIMERGY BX920 S1 server

My design should be around 500, right out of my hat.

This is a 32 cores (16x2) solution. Mount 4 boards of 4 dual core atoms on a thin rack. Run it up to 5m away, not that you have to. PCIe signals run between 2.5Gb/s and 80 Gb/s. Latency is less than a microsecond.

--------------------------------+ |||| |||| 5M PCIe cable ||||

--------------------------------+ |||| 1U PCIe cable adapter |=3D=3D=3D=3D||

-------------------------+ |=3D=3D=3D=3D=3D=3D +------+

CPU: Intel Atom N270 $44 or ARM A9 Bridge: Pericom PI7C9X130DNDE $28 MEM: Micron MT46H64M32L2JG $27 uSD: Sandisk 1G MicroSD boot drive $5

PCIe PCB (x4) CPU (x4) 176 PCIe to PCI (x4) 112 2G DRAM (x4) 108 Misc 100 PCIe adapter 40 -------------------- 500

------------------------ 2000

I have read somewhere that Atoms are dead slow, even slower than Celerons?

Yes, dead slow, lower power and cheap. That's why it's 50% of equivalent to xeon, but less than 50% cost. If you don't like xeon, go with 1.5GHz dual core ARM A9. I know this question will come up.

There is a very small increase in latency. CPU utilization increases due to the LAG protocol. Another thing is that I'm reading that there may not be any benefit if the destination IP is the same for any link. It works well if there are multiple destinations, such if there are large number of clients.

But if you do buy a switch, buy a larger switch than you need. It would have lower latency if its < 50% utilized.

Cheers