The easiest on-ramp to speeding up image/video processing is probably the npp library https://developer.nvidia.com/npp [nvidia.com] It has functionality and syntax similar to Intel's ipp library but uses an NVIDIA cuda-capable GPU to accelerate the operations.
If you want to dig in deeper you could explore OpenACC http://www.openacc-standard.org/ [openacc-standard.org] OpenACC is a directives based approach to accelerator programming. You comment or mark up your code with OpenACC directives that provide additional information that the compiler can use to generate parallel code.
Finally, you can learn CUDA C, or OpenCL, or CUDA Fortran, or NumbaPro, or one of the other programming languages that are supported on the GPU hardware of your choice. NVIDIA's CUDA C compiler is based on LLVM and the IR changes have been upstreamed to LLVM.org, There are several languages and projects in development that are leveraging the LLVM infrastructure to add GPU/parallel support.
[disclaimer: I work for NVIDIA, but the words above are my own.]
"In particular, ZFS’s advanced architecture addresses two of our key performance concerns: random I/O, and small I/O. In a large cluster environment a Lustre I/O server (OSS) can be expected to generate a random I/O workload. There will be 100’s of threads concurrently accessing different files in the back-end file system. For writes ZFS’s copy-on-write transaction model converts this random workload in to a streaming workload which is critical when using SATA disks. For small I/O, Lustre can leverage a ZIL placed on separate SSD devices to maximize performance."
The LLNL ZFS study has been pretty widely publicized in the HPC community. Lustre uses the filesystem API rather than mounting in. Until now Lustre used ext under-the-hood for data storage, so the performance improvement from ZFS is relative to ext. ext3/4 may very well outperform ZFS on a workstation or small server, but that's not the what Lustre is used for (even their test system is ~900TB).
SSE vectors are 128 bits -- that's two doubles, not eight. [There may be 8 sse registers, but that doesn't mean you can do 8 simultanous sse operations.]
It's possible to extend precision using single-single "native pair" arithmetic. There's a paper by Dietz et al on GPGPU.org that discusses this.
This doesn't make GPUs capable of double-precision arithmetic, and doesn't mean they will replace CPUs. But it can be used expand the number of algorithms where the vast "arithmetic density advantage" of GPUs can be applied. Top-end CPUs can do 20-30 single-precision GFLOPS, GPUs have about 10x more GFLOPs in the fragment shader ALUs. That's alot of power if you can figure out how to make it work for your problem.
SSH keys are not a cure-all. In fact, they can be worse than passwords.
Yes worse. Ssh keys are not certificates -- they don't expire and are not revokable. So, if someone compromises your private key, they get access to every host that has your pub key until you visit each host and delete the offending key. Add to this the fact that users can (and often do) create ssh keypairs without putting a password on the private key and the fact that there's no way for an admin to detect and inforce password protection of private keys on off-site machines, and you see the problem.Many sites configure sshd to deny ssh-key access from off-site for just these reasons.
If you're using ssh keys, put a strong password on the private key (man ssh-agent).
The same machine is also sold (more cheaply) as a Sager Notebooks 9880. Sager also makes the 9890, which replaces the NVIDIA 6800U Go video card with an NVIDIA 7800GTX Go.
For even more money, it's also sold as the voodoo envy and the alienware something-or-other. Sager/Widow/Voodoo/Alien all resell the same platform (the Clevo 900T), differing only in cost and extra case flash. Note that Clevo is also producing the 900K, which Athlon64 based, so most of the vendors will soon be offering that product as well.
Disclaimer: I'm the reasonably happy owner of a 9880 that I use for OpenGL research and the occasional Battlefield 2 game.
Though the Information Week article didn't mention this,
an article
at another site makes it clear that Microsoft blocked the outgoing spam messages
during their honeypot experiement.
I'm not sure if you're being serious, but the older B-series
SMC routers (7004AWBR and similar) had RS-232 ports.
During a cable-modem outage I just plugged in an external
modem, made a couple setup changes, and had my whole
house "sucking Internet through a straw" while the cable
company was sorting things out.
As others have indicated, I'm not sure why the WiFlyer
is regarded as a big deal. The SMC hub + an external
modem could do the same thing, plus had a built-in
4 port hub, lpd print server, and much much better wireless
range.
Motorcycle speedos are typically driven off the front wheel, while car speedos are taken off the propshaft coming out of the transmission.
Actually most modern motorcycles have a speed sensor
driven off the engine rather than the old "cable to the front hub"
setup. Exceptions are things like the Kawasaki Ninja 250, which
hasn't had a significant redesign for years.
You won't be able to do the type of things that an
engine like crystal space would enable, but you will have
easy access to web-like hyperlinking and information
presentation. It depends on how game-like you envision
the final product being and what information you are trying
to convey.
Note though, that the BGL CPUs have a double-precision floating point pipeline. The Cell is mostly a single-precision chip, so it's
somewhat difficult to compare performance directly at the moment.
Also - I don't think TWAIN is windows-specific. I seem to recall using TWAIN on a Mac many a year ago...
You're correct, TWAIN is a standard. The MacOS X image caputure tool supports TWAIN drivers. I use it all the time
to drive my Epson Scanner (beats the heck out of Epson's
software).
imac:~ dsouth$ uname -a Darwin imac.local 7.7.0 Darwin Kernel Version 7.7.0: Sun Nov 7 16:06:51 PST 2004; root:xnu/xnu-517.9.5.obj~1/RELEASE_PPC Power Macintosh powerpc
As others have mentioned, you're unlikely to write Quake3 at this point in your programming career. But there are some things you probably can tackle.
Start simple -- do a 2D game, either a simple arcade game or a conversion of a board game.
Build it incrementally -- game programming actually spans many areas, so don't get frustrated if your first creation isn't a graphical wonder with advanced sound and cutting-edge AI.
Since you're new to programming and want to do cross-platform, choose your environment carefully. Python and Java
are probably good choices, and both will probably serve you well in a college CS program. Java also offers the possibility of targeting things like web delivery or cellphones if you want to keep growing your project.
Set achievable milestones -- things that seem impossibly large can be done quicker than you'd think by breaking them into smaller, independently testable units.
On the good side, building a simple game can be a pretty good first project. Simple games are fairly common as 1-2 week assignments in CS courses, so you should be able to tackle one over 5 months. Here's one of my favorites
from Stanford, though it may be a little advanced for a first project.:
Tetris in Java
A 35 million pixel screen would rock for Half-Life 2. Where can I get me one? Looking at the picture, it's kind of like 3 monitors stuck together, so maybe I'll save some money and only get 1/3rd of the setup. How much can that cost? I mean, really.
I know you're joking, but since I'm the hardware architect for
the LLNL viz effort, I'll bite anyway.:-)
Here's what you'll need at minimum:
A lot of display devices (monitors, projectors, whatever)
Sufficient video cards to drive the above (with new cards,
you could do 2 devices per card if you have the
appropriate cards, X configs, and the like).
A sufficient number of nodes to run the cards.
The fastest interconnect you can afford.
Once you've assembled the above, you connect everything
up, install your favorite Linux or BSD distro on each node,
then install DMX. DMX works as an X11 proxy. It dispatches
the X calls to other X11 servers on the appropriate nodes, giving the illusion that
they are all one big X11 server. It also proxies for glX, so
openGL stuff should run correctly.
If you've built a large setup (where "large" means "more than eight screens"), the openGL performance will suffer. In that
case you can also install Chromium which can work with
DMX to provide a more efficient path for the openGL commands.
[The DMX glx proxy broadcasts the gl commands to all
nodes, Chromium can provide a tile sort that only sends
the gl calls to the appropriate nodes.]
Assuming you can get all the above running, there's still
plenty of work. Just keeping eight projectors color balanced
will eat up a few hours of your week. If you want to do frame-locked stereo on your power wall, things get even more complex
(and expensive -- nvidia 3000G/4400G cards aren't typically in
the discount bin at Fry's).
Have fun, openGL stuff looks really cool on powerwalls...:-)
DMSO has been proven to cause cataracts in animal studies. Though this hasn't been observed in humans (yet), it's worth considering before you start swabbing
yourself with random industrial solvents. It also gives you really bad garlic breath, so if you're one of the/. minority that has a spouse or significant other, you might want to stick with asprin.
LSI, DataDirectNetworks, and others all have array systems that can push more than 320MBps (note the big B). I've got filesystems running on six year old SGI hardware that can push more than that to between a single file and a single execution thread. [To be exact, the system can do around 620 MBps over 8 fc1 loops all hooked into the same set of 10 jbod enclosures.]
A single fibrechannel2 interface runs at around 2000 mbps. Both the vendors above produce controllers that can saturate four client side interfaces (~8000 Mbps) and in both cases the limiting factor is the controller and fibre, not the disks. [And in fact both vendors allow you to hook twin controllers to the jbods in order to double the bandwidth.]
There are probably other vendors as well, but I've worked with systems from the two I mentioned and can categorically state that the performance is better than 3200Mbps and has been for at least 4 years.
C++ would be a totally stupid first language; I don't think it's suited as a teaching language at all. Even C is too finicky in many ways.
But Java is a fairly clean language. I'm biased coz I use it a lot, but I'm quite happy with the idea of using it as a teaching language, especially for OO.
To each his own. I think Java is a horrible first language for a CS
curriculum. IMHO,
Joel on Software has it right when
he refers to it as a "pedagogical disaster". First learn the low-level stuff using C (or C++ without objects), then move on to
OOP and Java after you know what a pointer is and how to tell
big-endian from little-endian.
Of course I'm biased since Stanford was doing C++, to Lisp, to Java.
My wife and I both use backpacks from Spire. Great backpacks, comfortable and well-built. [I'm an FAA parachute rigger, and have a soft spot for well-constructed packs -- the materials and construction in Spire's stuff is much higher quality than the competeing products I've seen. The Targus cases in particular are junk.]
The downside is that you'll be spending more than $50. The upside is that the backpack will outlast your laptop. [Mine has been doing 50 mi of motorcycle commuting a day for the last 4 years, my wife's has been hauling schoolbooks for three years. Both have all seams, zippers, and fabric intact, if a little dirty.]
All topics eventually degenerate into anti-Bush commentary.
Oh please. Texas was an object of scorn and ridicule long before the Bushies adopted it. Likewise, it was OK to hate new yorkers long before the Bill and Hill show took up residence there.
It may be a "public key", but the key was never pubically available before now. The public key was RSA encrypted... it was that encryption that was "cracked".
No, the public key is part of RSA encryption, which uses a keypair consisting of a public and private key. Finding the public key isn't "cracking" the encryption for any reasonable definition of the word"cracking" -- it won't allow you to access information encrypted by others with the same public key, it won't allow you to change the private key.
Cars with automatic transmissions have an interlock that prevents shfting out of park unless the brake pedal is depressed. [Prevents people from accidently runniing trough the garage wall if they've accidently "covered' the accelerator rather than the brake.] So if you lock the brake in the upward position, you won't be able to shift the transmission into drive.
I'm not sure how well this lock would work with a manual transmission, but since I drive a motorcycle, I'm not their target market anyway.
Actually, i recall fiddling around with a mac once.. I seem to remember that typing "LS" would result in the same thing as "ls", but if you typed the direct path to it (/bin/LS (i think) instead of/bin/ls) it would say it wasn't found. Also if you were in the same directory as all the executable commands, sometimes it would recognize them in uppercase, sometimes it wouldn't.
That will depend on your shell. BASH/sh/ksh search for executables in your path, so those shells will indeed treat `ls` the same as `LS`. The csh and tcsh shells keep an interal hash table of the executables, so they are case sensitive even though the underlying filesystem is not (with the exception that the current directory is searched regularly rather than being hashed and so behaves like bash/sh).
As to the original poster's comments aobut HFS+ not being case sensitive, it's actually case-preserving, but case insensitive,
Eg:
% touch aFile % touch Afile % ls *ile aFile
Most unix types (myself included) look at that and say "that's just wrong". That was until after I read a long discussion
about the reasoning behind it. Some things to consider:
From a programming standpoint, it is much easier to make
a case insentive or non-case preserving filesystem than it is to do what HFS does (preserve the case, but not use it for matching). So it is not a case of Apple developers being lazy, they actually wanted the current HFS behavior.
If someone told you to go get a file named "Taxes 2004"
from a regular (physical) filing cabinet, and all you found was a file labeled "TAXES 2004" would you think it was the correct file?
If you created two files with the above labels, would you expect anyone else to recognize they were different?
Because HFS is case preserving, most of the things you would normall use cases for still work. [Eg, many people name all directories with a capital letter to help differentiate them from regular files when looking at a directory listing. This works fine in HFS since 'ls' will show the original case.]
Though I'm still emotionally attached to the unix implementation of case sensitivity, I'm increasingly of the opinion that the HFS behavior is the more "correct" one from a user point of view.
I agree with you, but Sun (and a lot of other people) do not -- they refer to the Sun E10K/15K as SMP and the SGI O2K/3K as NUMA. My points were intended to go to the underlying designs (Sun has two tiers of memory latency, SGI has many tiers), not to the nomenclature attached to the Enterprise servers. But feel free to keep beating the dead horse -- I'd be especially grateful and impressed if you could get Sun to change their web pages.:-)
If you mean consistent access times to memory (aka SMP) then yes, the Sun design is more scalable (though, as mentioned, there is still a latency difference between local memory and remote memory). The downside is that you pay for the switch up-front, and the design (and performance) is limited by the size of a single switch.
If by scaleable you mean the maximum number of processors, maximum amount of memory, maximum number of IO channels, maximum cross-sectional bandwidth, or the expandability of a given system, then the SGI design wins.
You add NUMA fabric as you add nodes, so you can start small and grow things. The downside is that it is NUMA, so as the system gets larger so do the latency differences
in memory access (though the OS does manage to hide some of that using things like page replication and migration).
As I eluded to earlier, if I was running Oracle, I'd opt for the Sun,
If I was running HPC loads, I'd opt for the SGI. Actually, now days I'd opt for a cluster of opterons, but that wasn't the question.:-)
Slashdot Mirror
The easiest on-ramp to speeding up image/video processing is probably the npp library https://developer.nvidia.com/npp [nvidia.com] It has functionality and syntax similar to Intel's ipp library but uses an NVIDIA cuda-capable GPU to accelerate the operations.
If you want to dig in deeper you could explore OpenACC http://www.openacc-standard.org/ [openacc-standard.org] OpenACC is a directives based approach to accelerator programming. You comment or mark up your code with OpenACC directives that provide additional information that the compiler can use to generate parallel code.
Finally, you can learn CUDA C, or OpenCL, or CUDA Fortran, or NumbaPro, or one of the other programming languages that are supported on the GPU hardware of your choice. NVIDIA's CUDA C compiler is based on LLVM and the IR changes have been upstreamed to LLVM.org, There are several languages and projects in development that are leveraging the LLVM infrastructure to add GPU/parallel support.
[disclaimer: I work for NVIDIA, but the words above are my own.]
It appears to be based on the linked site:
"In particular, ZFS’s advanced architecture addresses two of our key performance concerns: random I/O, and small I/O. In a large cluster environment a Lustre I/O server (OSS) can be expected to generate a random I/O workload. There will be 100’s of threads concurrently accessing different files in the back-end file system. For writes ZFS’s copy-on-write transaction model converts this random workload in to a streaming workload which is critical when using SATA disks. For small I/O, Lustre can leverage a ZIL placed on separate SSD devices to maximize performance."
The LLNL ZFS study has been pretty widely publicized in the HPC community. Lustre uses the filesystem API rather than mounting in. Until now Lustre used ext under-the-hood for data storage, so the performance improvement from ZFS is relative to ext. ext3/4 may very well outperform ZFS on a workstation or small server, but that's not the what Lustre is used for (even their test system is ~900TB).
Disclaimer: I used to work for LLNL.
- SSE vectors are 128 bits -- that's two doubles, not eight. [There may be 8 sse registers, but that doesn't mean you can do 8 simultanous sse operations.]
- It's possible to extend precision using single-single "native pair" arithmetic. There's a paper by Dietz et al on GPGPU.org that discusses this.
This doesn't make GPUs capable of double-precision arithmetic, and doesn't mean they will replace CPUs. But it can be used expand the number of algorithms where the vast "arithmetic density advantage" of GPUs can be applied. Top-end CPUs can do 20-30 single-precision GFLOPS, GPUs have about 10x more GFLOPs in the fragment shader ALUs. That's alot of power if you can figure out how to make it work for your problem.SSH keys are not a cure-all. In fact, they can be worse than passwords.
Yes worse. Ssh keys are not certificates -- they don't expire and are not revokable. So, if someone compromises your private key, they get access to every host that has your pub key until you visit each host and delete the offending key. Add to this the fact that users can (and often do) create ssh keypairs without putting a password on the private key and the fact that there's no way for an admin to detect and inforce password protection of private keys on off-site machines, and you see the problem.Many sites configure sshd to deny ssh-key access from off-site for just these reasons.
If you're using ssh keys, put a strong password on the private key (man ssh-agent).
For even more money, it's also sold as the voodoo envy and the alienware something-or-other. Sager/Widow/Voodoo/Alien all resell the same platform (the Clevo 900T), differing only in cost and extra case flash. Note that Clevo is also producing the 900K, which Athlon64 based, so most of the vendors will soon be offering that product as well.
Disclaimer: I'm the reasonably happy owner of a 9880 that I use for OpenGL research and the occasional Battlefield 2 game.
Though the Information Week article didn't mention this, an article at another site makes it clear that Microsoft blocked the outgoing spam messages during their honeypot experiement.
I'm not sure if you're being serious, but the older B-series SMC routers (7004AWBR and similar) had RS-232 ports. During a cable-modem outage I just plugged in an external modem, made a couple setup changes, and had my whole house "sucking Internet through a straw" while the cable company was sorting things out.
As others have indicated, I'm not sure why the WiFlyer is regarded as a big deal. The SMC hub + an external modem could do the same thing, plus had a built-in 4 port hub, lpd print server, and much much better wireless range.
FreeWRL
You won't be able to do the type of things that an engine like crystal space would enable, but you will have easy access to web-like hyperlinking and information presentation. It depends on how game-like you envision the final product being and what information you are trying to convey.
Note though, that the BGL CPUs have a double-precision floating point pipeline. The Cell is mostly a single-precision chip, so it's somewhat difficult to compare performance directly at the moment.
Pics of the Terascale Simulation Facility at LLNL that houses blue gene are available here. My office window is on the far left.
- Start simple -- do a 2D game, either a simple arcade game or a conversion of a board game.
- Build it incrementally -- game programming actually spans many areas, so don't get frustrated if your first creation isn't a graphical wonder with advanced sound and cutting-edge AI.
- Since you're new to programming and want to do cross-platform, choose your environment carefully. Python and Java
are probably good choices, and both will probably serve you well in a college CS program. Java also offers the possibility of targeting things like web delivery or cellphones if you want to keep growing your project.
- Set achievable milestones -- things that seem impossibly large can be done quicker than you'd think by breaking them into smaller, independently testable units.
On the good side, building a simple game can be a pretty good first project. Simple games are fairly common as 1-2 week assignments in CS courses, so you should be able to tackle one over 5 months. Here's one of my favorites from Stanford, though it may be a little advanced for a first project.: Tetris in JavaGood luck and have fun.
Here's what you'll need at minimum:
- A lot of display devices (monitors, projectors, whatever)
- Sufficient video cards to drive the above (with new cards,
you could do 2 devices per card if you have the
appropriate cards, X configs, and the like).
- A sufficient number of nodes to run the cards.
- The fastest interconnect you can afford.
Once you've assembled the above, you connect everything up, install your favorite Linux or BSD distro on each node, then install DMX. DMX works as an X11 proxy. It dispatches the X calls to other X11 servers on the appropriate nodes, giving the illusion that they are all one big X11 server. It also proxies for glX, so openGL stuff should run correctly.If you've built a large setup (where "large" means "more than eight screens"), the openGL performance will suffer. In that case you can also install Chromium which can work with DMX to provide a more efficient path for the openGL commands. [The DMX glx proxy broadcasts the gl commands to all nodes, Chromium can provide a tile sort that only sends the gl calls to the appropriate nodes.]
Assuming you can get all the above running, there's still plenty of work. Just keeping eight projectors color balanced will eat up a few hours of your week. If you want to do frame-locked stereo on your power wall, things get even more complex (and expensive -- nvidia 3000G/4400G cards aren't typically in the discount bin at Fry's).
Have fun, openGL stuff looks really cool on powerwalls... :-)
Quick note of caution --
DMSO has been proven to cause cataracts in animal studies. Though this hasn't been observed in humans (yet), it's worth considering before you start swabbing yourself with random industrial solvents. It also gives you really bad garlic breath, so if you're one of the /. minority that has a spouse or significant other, you might want to stick with asprin.
LSI, DataDirectNetworks, and others all have array systems that can push more than 320MBps (note the big B). I've got filesystems running on six year old SGI hardware that can push more than that to between a single file and a single execution thread. [To be exact, the system can do around 620 MBps over 8 fc1 loops all hooked into the same set of 10 jbod enclosures.]
A single fibrechannel2 interface runs at around 2000 mbps. Both the vendors above produce controllers that can saturate four client side interfaces (~8000 Mbps) and in both cases the limiting factor is the controller and fibre, not the disks. [And in fact both vendors allow you to hook twin controllers to the jbods in order to double the bandwidth.]
There are probably other vendors as well, but I've worked with systems from the two I mentioned and can categorically state that the performance is better than 3200Mbps and has been for at least 4 years.
Of course I'm biased since Stanford was doing C++, to Lisp, to Java.
The downside is that you'll be spending more than $50. The upside is that the backpack will outlast your laptop. [Mine has been doing 50 mi of motorcycle commuting a day for the last 4 years, my wife's has been hauling schoolbooks for three years. Both have all seams, zippers, and fabric intact, if a little dirty.]
No, the public key is part of RSA encryption, which uses a keypair consisting of a public and private key. Finding the public key isn't "cracking" the encryption for any reasonable definition of the word"cracking" -- it won't allow you to access information encrypted by others with the same public key, it won't allow you to change the private key.
Actually not.
Cars with automatic transmissions have an interlock that prevents shfting out of park unless the brake pedal is depressed. [Prevents people from accidently runniing trough the garage wall if they've accidently "covered' the accelerator rather than the brake.] So if you lock the brake in the upward position, you won't be able to shift the transmission into drive.
I'm not sure how well this lock would work with a manual transmission, but since I drive a motorcycle, I'm not their target market anyway.
As to the original poster's comments aobut HFS+ not being case sensitive, it's actually case-preserving, but case insensitive, Eg:
Most unix types (myself included) look at that and say "that's just wrong". That was until after I read a long discussion about the reasoning behind it. Some things to consider:
- From a programming standpoint, it is much easier to make
a case insentive or non-case preserving filesystem than it is to do what HFS does (preserve the case, but not use it for matching). So it is not a case of Apple developers being lazy, they actually wanted the current HFS behavior.
- If someone told you to go get a file named "Taxes 2004"
from a regular (physical) filing cabinet, and all you found was a file labeled "TAXES 2004" would you think it was the correct file?
- If you created two files with the above labels, would you expect anyone else to recognize they were different?
- Because HFS is case preserving, most of the things you would normall use cases for still work. [Eg, many people name all directories with a capital letter to help differentiate them from regular files when looking at a directory listing. This works fine in HFS since 'ls' will show the original case.]
Though I'm still emotionally attached to the unix implementation of case sensitivity, I'm increasingly of the opinion that the HFS behavior is the more "correct" one from a user point of view.[I'm mostly joking, but it is somewhat interesting that the two major parties don't even agree on web platforms.]
I agree with you, but Sun (and a lot of other people) do not -- they refer to the Sun E10K/15K as SMP and the SGI O2K/3K as NUMA. My points were intended to go to the underlying designs (Sun has two tiers of memory latency, SGI has many tiers), not to the nomenclature attached to the Enterprise servers. But feel free to keep beating the dead horse -- I'd be especially grateful and impressed if you could get Sun to change their web pages. :-)
If you mean consistent access times to memory (aka SMP) then yes, the Sun design is more scalable (though, as mentioned, there is still a latency difference between local memory and remote memory). The downside is that you pay for the switch up-front, and the design (and performance) is limited by the size of a single switch.
If by scaleable you mean the maximum number of processors, maximum amount of memory, maximum number of IO channels, maximum cross-sectional bandwidth, or the expandability of a given system, then the SGI design wins. You add NUMA fabric as you add nodes, so you can start small and grow things. The downside is that it is NUMA, so as the system gets larger so do the latency differences in memory access (though the OS does manage to hide some of that using things like page replication and migration).
As I eluded to earlier, if I was running Oracle, I'd opt for the Sun, If I was running HPC loads, I'd opt for the SGI. Actually, now days I'd opt for a cluster of opterons, but that wasn't the question. :-)