Or better yet, check out in-hub motors made by New Generation Motors, or by CSIRO designed for solar cars. They get upto about 98% efficiency, although they'll cost you plenty.
You can figure this out by trial and error just by typing in a bunch of carefully crafted IP addresses.
The bitmap is as you describe, except with the 4 corner pixels missing. So its a 6x6 grid, with the first and last rows having only 4 pixels (and centered). 255.255.255.254 shows the full grid (except the last bit). 255.255.255.255 would show the full grid, but the program doesn't want to accept that one.
Try 4.128.133.224:).
The poker is similar. Starting at the first bit, each "card" is 6 bits, with the last 2 bits ignored. The first 2 bits is the suit, with 00=spades, 01=clubs, 10=diamonds, and 11=hearts, and the remaining four bits is the value, with 0000=A, 0001=2, upto 1100=K.
0.194.202.36 is a royal flush (although you can encode it in other ways as well). Oh, and the website says that it's not working correctly, so they may change this.
The colour is just the last 3 bytes as an rgb value. 0.255.0.0. is red, 0.0.0.255 is blue, etc.
AMD was never really in a position where their chips were the clear MHz winners. Up until the K6/K6-2/K6-3 series, they were always lagging in MHz. The Althon changed that, and for the first time they could out perform the Intel equivalents.
There were brief moments where AMD did have the MHz advantage with the Athlon, but the advantage swapped often between Intel and AMD. Once the P4 was released, that MHz advantage disappeared forever... however the AMD chips could STILL compete in performance, in most cases, even at a lower frequency.
Re:Computer from scratch...
on
Makers
·
· Score: 1
Check out the guy at http://homebrewcpu.com/. He's still working on his, some 5 years and counting:). Serously though, the software side of his project wasn't the most time consuming, it would seem.
The finger icon is a button. When you press it, the LEDs will show you an approximate state of charge for the batteries. Its meant to be used when you have more than one battery, and want to check the state of charge without having to plug it into your computer.
Pressing the finger button should enable the LEDs. If it does not, maybe you aren't hitting it hard enough, or in the right spot, or maybe it got damaged in some way. All I can say is that mine works:).
I am on the UWO solar car team, and these quotes were taken completely out of context. Prior to the accident, the tour was in London Ontario for a media stop, in which UWO participated.
During this time we were interviewed by the media about solar cars in general, and about our car, the SunStang in particular. The quotes in the parent comment were talking specifically about the steering decisions of our team, and have nothing to do with the U of T vehicle or the accident.
Any information as to what may have caused this accident is just speculation at this point. Please let's just wait for the facts before we jump to conclusions.
Dynamo isn't hardware. Dynamo is the dynamic compiler/optimizer. They just happened to use the PA-8000 processors for the implementation since that's HP's own processor, so they might as well use it for their internal projects.
It is possible for dynamically compiled code to be faster than statically compiled code.
Take for example HP's Dynamo project. Dynamo is basically an interpreter of PA-8000 code, but which runs on the PA-8000 processor itself. It's as if you were running an x86 emulator on an x86. Only that Dynamo was designed to dynamically compile and optimize the code it was interpreting. It turned out that the dynamically compiled code ran faster than the static binaries running on the raw processor in almost every case!
True, they weren't running Java, but they were doing dynamic compilation. With a Dynamo based JVM for Java, I'll bet your task of writing C++ code which is faster in all cases would be quite a feat.
Are you referring maybe to the ICON computer? It was a computer comissioned by the Ontario Government to be used in Ontario public schools. The above link has a lot more information.
Caching is controlled completely by the CPU, transparent of the programmer.
Assuming that the kernel is the only code running, and it is small enough to fit into cache, then it will get there eventually.
However, it would make no sense to keep the entire kernel in cache, since most of that code isn't used most of the time. Also, application software is running at the same time, which needs to be cached as well.
In other words, just trust the CPU. It knows what it's doing:).
Makes me wonder what tricks AMD has managed to pull out of their hat to increase 64 bit performance by 20-30%...
They added more registers to an architecture that had very few of them. This is likely where most of the performance increase comes from in 64bit mode on the Opteron, not from the fact that it is 64bit.
This is mostly what branch prediction accomplishes, except that it bases its prediction based on historical data.
Besides that, the P4 (and other processors) already supports prefixes onto branch instructions, which tell the processor how likely the branch is to be taken.
Just a word of caution. If anyone here decides to use carbon fibre in their case mods, keep in mind that it is conductive. Yes, computer cases in general are made of metal, which is conductive as well, but since the carbon is basically a piece of cloth, people forget that it too conducts electricity.
Wouldn't it be nice if we could use the same bookmarks in Konqueror and Mozilla? Store the same emails in KMail and Evolution? Edit the same documents in KOffice and Openoffice.org? People like choice. Let's give it to them! We just have to make it so that the choice is based on quality or feature set or stability or security or whatever, rather than lock-in. We should encourage choice. It is one of the greatest strengths of the open source movement.
This (standardization) is exactly what the freedesktop project is working towards.
Luckily the clipboard problems are simply a lack of standardization between applications. The freedesktop.org people are working on a spec to fix this, and already (afaik) most of KDE and GNOME apps, among others, follow the spec. It's only a matter of time now.
The 5pm camp rule has nothing to do with the fact that the cars are powered by the sun. It's simply for the safety of the teams competing. One of the teams in the past has once calculated that the optimal driving strategy is to drive through the day and night (driving a bit slower at night since you're limited to a 5kWh battery pack). This has been proposed as a rule change a few times for the ASC, but has been rejected simply for safety reasons. (some of) These cars cause enough of a disruption on roads during the day time. And the crews/drivers need their sleep as well. You can't necessairly afford to take a huge team of drivers with you.
Actually there were many teams who weren't able to make it this year. There are only 3 or 4 cars coming from the whole of North America, when it used to be about that amount from Canada alone. It has been a bad year to raise money for a race like this.
Very cool. One feature I'd like to see in the next version of this watch is some sort of hook-up to a computer that would let you record good data on long-term exposure. Still, I want one of these.
As long as you're adding a logging feature, it might be useful to add a GPS receiver as well, so that you can tell where, and not just when the radiation was higher/lower.
Or better yet, check out in-hub motors made by New Generation Motors, or by CSIRO designed for solar cars. They get upto about 98% efficiency, although they'll cost you plenty.
You can figure this out by trial and error just by typing in a bunch of carefully crafted IP addresses.
The bitmap is as you describe, except with the 4 corner pixels missing. So its a 6x6 grid, with the first and last rows having only 4 pixels (and centered). 255.255.255.254 shows the full grid (except the last bit). 255.255.255.255 would show the full grid, but the program doesn't want to accept that one.
Try 4.128.133.224 :).
The poker is similar. Starting at the first bit, each "card" is 6 bits, with the last 2 bits ignored. The first 2 bits is the suit, with 00=spades, 01=clubs, 10=diamonds, and 11=hearts, and the remaining four bits is the value, with 0000=A, 0001=2, upto 1100=K.
0.194.202.36 is a royal flush (although you can encode it in other ways as well). Oh, and the website says that it's not working correctly, so they may change this.
The colour is just the last 3 bytes as an rgb value. 0.255.0.0. is red, 0.0.0.255 is blue, etc.
Now see who can generate the highest score! :)
AMD was never really in a position where their chips were the clear MHz winners. Up until the K6/K6-2/K6-3 series, they were always lagging in MHz. The Althon changed that, and for the first time they could out perform the Intel equivalents.
There were brief moments where AMD did have the MHz advantage with the Athlon, but the advantage swapped often between Intel and AMD. Once the P4 was released, that MHz advantage disappeared forever... however the AMD chips could STILL compete in performance, in most cases, even at a lower frequency.
This timeline should clarify this somewhat.
Check out the guy at http://homebrewcpu.com/. He's still working on his, some 5 years and counting :). Serously though, the software side of his project wasn't the most time consuming, it would seem.
The finger icon is a button. When you press it, the LEDs will show you an approximate state of charge for the batteries. Its meant to be used when you have more than one battery, and want to check the state of charge without having to plug it into your computer.
:).
Pressing the finger button should enable the LEDs. If it does not, maybe you aren't hitting it hard enough, or in the right spot, or maybe it got damaged in some way. All I can say is that mine works
Hope this helped.
I am on the UWO solar car team, and these quotes were taken completely out of context. Prior to the accident, the tour was in London Ontario for a media stop, in which UWO participated.
During this time we were interviewed by the media about solar cars in general, and about our car, the SunStang in particular. The quotes in the parent comment were talking specifically about the steering decisions of our team, and have nothing to do with the U of T vehicle or the accident.
Any information as to what may have caused this accident is just speculation at this point. Please let's just wait for the facts before we jump to conclusions.
Dynamo isn't hardware. Dynamo is the dynamic compiler/optimizer. They just happened to use the PA-8000 processors for the implementation since that's HP's own processor, so they might as well use it for their internal projects.
It is possible for dynamically compiled code to be faster than statically compiled code.
Take for example HP's Dynamo project. Dynamo is basically an interpreter of PA-8000 code, but which runs on the PA-8000 processor itself. It's as if you were running an x86 emulator on an x86. Only that Dynamo was designed to dynamically compile and optimize the code it was interpreting. It turned out that the dynamically compiled code ran faster than the static binaries running on the raw processor in almost every case!
True, they weren't running Java, but they were doing dynamic compilation. With a Dynamo based JVM for Java, I'll bet your task of writing C++ code which is faster in all cases would be quite a feat.More info on Dynamo can be found here.
Are you referring maybe to the ICON computer? It was a computer comissioned by the Ontario Government to be used in Ontario public schools. The above link has a lot more information.
Much more of these (and a lot of other info) at the American's Guide to Canada.
I guess that explains why Bender is based on the 6502 cpu!
Caching is controlled completely by the CPU, transparent of the programmer.
:).
Assuming that the kernel is the only code running, and it is small enough to fit into cache, then it will get there eventually.
However, it would make no sense to keep the entire kernel in cache, since most of that code isn't used most of the time. Also, application software is running at the same time, which needs to be cached as well.
In other words, just trust the CPU. It knows what it's doing
They added more registers to an architecture that had very few of them. This is likely where most of the performance increase comes from in 64bit mode on the Opteron, not from the fact that it is 64bit.
This is mostly what branch prediction accomplishes, except that it bases its prediction based on historical data.
Besides that, the P4 (and other processors) already supports prefixes onto branch instructions, which tell the processor how likely the branch is to be taken.
Just a word of caution. If anyone here decides to use carbon fibre in their case mods, keep in mind that it is conductive. Yes, computer cases in general are made of metal, which is conductive as well, but since the carbon is basically a piece of cloth, people forget that it too conducts electricity.
This (standardization) is exactly what the freedesktop project is working towards.
Luckily the clipboard problems are simply a lack of standardization between applications. The freedesktop.org people are working on a spec to fix this, and already (afaik) most of KDE and GNOME apps, among others, follow the spec. It's only a matter of time now.
The 5pm camp rule has nothing to do with the fact that the cars are powered by the sun. It's simply for the safety of the teams competing. One of the teams in the past has once calculated that the optimal driving strategy is to drive through the day and night (driving a bit slower at night since you're limited to a 5kWh battery pack). This has been proposed as a rule change a few times for the ASC, but has been rejected simply for safety reasons. (some of) These cars cause enough of a disruption on roads during the day time. And the crews/drivers need their sleep as well. You can't necessairly afford to take a huge team of drivers with you.
Actually there were many teams who weren't able to make it this year. There are only 3 or 4 cars coming from the whole of North America, when it used to be about that amount from Canada alone. It has been a bad year to raise money for a race like this.
It's ok. So has everyone else :).
I just went out and got a copy of SS2, after reading several posts on here.
Now there's no way I'm going to sleep tonight... And it's not because I'm still playing... I keep hearing those f**ing monkeys!!
Here is a link to the last audio received from Columbia: http://www.canada.com/toronto/globaltv/info/video/ 020103audio.ram
As long as you're adding a logging feature, it might be useful to add a GPS receiver as well, so that you can tell where, and not just when the radiation was higher/lower.
And we can call it uMovie :).
(u for UNIX, of course!)
Except that it's not the submitter who is the one that can give the permission. It's the site's owner.