You typically write code that runs on the main CPU. This program supplies the GPU with data such as vertices, triangles, textures, etc.. For special effects, you can write shader programs for the GPU that modify how the GPU renders specific things. However, most of the code that's running on the GPU is already written for you... at the transistor level.
All a DSP does is do lots of arithmetic operations and memory moves quickly. For example, in a single instruction, the DSP could run an addition and shift operation, move some data from memory to registers, and move some data from registers to memory. Also, DSPs (and the SPU in the cell) tend to perform (relatively) terribly when they run into a conditional statement. Thus, the type of programs that you end up writing for DSPs don't just need special attention when programming; you have to write a whole different kind of program for them than you're used to.
It's a good design, it just doesn't seem like a good design for a video game system. It's a general purpose CPU attached to several CPUs that essentially are DSPs. DSP programming is very weird, and you need to at least understand how the device works on the instruction level for optimal performance. A lot of DSP code is still written in assembly (or at the very least hand-optimized after compilation).
It's very expensive to have DSP code written, when compared to normal CPU code, and video game manufacturers have been complaining that the cost of making a game is too high. Also, most of the complexity in a video game nowadays is handled by the GPU, not the CPU. Now the cell would be great for lots of parallel signal processing, or some other similar task, and I bet it could be used to create a great video game, it would just be prohibitively expensive.
The cell is a great solution to a problem. However, that problem isn't video games. A fast traditional CPU, possibly with multiple cores, attached to a massively pipelined GPU would probably work better for video games.
Debian stable gets bugfixes for significant bugs in later -r1 -r2 releases. This is not limited to security bugfixes. Security bugfixes are the only ones that are pushed out using the security.debian.org repository, however.
Also, modern compilers produce programs using mostly a RISC-like subset of the x86 instructions, because those perform better on modern x86 processors. This has been the case since about the Pentium Pro.
Compile your own kernel with your hardware options selected as compiled in to the kernel, rather than as modules. Then you won't have to load the same set of kernel modules each time, and you won't need an initrd.
I love how many posts there are like this, and how few posts like this actually post the location of the aforementioned store. I'm still trying to find one myself.
It's all about the add-ons. Firefox add-ons give the browser extra functionality. I don't know if Safari has similar functionality (I am not an OS X user), but I'm pretty sure that the sheer number and diversity of add-ons for Firefox would be higher. I use lots of different plugins, from the download statusbar (I hate that download window) to the web developer plugin (great for lots of different things).
Many people find adblock and noscript very useful. Don't forget about greasemonkey, which is helpful for some of the more annoying sites. The list goes on and on. While the browser itself might not be as good as Safari, for some Mac users, the ability to customize is worth it.
I bet the GP was talking about Windows NT. NT 3.1 came out in 1993, and it had the BSOD. When Windows '95 came out, its blue screen was different than NT's, and many had the opinion that only NT's version should be called the blue screen of death.
It's because the hottest and coldest days of the year do not correspond with the solstices. Local temperatures have state, and it takes a while to heat and cool the atmosphere, surface, and oceans.
Re:One recipe this book doesn't cover
on
Rails Recipes
·
· Score: 1
Well, if you're bound to Ruby, I don't know where to start. However, Perl's Class::DBI can do a lot of this type of code generation for you, including the many-to-many references. Combined with something like CGI::Application, you can create a powerful website with very little fuss.
Better watch out for that exponential increase though. That'll get you every time. Before you know it, you'll have a triple duplicate post (this is slashdot, after all) or a dropped server from all that traffic.</humor class="lame">
They carry endpoint IDs, which achieve a similar functionality to IP addresses and TCP/UDP ports, but are also human-readable. DTN protocols are fairly high-level, so they can do that.
No. Normal routing works through space. Packets move from node to node, avoiding nodes and links that are down. DTNs can route through space and time, delaying packets until they can be routed further along.
If you have two networks that are only intermittently connected, normal routing will drop packets when the connection is down. DTNs will allow the packets to be held until the connection is up.
Actually, a planned convergence layer for the DTN project is sneakernet.
DTNs work by storing packets (well, "bundles," really) at the router, until an opportunistic connection is available. Bundles move from hop to hop, until they arrive at their destination.
This is accomplished over a variety of "convergence layers," such as TCP and UDP, with UDP being the most commonly used for transmitting bundles currently in research. However, other convergence layers for other uses are being planned. One of these is sneakernet, where data is copied to physical media, the media is physically taken over to another node, and the other node reads the data and forwards the bundles to the next hop as available.
The PHP interpreter is over 5 megabytes in size. And it isn't thread-safe. That's a lot of memory overhead for a program that's going to be blocking on I/O most of the time, seeing how you'll have to fork() a new process for each new "thread" you want.
Also, languages like Perl and Python have binaries that are about 1 megabyte in size. Now, while they'll probably need to load in extra files for most practical applications, these extra files are typically small. Most importantly, Perl and Python are thread-safe.
Perl, for example, includes libraries such as Thread::Queue, which allows you to very easily create a threading model with worker threads, without having to worry too much about condition variables, mutexes, and the like.
Disclaimer: All measurements done on x86 Debian Linux.
DNS is typically used over UDP. A single query/response pair with only a small amount of data would be very inefficient for TCP. You don't need reliability for DNS. If you don't get your answer back, ask again. Requiring a three-way handshake before sending the query, and then requiring the TCP connection-destroy mechanism is just unnecessary.
Ars Technica ran an interesting piece on this, named You pull, Wii push. They pretty much stated that the Wii has a profit margin per cost significantly higher than the other two consoles, so they help retailers will advertise the Wii more prominently and give it better placement---it's more worth their effort to sell $5000 worth of Wii units than $5000 of the other two consoles. Microsoft and Sony are taking the opposite approach, driving up demand via consumers with direct advertising, but giving lower margins to retailers.
I write my papers in LaTeX, typically. I use vim as my text editor. Every single change I make is written to a swapfile. If my computer crashes, I can reopen the file and recover everything (except maybe my last keystroke). If the system can't write to the swapfile, it tells me so that I can save the original copy, close the program, and reopen it, or otherwise address the problem.
Slashdot Mirror
You typically write code that runs on the main CPU. This program supplies the GPU with data such as vertices, triangles, textures, etc.. For special effects, you can write shader programs for the GPU that modify how the GPU renders specific things. However, most of the code that's running on the GPU is already written for you... at the transistor level.
All a DSP does is do lots of arithmetic operations and memory moves quickly. For example, in a single instruction, the DSP could run an addition and shift operation, move some data from memory to registers, and move some data from registers to memory. Also, DSPs (and the SPU in the cell) tend to perform (relatively) terribly when they run into a conditional statement. Thus, the type of programs that you end up writing for DSPs don't just need special attention when programming; you have to write a whole different kind of program for them than you're used to.
It's a good design, it just doesn't seem like a good design for a video game system. It's a general purpose CPU attached to several CPUs that essentially are DSPs. DSP programming is very weird, and you need to at least understand how the device works on the instruction level for optimal performance. A lot of DSP code is still written in assembly (or at the very least hand-optimized after compilation).
It's very expensive to have DSP code written, when compared to normal CPU code, and video game manufacturers have been complaining that the cost of making a game is too high. Also, most of the complexity in a video game nowadays is handled by the GPU, not the CPU. Now the cell would be great for lots of parallel signal processing, or some other similar task, and I bet it could be used to create a great video game, it would just be prohibitively expensive.
The cell is a great solution to a problem. However, that problem isn't video games. A fast traditional CPU, possibly with multiple cores, attached to a massively pipelined GPU would probably work better for video games.
Debian stable gets bugfixes for significant bugs in later -r1 -r2 releases. This is not limited to security bugfixes. Security bugfixes are the only ones that are pushed out using the security.debian.org repository, however.
Also, modern compilers produce programs using mostly a RISC-like subset of the x86 instructions, because those perform better on modern x86 processors. This has been the case since about the Pentium Pro.
Compile your own kernel with your hardware options selected as compiled in to the kernel, rather than as modules. Then you won't have to load the same set of kernel modules each time, and you won't need an initrd.
I love how many posts there are like this, and how few posts like this actually post the location of the aforementioned store. I'm still trying to find one myself.
As long as they have SoIP support (Sewage over Internet Protocol), you should be fine.
It's all about the add-ons. Firefox add-ons give the browser extra functionality. I don't know if Safari has similar functionality (I am not an OS X user), but I'm pretty sure that the sheer number and diversity of add-ons for Firefox would be higher. I use lots of different plugins, from the download statusbar (I hate that download window) to the web developer plugin (great for lots of different things).
Many people find adblock and noscript very useful. Don't forget about greasemonkey, which is helpful for some of the more annoying sites. The list goes on and on. While the browser itself might not be as good as Safari, for some Mac users, the ability to customize is worth it.
I bet the GP was talking about Windows NT. NT 3.1 came out in 1993, and it had the BSOD. When Windows '95 came out, its blue screen was different than NT's, and many had the opinion that only NT's version should be called the blue screen of death.
It's because the hottest and coldest days of the year do not correspond with the solstices. Local temperatures have state, and it takes a while to heat and cool the atmosphere, surface, and oceans.
Well, if you're bound to Ruby, I don't know where to start. However, Perl's Class::DBI can do a lot of this type of code generation for you, including the many-to-many references. Combined with something like CGI::Application, you can create a powerful website with very little fuss.
Yes. If you were serious, you'd go straight for the hard gammas. ;-)
I would agree. Having to listen to some of those NPR shows *would* be absolute torture.
Slow start ...
Better watch out for that exponential increase though. That'll get you every time. Before you know it, you'll have a triple duplicate post (this is slashdot, after all) or a dropped server from all that traffic.</humor class="lame">
They carry endpoint IDs, which achieve a similar functionality to IP addresses and TCP/UDP ports, but are also human-readable. DTN protocols are fairly high-level, so they can do that.
No. Normal routing works through space. Packets move from node to node, avoiding nodes and links that are down. DTNs can route through space and time, delaying packets until they can be routed further along.
If you have two networks that are only intermittently connected, normal routing will drop packets when the connection is down. DTNs will allow the packets to be held until the connection is up.
Actually, a planned convergence layer for the DTN project is sneakernet.
DTNs work by storing packets (well, "bundles," really) at the router, until an opportunistic connection is available. Bundles move from hop to hop, until they arrive at their destination.
This is accomplished over a variety of "convergence layers," such as TCP and UDP, with UDP being the most commonly used for transmitting bundles currently in research. However, other convergence layers for other uses are being planned. One of these is sneakernet, where data is copied to physical media, the media is physically taken over to another node, and the other node reads the data and forwards the bundles to the next hop as available.
The main research page is at http://dtnrg.org/.
PHP lightweight? Ha!
The PHP interpreter is over 5 megabytes in size. And it isn't thread-safe. That's a lot of memory overhead for a program that's going to be blocking on I/O most of the time, seeing how you'll have to fork() a new process for each new "thread" you want.
Also, languages like Perl and Python have binaries that are about 1 megabyte in size. Now, while they'll probably need to load in extra files for most practical applications, these extra files are typically small. Most importantly, Perl and Python are thread-safe.
Perl, for example, includes libraries such as Thread::Queue, which allows you to very easily create a threading model with worker threads, without having to worry too much about condition variables, mutexes, and the like.
Disclaimer: All measurements done on x86 Debian Linux.
s/$/\//
DNS is typically used over UDP. A single query/response pair with only a small amount of data would be very inefficient for TCP. You don't need reliability for DNS. If you don't get your answer back, ask again. Requiring a three-way handshake before sending the query, and then requiring the TCP connection-destroy mechanism is just unnecessary.
Ars Technica ran an interesting piece on this, named You pull, Wii push. They pretty much stated that the Wii has a profit margin per cost significantly higher than the other two consoles, so they help retailers will advertise the Wii more prominently and give it better placement---it's more worth their effort to sell $5000 worth of Wii units than $5000 of the other two consoles. Microsoft and Sony are taking the opposite approach, driving up demand via consumers with direct advertising, but giving lower margins to retailers.
Their whois info points to tucows as their registrar. Tucows is registered as in Canada. So no, they don't quite have a domain registered in the US.
I write my papers in LaTeX, typically. I use vim as my text editor. Every single change I make is written to a swapfile. If my computer crashes, I can reopen the file and recover everything (except maybe my last keystroke). If the system can't write to the swapfile, it tells me so that I can save the original copy, close the program, and reopen it, or otherwise address the problem.
Hey! Never take away our corrupt politicians and coffee milk! Or, wait, I'm having a second thought on the corrupt politicians ...
It was X2 vs. KFlex. Neither really won---both kind of were combined to form V.90.