It's not the computer, either. My old Mini (the Austin kind, not the BMW kind) could be made to move without using the accelerator too. It didn't have a computer. It barely knew what electricity was.
Correction: The cpu cache line size of modern cpus is 64 bytes. This means that any random RAM access will load 64-bytes (as a single read). The CPU is then capable of extracting 1, 2, 4, 8 or even 16 byte (SSE2 vector load/stores) sections of that into registers, as a single operation if the data is aligned to its size, or as a few micro-instructions if not. This is no different between 32-bit and 64-bit CPUs.
For #1, RAM is always read / written in a multiple of a cache line, which I believe is 128 bits in most modern CPUs, and is independent of the native data size of the cpu (32 or 64 bits).
I know some about.net, but not enough to explain that. I would question how accurate your measurements are though, because that's quite quick either way.
It's full of errors. Especially the spiel about alignment. In 64-bit mode you don't have to align everything to 64-bits for best performance, only 64-bit-sized values (including memory pointers). The example 16-bit value actually only needs 16-bit alignment for best performance, which is no different to the 32-bit version of the program.
2: The increase in the memory use of pointers doesn't explain Windows x64's extra 300MB of memory use. My bet is on it loading both 64-bit and 32-bit versions of a bunch of libraries in order to support various components of Windows that are still 32-bit (as well as any 32-bit software you run).
3: Saying that a 64-bit version of a program won't be faster... Two things are actually in favour of it being faster: 64-bit mode exposes more and larger registers to use, and also guarantees certain instruction set enhancements exist (SSE2). The latter especially is a huge speedup if you take advantage of it.
What you really want is failure rate within first N years of operation, which you can't calculate from the MTBF figures.
Actually MTBF is defined as failure rate in the "constant failure rate" stage of a components lifetime, which is between the initial failure rate (aka infant mortality) and wear-out failure stage. So it's actually the failure rate over the regular lifetime of the component (typically 1-5 years).
MTBF is not the failure rate of a single disk, it's the average failure rate of disks used in an array. If you have a type of disk with a 100,000 hour MTBF, and use 100 of them (whether in a raid array, a cluster, or 100 individual desktops in a company). Then you will (roughly) replace one disk due to failure for every 1000 hours (100,000 MTBF / 100 disks), or 40 days.
It doesn't try to pretend that a single disk lasts 100,000 hours. That's stupid.
Correction: It was primarily about writing reports (in Word) about what they'd taught you about MS Access. I was specifically told not to hand in an Access DB file, and instead to screenshot everything.
I did an A-Level in ICT. It was primarily about MS Access. I got an E. I went on to do a computer programming course at university. I'm now a computer games programmer (xbox 360, pc and ps3 games specifically). The ICT course was completely useless.
And your download rate gets almost completely destroyed as a result. Other peers/leachers try to find the peers/seeds they can get the highest download rate from, so will disconnect from you if you don't send them anything. Leaving you with any seeds there might be, which are usually overloaded.
Torrenting almost always involves distributing pieces to a lot of other bit-torrent users. Each constitutes a copyright infringement, because you don't have distribution rights (aka copyright).
Even if you buy or own the thing you are bit-torrenting, it's still very much illegal if you don't own the copyright to that thing.
Right. Which is why you multiply smidge's numbers by 1 month to get watt-hours for one month. Which is another point in favour of his numbers not already being in watt-hours.
Actually you have calculated average watts (which is what is really relevant). Your numbers are "watt hours per hour", cancelling to watts, not watt hours.
I have a working (graphical) snake game I wrote in QBASIC (self-taught) saved from the month I turned 13 (the code is of course horrific). School didn't teach me any programming either (I self-taught a variety of languages though), until taking a university course in computer game programming. Fast forward to the present day, and I have one shipped PC/360/PS3 game on my resumé and am a year away from adding a PS3-exclusive to that.
I live in the same economy as you, had the same opportunities. The difference is that I didn't drop out. I followed my dream.
Perhaps the problem isn't with the BBC, but the fact that your internet traffic is proxy'd via the US? You'd also get much better latency if you could get directly onto the internet locally.
Slashdot Mirror
Even if the ingredients are listed, the preparation process and relative amounts aren't. There's more to a "recipe" than the list of ingredients!
It's not the computer, either. My old Mini (the Austin kind, not the BMW kind) could be made to move without using the accelerator too. It didn't have a computer. It barely knew what electricity was.
Correction: The cpu cache line size of modern cpus is 64 bytes. This means that any random RAM access will load 64-bytes (as a single read). The CPU is then capable of extracting 1, 2, 4, 8 or even 16 byte (SSE2 vector load/stores) sections of that into registers, as a single operation if the data is aligned to its size, or as a few micro-instructions if not. This is no different between 32-bit and 64-bit CPUs.
For #1, RAM is always read / written in a multiple of a cache line, which I believe is 128 bits in most modern CPUs, and is independent of the native data size of the cpu (32 or 64 bits).
I know some about .net, but not enough to explain that. I would question how accurate your measurements are though, because that's quite quick either way.
It's full of errors. Especially the spiel about alignment. In 64-bit mode you don't have to align everything to 64-bits for best performance, only 64-bit-sized values (including memory pointers). The example 16-bit value actually only needs 16-bit alignment for best performance, which is no different to the 32-bit version of the program.
2: The increase in the memory use of pointers doesn't explain Windows x64's extra 300MB of memory use. My bet is on it loading both 64-bit and 32-bit versions of a bunch of libraries in order to support various components of Windows that are still 32-bit (as well as any 32-bit software you run).
3: Saying that a 64-bit version of a program won't be faster... Two things are actually in favour of it being faster: 64-bit mode exposes more and larger registers to use, and also guarantees certain instruction set enhancements exist (SSE2). The latter especially is a huge speedup if you take advantage of it.
No, boiling is the substance itself becoming gaseous.
What you really want is failure rate within first N years of operation, which you can't calculate from the MTBF figures.
Actually MTBF is defined as failure rate in the "constant failure rate" stage of a components lifetime, which is between the initial failure rate (aka infant mortality) and wear-out failure stage. So it's actually the failure rate over the regular lifetime of the component (typically 1-5 years).
MTBF is not the failure rate of a single disk, it's the average failure rate of disks used in an array. If you have a type of disk with a 100,000 hour MTBF, and use 100 of them (whether in a raid array, a cluster, or 100 individual desktops in a company). Then you will (roughly) replace one disk due to failure for every 1000 hours (100,000 MTBF / 100 disks), or 40 days.
It doesn't try to pretend that a single disk lasts 100,000 hours. That's stupid.
Correction: It was primarily about writing reports (in Word) about what they'd taught you about MS Access. I was specifically told not to hand in an Access DB file, and instead to screenshot everything.
I did an A-Level in ICT. It was primarily about MS Access.
I got an E.
I went on to do a computer programming course at university.
I'm now a computer games programmer (xbox 360, pc and ps3 games specifically).
The ICT course was completely useless.
You should see my 8086 with 640kB of ram (that I haven't been able to convince to run Windows 3.0 in colour yet) then.
Especially as it's compatible with my optical mouse and TFT monitor, which I find pretty impressive.
Thankyou :)
And your download rate gets almost completely destroyed as a result. Other peers/leachers try to find the peers/seeds they can get the highest download rate from, so will disconnect from you if you don't send them anything. Leaving you with any seeds there might be, which are usually overloaded.
Still, I said almost always.
Personal property right to share your bought copy with a few thousand torrenters? I didn't know there was such a right.
Torrenting almost always involves distributing pieces to a lot of other bit-torrent users. Each constitutes a copyright infringement, because you don't have distribution rights (aka copyright).
Even if you buy or own the thing you are bit-torrenting, it's still very much illegal if you don't own the copyright to that thing.
Indeed. My mistake.
Actually the EU caps only cover calls and texts, not data.
Right. Which is why you multiply smidge's numbers by 1 month to get watt-hours for one month. Which is another point in favour of his numbers not already being in watt-hours.
Actually you have calculated average watts (which is what is really relevant). Your numbers are "watt hours per hour", cancelling to watts, not watt hours.
I would imagine that you'll likely still be able to upgrade by adding a discrete graphics card for quite some time.
I have a working (graphical) snake game I wrote in QBASIC (self-taught) saved from the month I turned 13 (the code is of course horrific). School didn't teach me any programming either (I self-taught a variety of languages though), until taking a university course in computer game programming. Fast forward to the present day, and I have one shipped PC/360/PS3 game on my resumé and am a year away from adding a PS3-exclusive to that.
I live in the same economy as you, had the same opportunities. The difference is that I didn't drop out. I followed my dream.
You could JIT generate Javascript which is then JIT compiled itself...
Perhaps the problem isn't with the BBC, but the fact that your internet traffic is proxy'd via the US? You'd also get much better latency if you could get directly onto the internet locally.
I have a self-dumped pokémon red rom, and it does indeed run pretty well.
Colour me impressed!