You should have a look at the PostgreSQL JDBC documentation, which can be found at http://jdbc.postgresql.org. While you're at it, also search for BYTEA in the PGSQL JDBC mailingslist.
Some of our servers have an ISA PC Weasel card. They're not cheap, but work very well. They completely emulate the videocard/keyboard and you can also reset (and maybe powercycle, not sure about that one) your server with it.
We've got several servers sporting a dual CPU Thunder LE mobo at work and they work marvelously, including serial console. Available with or without dual channel U160 SCSI. We're running FreeBSD on them, btw. The biggest downside is the price.
How important is deletion speed for you? Deleting files on an XFS filesystem is notoriously slow. That does not make XFS a slow filesystem. If you've got really deep and large directory trees, XFS will be able to handle that much better than EXT2FS.
Raw transfer speed will probably be better on a EXT2FS filesystem. Depending on the FAT16 implementation, writing to a FAT16 filesystem is going to be even faster. This has been tested using PostgreSQL and a large database (check the pgsql mailinglists for details).
Please note that Sparc64 is Fujitsu's 64-bit SPARC processor, which is not completely compatibel with Sun own 64-bit SPARC processor, called UltraSparc. They've been working on getting FreeBSD to work on the UltraSparc architecture, since the DEC^H^H^HCompaq road seems to be a dead end...
A SparcStation 5/170 is almost twice as fast as a 5/110 and is the only SparcStation to use a TurboSparc CPU. Linux (in the past) had problems running on it (crashed like crazy, due to the CPU), but NetBSD ran just fine. The problems with Linux may have been solved. The SS5/170 performs a bit better than a 200 MHz Pentium. However, under high load (ie. webserver) it performs quite a bit better than Intel hardware, probably due to the fact that task switching on a Sparc CPU is much cheaper. Quite a nifty little box.
I now use a Ultra 10 (running Solaris 8) with a 440 MHz UltraSparc IIi and it feels quite a bit faster than my 433 MHz Celeron box. I'm using the on-board videocard (PGX24?) and it has a standard HD15 VGA connector. I think the Ultra 5 does too.
I sincerely doubt you'd want that. If your CPU was able to achieve 2000 MHz, when not under load and 600 MHz when under load (hot), I'm pretty sure they'd sell it as a 2 GHz and not a 600 MHz processor (like with the P4). Apart from this, the idea is interesting.
I did some testing on my own SGI Indigo2 R10K and my Sun Ultra 10 workstation at work. When I use the SGI compiler (MIPSpro 7.1 in my case) the compiled code is at least 30-50% faster than the gcc 2.95.2 compiled code. On the SPARC however, using gcc generated much faster code than Suns own compiler (Forte 4, I think). Another example is Compaq; their ccc compiler generates much faster code than gcc and to boot (unlike MIPSpro) it's free!
Now I find myself wondering about a few things.
Why is gcc so poorly optimized for 'exotic' architectures?
Does anyone really use C for computational work, knowing that the GNU Fortan compiler performs even worse?
Why is Sun selling such a crappy compiler?
The fact that SGI and Compaq (Digital) have such good compilers may be explained that their machines are being used in scientific establishments where CPU performance is key, while Suns machines are the favourites of dotcom farmers requiring massive amounts of IO (databases, etc). When an uni needs a new super computer they'll look to SGI, Compaq (Alpha), Intel (they've got very good compilers) and maybe even IBM (SP2). But I've never heard of an uni using a Sun for a super computer (cluster of UE10000's anyone?)
SARA, a dutch institution that maintains and houses several of Hollands super computers, is housing mostly SGI/Cray, Alpha and IBM hardware (and even some beowulf clusters). They do have a lot of Sun hardware, but most of it is being used as a web or database server.
My point? Well, maybe compiler (gcc and vendor) performance is influenced by heritage. In a scientific setting people will use the vendor supplied compiler, demanding and paying for premium performance. They don't really feel the need to contribute a very good code optimizer to the gcc project. However, in the dotcom world everything must be done as cheap as possible with maximum (ahem) performance. Hence, there are a lot of people tinkering with gcc for Intel (and maybe even SPARC).
Whatever the case the may be, the day gcc generates working 64-bit code I'll drink a few beers for the guys working on gcc. As it stands now, gcc can't generate a decent (maybe I should say working) 64-bit binary for both the SGI and SPARC platforms:( (I haven't tried it on an Alpha yet.)
And yes, I'm one of those CS drop-outs (web farmer) being forced to accept a fairly large amount of cash for trivial work while I would prefer doing research work for a minimum wage. Oh well, we can't all be brilliant.
I don't know how memory intensive your application will be, but you should be aware of the fact that memory access on a laptop is usually quite a bit slower than memory access on a desktop/server. Also, the memory speed can vary wildly between different brands and configurations.
We've got a couple of Dell Inspiron laptops that do about 280 MB/sec (according to SiSoft Sandra 2001se), while we've also got some noname laptops that only do about 160-170 MB/sec. The Dells got a 500 MHz Pentium III (100 MHz bus), the noname laptop a 500 Celeron (66 MHz bus). rc5des runs about the same speed on both types of laptops, but seti@home is quite a bit faster on the Dell (seti@home is much more memory intensive than rc5des). This speed difference can be explained by the fact that the Dell uses a 100 MHz bus and faster RAM.
My noname desktop (Athlon 650 MHz) does about 420 MB/sec and runs rc5des and seti@home about 60-80% faster.
The only unfortunate thing is that when I took her class, she was teaching Pascal, which has fallen by the wayside. Sure could use a teacher like her in my efforts to learn C++ and Java.
Why is this unfortunate? All the underlying principles you've been tought still hold true for other languages, such as C or Java. Sure, you'll need to learn a new language, but you should be able to get very comfortable with a new language in a couple of weeks. Personally I think Pascal is a great language for teaching programming principles. Languages such as C or Java (not to mention C++) have too much overhead for people new to programming; just look at the number of lines a minimalistic 'Hello World' program needs...
Of course, a lot depends on the type of computing you are going to do. Since you're thinking of using a Beowulf cluster, I'm assuming the amount is 'fairly' limited and that you are able to partition your problem across several nodes without too much trouble.
That should read 'the amount of traffic between nodes is'...
Of course, a lot depends on the type of computing you are going to do. Since you're thinking of using a Beowulf cluster, I'm assuming the amount is 'fairly' limited and that you are able to partition your problem across several nodes without too much trouble.
The easiest solution is probably using MPI for all communication, like some suggested before. However, you would be completely ignoring the fact that your nodes do have two tightly coupled CPUs. Because of this you may not get the best performance from your system. Since this is a hybrid system (looesely coupled between nodes, tightlly coupled between the two CPUs of a node) you might as well use this to your advantage.
If performance is your thing, why not off-load the SSL calculations to some dedicated hardware?
For instance Rainbow (isglabs.rainbow.com) sells some really nice hardware. It includes drivers for Linux and FreeBSD. It also works with most popular web servers, including Apache.
Those Indigos, while nice, aren't exactly real performers anymore (especially if they've still got R3000 CPUs). A modern day CPU, such as an AMD Athlon, will run circles around a bunch of those SGI boxes. If you want performance, buy an AMD Duron or even a Thunderbird. A Pentium III would do nicely too.
However, if you're into this kind of stuff (clusters, etc), this is going to be a lot of fun!
You could use a free raytracer, such as POVray or BMRT, which should give you excellent quality output. You should still be able to find IRIX 5.3 binaries of both programs. You'll need to use some other program to convert your CAD files to one of the formats supported by these raytraces. There are several programs that can do this.
Boring? Just imagine the possibilities single-chip, IPv6 capable micro-webservers have to offer. It's a bit like X10 taken to the extreme, for only a few dollars per device.
You might not find this exciting, but I see great potential in developments like this.
Hi Edwin, It doesn't seem to be Chello. They do have a 128 kbit upstream limit (1.5 mbit downstream), but I've never noticed it dropping to 64 kbit. Chello does work with rather vague traffic restrictions (they call it 'fair use' - yeah right). I usually stay below 30-50 gbit a month, so I don't really know when they'll start complaining. Mathijs
Well, it'll be either that or a change in the way Microsoft licensing works. How about this: you buy a PC with Windows 2000 at no extra charge. However, they forgot to inform you that only the first month is free. After that, you'll have to pay an annual subscription. This would make Wintel stuff even cheaper, since it hides the cost of the OS.
Some people say perl sucks. They point to some piece of perlcode crawling along at 3 miles/hour. 'Look, perl sucks!'.
Then, when they take a look at the programmers next project (written either in C of Java), they find out it also crawls along at about 3 miles/hour. 'Gee, how can that be?'
The best recipe for a fast program is a smart algorithm. If you give the job to a mediocre programmer, nothing's going to save your project (except maybe buying that $30K quad-Xeon machine).
There are occasions perl isn't a good choice though. For instance, the software operating a sidewinder missle probably should be written in some other language. Apart from that, just about anything can be written in perl;)
Whatever happened to cachedot? Did I miss a post or something some time ago? cachedot has stopped working more than two weeks ago. I mailed Rob about this, but we all now how busy he is...
I would put one SOC+ board in though for connection to a few A5000's (20 x 9.1/18GB each). That should be fast enough.
The E450 has enough room to house 7 disks without having to give up on PCI slots (or so I remember). Using 18 GB disks, that'd be more than 100 GB of RAID5 storagespace. More than enough to store a couple of hours worth of frames. Also, diskspeed is probably not a critcal issue. RAID5 would be pretty essential, since loosing several frames could be rather expensive.
Also, there shouldn't be any problem with heat. The E450 is designed to accomodate 10 PCI boards both in terms of spacially and thermally.
Yes, but I bet it's not designed to take 6 cards that each contain 4 CPU's that may be up to 50/60 degrees C. On the other hand, an E450 can take a maximum of 21 disks. 21 (7200 or 10K RPM) disks would probably generate more heat.
Slashdot Mirror
You should have a look at the PostgreSQL JDBC documentation, which can be found at http://jdbc.postgresql.org. While you're at it, also search for BYTEA in the PGSQL JDBC mailingslist.
Some of our servers have an ISA PC Weasel card. They're not cheap, but work very well. They completely emulate the videocard/keyboard and you can also reset (and maybe powercycle, not sure about that one) your server with it.
We've got several servers sporting a dual CPU Thunder LE mobo at work and they work marvelously, including serial console. Available with or without dual channel U160 SCSI. We're running FreeBSD on them, btw. The biggest downside is the price.
How important is deletion speed for you? Deleting files on an XFS filesystem is notoriously slow. That does not make XFS a slow filesystem. If you've got really deep and large directory trees, XFS will be able to handle that much better than EXT2FS.
Raw transfer speed will probably be better on a EXT2FS filesystem. Depending on the FAT16 implementation, writing to a FAT16 filesystem is going to be even faster. This has been tested using PostgreSQL and a large database (check the pgsql mailinglists for details).
Please note that Sparc64 is Fujitsu's 64-bit SPARC processor, which is not completely compatibel with Sun own 64-bit SPARC processor, called UltraSparc. They've been working on getting FreeBSD to work on the UltraSparc architecture, since the DEC^H^H^HCompaq road seems to be a dead end...
Some more info:
A SparcStation 5/170 is almost twice as fast as a 5/110 and is the only SparcStation to use a TurboSparc CPU. Linux (in the past) had problems running on it (crashed like crazy, due to the CPU), but NetBSD ran just fine. The problems with Linux may have been solved. The SS5/170 performs a bit better than a 200 MHz Pentium. However, under high load (ie. webserver) it performs quite a bit better than Intel hardware, probably due to the fact that task switching on a Sparc CPU is much cheaper. Quite a nifty little box.
I now use a Ultra 10 (running Solaris 8) with a 440 MHz UltraSparc IIi and it feels quite a bit faster than my 433 MHz Celeron box. I'm using the on-board videocard (PGX24?) and it has a standard HD15 VGA connector. I think the Ultra 5 does too.
I sincerely doubt you'd want that. If your CPU was able to achieve 2000 MHz, when not under load and 600 MHz when under load (hot), I'm pretty sure they'd sell it as a 2 GHz and not a 600 MHz processor (like with the P4). Apart from this, the idea is interesting.
Is that a Gormengast reference I see before me? Sounds a lot like Swelter...
Now I find myself wondering about a few things.
The fact that SGI and Compaq (Digital) have such good compilers may be explained that their machines are being used in scientific establishments where CPU performance is key, while Suns machines are the favourites of dotcom farmers requiring massive amounts of IO (databases, etc). When an uni needs a new super computer they'll look to SGI, Compaq (Alpha), Intel (they've got very good compilers) and maybe even IBM (SP2). But I've never heard of an uni using a Sun for a super computer (cluster of UE10000's anyone?)
SARA, a dutch institution that maintains and houses several of Hollands super computers, is housing mostly SGI/Cray, Alpha and IBM hardware (and even some beowulf clusters). They do have a lot of Sun hardware, but most of it is being used as a web or database server.
My point? Well, maybe compiler (gcc and vendor) performance is influenced by heritage. In a scientific setting people will use the vendor supplied compiler, demanding and paying for premium performance. They don't really feel the need to contribute a very good code optimizer to the gcc project. However, in the dotcom world everything must be done as cheap as possible with maximum (ahem) performance. Hence, there are a lot of people tinkering with gcc for Intel (and maybe even SPARC).
Whatever the case the may be, the day gcc generates working 64-bit code I'll drink a few beers for the guys working on gcc. As it stands now, gcc can't generate a decent (maybe I should say working) 64-bit binary for both the SGI and SPARC platforms :( (I haven't tried it on an Alpha yet.)
And yes, I'm one of those CS drop-outs (web farmer) being forced to accept a fairly large amount of cash for trivial work while I would prefer doing research work for a minimum wage. Oh well, we can't all be brilliant.
We've got a couple of Dell Inspiron laptops that do about 280 MB/sec (according to SiSoft Sandra 2001se), while we've also got some noname laptops that only do about 160-170 MB/sec. The Dells got a 500 MHz Pentium III (100 MHz bus), the noname laptop a 500 Celeron (66 MHz bus). rc5des runs about the same speed on both types of laptops, but seti@home is quite a bit faster on the Dell (seti@home is much more memory intensive than rc5des). This speed difference can be explained by the fact that the Dell uses a 100 MHz bus and faster RAM.
My noname desktop (Athlon 650 MHz) does about 420 MB/sec and runs rc5des and seti@home about 60-80% faster.
Just some useless numbers...
Yeah, right, great idea! You want to turn personal computers into an overly complicated TV.
This is not what bothers me. Have you thought about the servers actually running the applications? They're going to need one darn stable OS...
MathijsThere are several good XML parsers, some free, some commercial. Have a look at the following URLs for more info on free versions:
xml.apache.org
users.iclway.co.uk/mhkay/saxon
www.jclark.com/xml
I hope this is of some use to use.
Why is this unfortunate? All the underlying principles you've been tought still hold true for other languages, such as C or Java. Sure, you'll need to learn a new language, but you should be able to get very comfortable with a new language in a couple of weeks. Personally I think Pascal is a great language for teaching programming principles. Languages such as C or Java (not to mention C++) have too much overhead for people new to programming; just look at the number of lines a minimalistic 'Hello World' program needs...
Need I say more? Greg knew it al ;)
Of course, a lot depends on the type of computing you are going to do. Since you're thinking of using a Beowulf cluster, I'm assuming the amount is 'fairly' limited and that you are able to partition your problem across several nodes without too much trouble.
That should read 'the amount of traffic between nodes is'...
Of course, a lot depends on the type of computing you are going to do. Since you're thinking of using a Beowulf cluster, I'm assuming the amount is 'fairly' limited and that you are able to partition your problem across several nodes without too much trouble.
The easiest solution is probably using MPI for all communication, like some suggested before. However, you would be completely ignoring the fact that your nodes do have two tightly coupled CPUs. Because of this you may not get the best performance from your system. Since this is a hybrid system (looesely coupled between nodes, tightlly coupled between the two CPUs of a node) you might as well use this to your advantage.
If performance is your thing, why not off-load the SSL calculations to some dedicated hardware?
For instance Rainbow (isglabs.rainbow.com) sells some really nice hardware. It includes drivers for Linux and FreeBSD. It also works with most popular web servers, including Apache.
Mathijs
Hi
Those Indigos, while nice, aren't exactly real performers anymore (especially if they've still got R3000 CPUs). A modern day CPU, such as an AMD Athlon, will run circles around a bunch of those SGI boxes. If you want performance, buy an AMD Duron or even a Thunderbird. A Pentium III would do nicely too.
However, if you're into this kind of stuff (clusters, etc), this is going to be a lot of fun!
You could use a free raytracer, such as POVray or BMRT, which should give you excellent quality output. You should still be able to find IRIX 5.3 binaries of both programs.
You'll need to use some other program to convert your CAD files to one of the formats supported by these raytraces. There are several programs that can do this.
You might not find this exciting, but I see great potential in developments like this.
Hi Edwin, It doesn't seem to be Chello. They do have a 128 kbit upstream limit (1.5 mbit downstream), but I've never noticed it dropping to 64 kbit. Chello does work with rather vague traffic restrictions (they call it 'fair use' - yeah right). I usually stay below 30-50 gbit a month, so I don't really know when they'll start complaining. Mathijs
God, I'm glad I'm not a Windows user anymore.
Then, when they take a look at the programmers next project (written either in C of Java), they find out it also crawls along at about 3 miles/hour. 'Gee, how can that be?'
The best recipe for a fast program is a smart algorithm. If you give the job to a mediocre programmer, nothing's going to save your project (except maybe buying that $30K quad-Xeon machine).
There are occasions perl isn't a good choice though. For instance, the software operating a sidewinder missle probably should be written in some other language. Apart from that, just about anything can be written in perl ;)
Mathijs
Whatever happened to cachedot? Did I miss a post
or something some time ago? cachedot has stopped
working more than two weeks ago. I mailed Rob
about this, but we all now how busy he is...
Mathijs
They don't got internet games!! ahaah they suck!
But they do, mister President. The PlayStation 2 does have a modem, so Internet games are bound to appear somewhere down the line.
Btw. I wish SGI would hurry up with those CrayStations... It's supposed to be as much fun as a herd of Vaxen.
Mathijs
Yes, but three are 32-bit only.
I would put one SOC+ board in though for connection to a few A5000's (20 x 9.1/18GB each). That should be fast enough.
The E450 has enough room to house 7 disks without having to give up on PCI slots (or so I remember). Using 18 GB disks, that'd be more than 100 GB of RAID5 storagespace. More than enough to store a couple of hours worth of frames. Also, diskspeed is probably not a critcal issue. RAID5 would be pretty essential, since loosing several frames could be rather expensive.
Also, there shouldn't be any problem with heat. The E450 is designed to accomodate 10 PCI boards both in terms of spacially and thermally.
Yes, but I bet it's not designed to take 6 cards that each contain 4 CPU's that may be up to 50/60 degrees C. On the other hand, an E450 can take a maximum of 21 disks. 21 (7200 or 10K RPM) disks would probably generate more heat.
Mathijs