I would personally spin each flash and other widgets (such as animated GIFs) in their own threads to spare myself the trouble of having centralized coordination of their independant/unrelated refresh requirements.
As an FPGA/VLSI person/engineer, I like parallelism. As a coder, I am a multi-threading freak.
Most coders have a hard time getting used to inherent parallelism... when I taught digital design, the simultaneous nature of gate-level designs caused major mind blocks for many students at least up to half-way through the lab project.
"The energy of the tritium-emitted beta particles (maximum, 0.018 MeV) is quite weak, compared to the range of beta particle energies (maximum, 1.7 MeV), but is sufficient to produce ionizations and excitations of molecules in their path. The average range of these beta particles in water is less than 1 m. Because of the low energy and short range of the beta particles, tritium does not pose an external radiation hazard; the radiation is not sufficiently energetic to pass through skin."
Tritium is present in drinking water and the atmosphere just like Deuterium is. When your atomic Tritium battery is dead, simply have it refilled - the previous "charge" can probably be safely vented outdoors.
Smoke detectors have a tiny bit of radioactive materials in them too.
In the UK, there are tritium-powered glow-lights on retail shelves and online stores... Tritium barely qualifies as a hazardous substance as long as you do not intentionally inhale or drink it.
This way, the spy/trojan threads would not be able to presume anything about what else is being executed along with them unless they happened to be the only other running processes.
Of course, quad-threading on a P4 would be futile given that it has only a three-ways instruction decoder and integer execution units. If Intel replaced the AGUs by one extra complex ALU and two additional simple ALUs, quad-threading would become practical... though the six-ways instruction decoder and register files might not.
Try upgrading a shared library that is currently in use by a dozen applications... the only way to make those programs reload the libraries is to restart them.
Since Windows is slightly less flexible about file deletions/replacements than Linux/ext2/3, the DLLs are locked on the disk until the apps are closed, the simplest way to guarantee that all DLLs queued for update are unlocked is to reboot.
On Linux, files are locked for as long as they are opened and are truly deleded only after all file handles to them have been closed. If you want, you can load 1000 different copies of/etc/lib/zlib.so from that exact file name... but the only ways to guarantee that all loaded instances of it have been upgraded is to either manually terminate all programs that loaded previous copies or reboot. The manual termination route is generally too inconvenient for typical users.
Well, this still does not change the fact that EULAs are generally trivial to work around of and that a company would have to prove that people have read and agreed to them... which is rarely the case when someone installs software and others use it, as often the case on shared PCs and PCs maintained my someone other than the owner(s) and primary user(s).
One very simple example: I go to a local computer store and play with the stuff that is on display, write up a wrap-up of all the crappy stuff I tried, where are the EULAs here?
Commercial products, software or otherwise, are in the public domain and therefore cannot avoid criticism, however restrictive whatever EULA they may come with may try to be. It is unlikely that any reasonable judge would rule against verifiable observations against commercial products, however damaging the findings may be. Opposing speech about public facts is highly unlikely to succeed.
NDAs are about protecting trade secrets, not exactly comparable to criticism/review of commercialized (public) products.
Radiative cooling does not work particularly well until something like 250C, few (if any) semiconductors would ever survive using this cooling method... most power semiconductors are specified for 125-175C maximum junction termperature while most logic devices fall in the 65-75C range.
As for fan noise, most HSF have this flaw in common: they place the fan immediately on the heatsink. Every time a blade crosses a fin, this messes up the airflow, generating noise and pressure losses which reduce effectiveness/airflow. Another common issue with typical HSF is that because the fan is directly on top, the heatsink's center is an air flow dead-zone.
I have not seen them for myself but Intel's orb-like P4 HSF and their BTX reference design seem like good examples of proper designs, they both provide some clearance and avoid dead-zones.
Last time I read a story about OLED I did not see a mention of blue problems... but losing as much as half the brightness over as little as a year can be somewhat of a problem for anything that is lit for a significant part of the year. IIRC, brightness degradation over the first three years was expected to be as bad as 80% of continuously lit.
This was eight or so months ago and I am betting the 80% figure must have migrated to the fifth year by now... and probably beyond the seventh year by the time the first retail OLED displays reach the shelves next year.
I hope these will feature decent resolutions at decent prices. After using my laptop continuously for a few months, going back to my desktop's 19" CRT's imperfect geometry and non-uniform misconvergence/focus is barely bearable... and by decent resolutions I mean at least WSXGA+ or UXGA - I would be using my CRT at 2048x1536 if I was able to achieve acceptable and reasonably uniform focus and convergence with it... and I would be using two of them if my second shelf could support a 27kg load. (Actually, the main shelf is rated at 25kg so I am already over the line.)
A pair (or possibly even a trio) of 19" WUXGA OLED displays would be nice, I could start coding double-ultra-wide long lines of code, I would not need so many line breaks anymore!
I am not going to contest the validity of NDAs... most NDAs are meant to protect trade secrets and priviledged information not available to the general public, generally related to unreleased products and internal projects.
Most NDAs have real-world justificative reasons behind them. Non-disclosure/comparison clauses in EULAs are highly questionable at best since their only net effect is hindering public review.
And yes, not being to be able to get a refund for software after finding out that one does not find the EULA acceptable is highly moronic if there is no practical way of checking it out until after unwrapping it... and sometimes, the printed EULA does not match the click-through EULA... and even the click-through EULA may be amended by online updates.
There are way too many ways for companies to screw customers over with these things. Me, I have roughly the same attitude with EULAs as I do with pop-ups: just click whatever it takes to make it go away and be on my merry way.
I guess I should write my own EULA to promote my projects...
"You may freely use this software on the condition that you only speak good of it, saying or demonstrating anything bad about it violates this EULA and may net you a silly but insanely expensive lawsuit."
This is how I perceive these unreasonable clauses. As far as I am concerned, these are void and unenforceable since we all know they will only make the related conversations move to less obvious/official channels.
BTW, if companies were allowed to limit their customer's free speech by sales (or other) agreements, we would not be seeing the *sucks.com company sites fight off corporate lawsuits so easily and frequently.
As I said in my post, these licenses try to limit open discussion about publically available products. To me, this reads very much like an attempt to impede free speech for very questionable reasons.
If the USA truly is the "land of the free", it must be for a different reason... what kind of free country allows corporation to dictate how people can discuss about their *published* works? If a company does not want its products criticised, analyzed and compared, it should simply not release them to the general public!
What part of an NDA applies to PUBLICALLY AVAILABLE products? You and many others apparently missed this detai from my post.
If I publish something, it is free game to all criticism and no EULA should be able to prevent it... but some do try, with the "If any clauses should be found not to apply, this shall not affect applicability of all other clauses" umbrella so EULA writers can lay it on as thick as they feel like.... at least until the day judges decide to protect the general public and decide to void in whole EULAs containing any form of illegal clauses - zero nonsense tolerance.
If you go in the 586/Pentium-class chips, 200MHz is no big deal, the non-MMX Pentium went to 200MHz and the MMX version was mass-produced up to 233MHz, where it was madly successful as a notebook chip.
I do not see why people should be authorized to conduct reviews and benchmarks of publically available products.
Surprisingly (controversially?) enough, some EULAs forbid public criticism - I wonder if such clauses would ever be found valid in court, I seriously hope not - judges should declare void in whole any EULA that includes any anticonstitutional demands.
Now that I think about it, I seem to remember that M$ used to include a non-comparison clause in many of its products' EULAs, this "licensed comparison" tells me it probably still does.
Consider branchy code... the only option for a single-threaded CPU is to do speculative execution and backtrack if it mispredicted, this is good for single-threaded performance, not so good for overall throughput. With SMT, instead of doing speculative execution, the CPU can simply reallocate resources to the other thread until some of the first thread's dependencies have been resolved.
To me, replacing speculative exection by known useful execution is always a good thing no matter how deep the pipeline may be. Since adding SMT costs something like one or two milion transistors, I hope AMD will jump on this wagon soon - much less expensive silicon-wise than extra cores and cache. On my P4, the second thread gives me a 20-50% throughput bonus, not bad for a 5% cost in die size - and this extra performance costs me only 6W more on top of the 60W difference from idle to full single-thread load. (Approximate line measurements from UPS - actual figures for the CPU are probably ~30% less.)
So, SMT is a silicon-efficient and power-efficient way to gain 20-50% extra performance for nearly free if you overlook the extra silicon and software engineering effort necessary to make it work properly.
Since AMD64 has quad instruction decoders and more execution units than the P4, AMD's SMT chips (late 2006) will probably wipe the floor with the P4's unless Intel pulls an ace - which they very well can and may.
Back then, Intel had managed to build a 10GHz 64bits register file and 8GHz full adder, I presume they were hoping to spread this goodness across all sub-circuits and the devil popped out on the way towards integration... each test sub-circuit is able to reach ~10GHz on its own but once you pack the register file with 500+ adders to form multipliers, address generators, etc. mixed with other general-purpose logic, being able to get the integrated design anywhere close to what was achieved with individual sub-circuits is a whole different story.
They most likely did it on good faith and overoptimistic hopes.
Back when the first Prescott rumors started popping up, Intel's hopes for it were as high as 5GHz for the end of 2004... the Intel side has been stuck in the 3Gs for almost three years now. The story is similar AMD-wise but around 2Gs instead.
And now that it is open season on multicore, clock speed will soon become a secondary matter.
For many enthrusiasts, Netburst seemed like a bad idea long before Prescott... many were massively underwhelmed right from the architecture's initial debut. When the P4 began at 1.6GHz, it lost pretty much every benchmark known to man to the 1-1.4GHz P3s. It was not until the 2.4GHz P4 that Netburst managed to beat the 1.4GHz P3 across the board. And today, we have the 2GHz Pentium-M giving the 3.6GHz Pentium-4 a run for its money. (Or maybe not, I have not checked the actual prices.)
The Pentium-M is much like a P3 on steroids, they both are among Intel's best and greatest.
Although the P4's single-threaded IPC very much sucks, Netburst did give us the first multi-threaded desktop CPUs - the only SMT desktop CPUs out there actually - and when things are written to exploit multi-threading to some decent extent, Netburst does not look so bad anymore.
One of AMD's IPC advantages comes from its quad instruction decoder vs the P4's triple... I wonder what sort of boost P4/HT would get from this hypothetical upgade - Intel's capabilities bits have a configuration for 16k uOP I-Cache for this case, maybe a chip featuring this will materialize in the near future... back to before the Prescott launch, there were rumors of it being a 16K chip but it was only wishful thinking.
Last time I checked, my two P3s, my P4-3G and A64-3000+ rarely exceeded 50C under constant 100% load and closed cases... and the P4 is in a rather crappy Antec Aria case: although the PSU has a 120mm fan, it runs at 1800ROM max and the PSU's casing has almost no internal venting - there are two models of that PSU and I got the venting-deficient one.
There are many reasons why I got a P4-3G... first because I am cheap, then because I wanted multi-threading and also because I did not want to set a foot too close to the >90W area.
Of course, I am not one of those who run their RAM at 3V and cores at 2V...
Basicaly, they don't realise it, but they are coming full circle, and the outcome is just going to be a another eDonkey network. Which means, why not just use the existing one.
Here goes one reason: 9500KB pieces Another: MD5-class hashes
The eD2k network uses oversized basic blocks and weak reference block hashes. Wasting up to 9.28MB because someone sent a bad bit is somewhat wasteful. So far, I have yet to see a torrent with >1MB pieces. Since MD5 is EOL, it is very likely that undetectable corruption exploits will appear in the near future (ViralG?). Killing legacy eD2k would be a good thing - those oversized blocks need to go, hopefully to be replaced by a scalable recursive tree hash.
There once was such a thing as electroacoustic memory - a mercury cylinder with a piezo element at both ends, one to "write" and the other to "read".
DRAM chips use a grid pattern where a memory address simply specifies which column/row to read/write. This grid is built off tiny capacitors which slowly self-discharge by leakage currents, this is why DRAM requires refresh cycles. Also, the DRAM cells are read by connecting these femto-capacitors to internal bus lines. Those bus lines have capacitance of roughly the same scale as the cells' so DRAMs are "destructive read" devices. These buses terminate into line amplifiers, during a read operation, the amplifiers drive a row register and once the read cycle is done, the DRAM chip usually initiates a write cycle to rewrite the original data into the partially discharged cells. This internal read/write operation is the same as a refresh and before DRAM chips started featuring self-refresh, refresh was carried out by doing a dummy read operation for each DRAM row address.
If people out there are anything like me, many download stuff because they've seen it mentionned somewhere and never look back afterwards... then, a number of months/years later, they see these old files and wonder "what was this thing already?"
I'm using FF most of the time now since IE becomes much too annoying when scripts, controls and other stuff like that are on "prompt". Now that I got used to tabbed browsing and extensions such as flashblock, I am in no hurry to use IE. Other than a few minor layout bugs, FF works well enough for me.
Well, the unnecessary 'test eax,eax' is still there and it still uses LEA instead of plugging the target address calculation directly in XADD. It did chuck the MOVs and push/pops though, bringing it a whole six instructions closer to optimum.
Thanks for the tip, it will be useful if I start coding for AMD64 for which VC does not support inline ASM.
Since RAM IOs are somewhat expensive, removing an unnecessary write/read pair and two push/pop pairs along with one superfluous and two obsolesced ones, it seems reasonable to expect better than halving execution time.
The potentially most expensive instruction would be the JG which should be taken 99% of the time anyway so mispredicts should be relatively rare. And on a mispredict the following 'delete this' (from FinalRelease) is way more expensive than JG's mispredict.
Reference counting is nice but using it extensively with smart pointers becomes costly when you have thousands of objects and thousands of temporary smart pointers going out of scope or get re-assigned every second. Saving ~20 instructions in the AddRef/Release pair probably gives me a few milion more spare CPU cycles per second in some of my projects.
Note: even if latencies make it so my optimized code takes roughly the same time to execute on its own, I have a P4/HT and my programs are semi-massively multi-threaded (10-20 threads) so reducing instruction count still means more execution capacity for my other threads.
Unless you actually got the linker to inline InterlockedXXX, calling it still implies push+call+ret+pop. Interlocked[Increment|Decrement] is only five instructions long and calling it costs just about as many.
I sort of wish M$ had an inline assembler that could accept extended syntax like GNU's... but this is unlikely to happen considering MS apparently has no plans to allow inline ASM for x86-64.
Slashdot Mirror
I would personally spin each flash and other widgets (such as animated GIFs) in their own threads to spare myself the trouble of having centralized coordination of their independant/unrelated refresh requirements.
As an FPGA/VLSI person/engineer, I like parallelism. As a coder, I am a multi-threading freak.
Most coders have a hard time getting used to inherent parallelism... when I taught digital design, the simultaneous nature of gate-level designs caused major mind blocks for many students at least up to half-way through the lab project.
http://www.oehha.ca.gov/water/phg/pdf/draft_tritiu m.pdf
"The energy of
the tritium-emitted beta particles (maximum, 0.018 MeV) is quite weak, compared to the
range of beta particle energies (maximum, 1.7 MeV), but is sufficient to produce ionizations and excitations of molecules in their path. The average range of these beta particles in water is less than 1 m. Because of the low energy and short range of the beta particles, tritium does not pose an external radiation hazard; the radiation is not sufficiently energetic to pass through skin."
Tritium is present in drinking water and the atmosphere just like Deuterium is. When your atomic Tritium battery is dead, simply have it refilled - the previous "charge" can probably be safely vented outdoors.
Smoke detectors have a tiny bit of radioactive materials in them too.
In the UK, there are tritium-powered glow-lights on retail shelves and online stores... Tritium barely qualifies as a hazardous substance as long as you do not intentionally inhale or drink it.
Here is another possibility:
Quad-threading.
This way, the spy/trojan threads would not be able to presume anything about what else is being executed along with them unless they happened to be the only other running processes.
Of course, quad-threading on a P4 would be futile given that it has only a three-ways instruction decoder and integer execution units. If Intel replaced the AGUs by one extra complex ALU and two additional simple ALUs, quad-threading would become practical... though the six-ways instruction decoder and register files might not.
Try upgrading a shared library that is currently in use by a dozen applications... the only way to make those programs reload the libraries is to restart them.
/etc/lib/zlib.so from that exact file name... but the only ways to guarantee that all loaded instances of it have been upgraded is to either manually terminate all programs that loaded previous copies or reboot. The manual termination route is generally too inconvenient for typical users.
Since Windows is slightly less flexible about file deletions/replacements than Linux/ext2/3, the DLLs are locked on the disk until the apps are closed, the simplest way to guarantee that all DLLs queued for update are unlocked is to reboot.
On Linux, files are locked for as long as they are opened and are truly deleded only after all file handles to them have been closed. If you want, you can load 1000 different copies of
Well, this still does not change the fact that EULAs are generally trivial to work around of and that a company would have to prove that people have read and agreed to them... which is rarely the case when someone installs software and others use it, as often the case on shared PCs and PCs maintained my someone other than the owner(s) and primary user(s).
One very simple example: I go to a local computer store and play with the stuff that is on display, write up a wrap-up of all the crappy stuff I tried, where are the EULAs here?
Commercial products, software or otherwise, are in the public domain and therefore cannot avoid criticism, however restrictive whatever EULA they may come with may try to be. It is unlikely that any reasonable judge would rule against verifiable observations against commercial products, however damaging the findings may be. Opposing speech about public facts is highly unlikely to succeed.
NDAs are about protecting trade secrets, not exactly comparable to criticism/review of commercialized (public) products.
Radiative cooling does not work particularly well until something like 250C, few (if any) semiconductors would ever survive using this cooling method... most power semiconductors are specified for 125-175C maximum junction termperature while most logic devices fall in the 65-75C range.
As for fan noise, most HSF have this flaw in common: they place the fan immediately on the heatsink. Every time a blade crosses a fin, this messes up the airflow, generating noise and pressure losses which reduce effectiveness/airflow. Another common issue with typical HSF is that because the fan is directly on top, the heatsink's center is an air flow dead-zone.
I have not seen them for myself but Intel's orb-like P4 HSF and their BTX reference design seem like good examples of proper designs, they both provide some clearance and avoid dead-zones.
Lead-lined fries, yummy!
And even if lead-free, lead is not the only yummy toxic thing involved in PCB and component manufacturing.
Last time I read a story about OLED I did not see a mention of blue problems... but losing as much as half the brightness over as little as a year can be somewhat of a problem for anything that is lit for a significant part of the year. IIRC, brightness degradation over the first three years was expected to be as bad as 80% of continuously lit.
This was eight or so months ago and I am betting the 80% figure must have migrated to the fifth year by now... and probably beyond the seventh year by the time the first retail OLED displays reach the shelves next year.
I hope these will feature decent resolutions at decent prices. After using my laptop continuously for a few months, going back to my desktop's 19" CRT's imperfect geometry and non-uniform misconvergence/focus is barely bearable... and by decent resolutions I mean at least WSXGA+ or UXGA - I would be using my CRT at 2048x1536 if I was able to achieve acceptable and reasonably uniform focus and convergence with it... and I would be using two of them if my second shelf could support a 27kg load. (Actually, the main shelf is rated at 25kg so I am already over the line.)
A pair (or possibly even a trio) of 19" WUXGA OLED displays would be nice, I could start coding double-ultra-wide long lines of code, I would not need so many line breaks anymore!
I am not going to contest the validity of NDAs... most NDAs are meant to protect trade secrets and priviledged information not available to the general public, generally related to unreleased products and internal projects.
Most NDAs have real-world justificative reasons behind them. Non-disclosure/comparison clauses in EULAs are highly questionable at best since their only net effect is hindering public review.
And yes, not being to be able to get a refund for software after finding out that one does not find the EULA acceptable is highly moronic if there is no practical way of checking it out until after unwrapping it... and sometimes, the printed EULA does not match the click-through EULA... and even the click-through EULA may be amended by online updates.
There are way too many ways for companies to screw customers over with these things. Me, I have roughly the same attitude with EULAs as I do with pop-ups: just click whatever it takes to make it go away and be on my merry way.
I guess I should write my own EULA to promote my projects...
"You may freely use this software on the condition that you only speak good of it, saying or demonstrating anything bad about it violates this EULA and may net you a silly but insanely expensive lawsuit."
This is how I perceive these unreasonable clauses. As far as I am concerned, these are void and unenforceable since we all know they will only make the related conversations move to less obvious/official channels.
BTW, if companies were allowed to limit their customer's free speech by sales (or other) agreements, we would not be seeing the *sucks.com company sites fight off corporate lawsuits so easily and frequently.
The line is very thin between the two.
As I said in my post, these licenses try to limit open discussion about publically available products. To me, this reads very much like an attempt to impede free speech for very questionable reasons.
If the USA truly is the "land of the free", it must be for a different reason... what kind of free country allows corporation to dictate how people can discuss about their *published* works? If a company does not want its products criticised, analyzed and compared, it should simply not release them to the general public!
What part of an NDA applies to PUBLICALLY AVAILABLE products? You and many others apparently missed this detai from my post.
... at least until the day judges decide to protect the general public and decide to void in whole EULAs containing any form of illegal clauses - zero nonsense tolerance.
If I publish something, it is free game to all criticism and no EULA should be able to prevent it... but some do try, with the "If any clauses should be found not to apply, this shall not affect applicability of all other clauses" umbrella so EULA writers can lay it on as thick as they feel like.
But the 5x86 is not a 486.
If you go in the 586/Pentium-class chips, 200MHz is no big deal, the non-MMX Pentium went to 200MHz and the MMX version was mass-produced up to 233MHz, where it was madly successful as a notebook chip.
I do not see why people should be authorized to conduct reviews and benchmarks of publically available products.
Surprisingly (controversially?) enough, some EULAs forbid public criticism - I wonder if such clauses would ever be found valid in court, I seriously hope not - judges should declare void in whole any EULA that includes any anticonstitutional demands.
Now that I think about it, I seem to remember that M$ used to include a non-comparison clause in many of its products' EULAs, this "licensed comparison" tells me it probably still does.
Consider branchy code... the only option for a single-threaded CPU is to do speculative execution and backtrack if it mispredicted, this is good for single-threaded performance, not so good for overall throughput. With SMT, instead of doing speculative execution, the CPU can simply reallocate resources to the other thread until some of the first thread's dependencies have been resolved.
To me, replacing speculative exection by known useful execution is always a good thing no matter how deep the pipeline may be. Since adding SMT costs something like one or two milion transistors, I hope AMD will jump on this wagon soon - much less expensive silicon-wise than extra cores and cache. On my P4, the second thread gives me a 20-50% throughput bonus, not bad for a 5% cost in die size - and this extra performance costs me only 6W more on top of the 60W difference from idle to full single-thread load. (Approximate line measurements from UPS - actual figures for the CPU are probably ~30% less.)
So, SMT is a silicon-efficient and power-efficient way to gain 20-50% extra performance for nearly free if you overlook the extra silicon and software engineering effort necessary to make it work properly.
Since AMD64 has quad instruction decoders and more execution units than the P4, AMD's SMT chips (late 2006) will probably wipe the floor with the P4's unless Intel pulls an ace - which they very well can and may.
Back then, Intel had managed to build a 10GHz 64bits register file and 8GHz full adder, I presume they were hoping to spread this goodness across all sub-circuits and the devil popped out on the way towards integration... each test sub-circuit is able to reach ~10GHz on its own but once you pack the register file with 500+ adders to form multipliers, address generators, etc. mixed with other general-purpose logic, being able to get the integrated design anywhere close to what was achieved with individual sub-circuits is a whole different story.
They most likely did it on good faith and overoptimistic hopes.
Back when the first Prescott rumors started popping up, Intel's hopes for it were as high as 5GHz for the end of 2004... the Intel side has been stuck in the 3Gs for almost three years now. The story is similar AMD-wise but around 2Gs instead.
And now that it is open season on multicore, clock speed will soon become a secondary matter.
For many enthrusiasts, Netburst seemed like a bad idea long before Prescott... many were massively underwhelmed right from the architecture's initial debut. When the P4 began at 1.6GHz, it lost pretty much every benchmark known to man to the 1-1.4GHz P3s. It was not until the 2.4GHz P4 that Netburst managed to beat the 1.4GHz P3 across the board. And today, we have the 2GHz Pentium-M giving the 3.6GHz Pentium-4 a run for its money. (Or maybe not, I have not checked the actual prices.)
The Pentium-M is much like a P3 on steroids, they both are among Intel's best and greatest.
Although the P4's single-threaded IPC very much sucks, Netburst did give us the first multi-threaded desktop CPUs - the only SMT desktop CPUs out there actually - and when things are written to exploit multi-threading to some decent extent, Netburst does not look so bad anymore.
One of AMD's IPC advantages comes from its quad instruction decoder vs the P4's triple... I wonder what sort of boost P4/HT would get from this hypothetical upgade - Intel's capabilities bits have a configuration for 16k uOP I-Cache for this case, maybe a chip featuring this will materialize in the near future... back to before the Prescott launch, there were rumors of it being a 16K chip but it was only wishful thinking.
65C is a regular processor's temperature?
Last time I checked, my two P3s, my P4-3G and A64-3000+ rarely exceeded 50C under constant 100% load and closed cases... and the P4 is in a rather crappy Antec Aria case: although the PSU has a 120mm fan, it runs at 1800ROM max and the PSU's casing has almost no internal venting - there are two models of that PSU and I got the venting-deficient one.
There are many reasons why I got a P4-3G... first because I am cheap, then because I wanted multi-threading and also because I did not want to set a foot too close to the >90W area.
Of course, I am not one of those who run their RAM at 3V and cores at 2V...
Basicaly, they don't realise it, but they are coming full circle, and the outcome is just going to be a another eDonkey network. Which means, why not just use the existing one.
Here goes one reason: 9500KB pieces
Another: MD5-class hashes
The eD2k network uses oversized basic blocks and weak reference block hashes. Wasting up to 9.28MB because someone sent a bad bit is somewhat wasteful. So far, I have yet to see a torrent with >1MB pieces. Since MD5 is EOL, it is very likely that undetectable corruption exploits will appear in the near future (ViralG?). Killing legacy eD2k would be a good thing - those oversized blocks need to go, hopefully to be replaced by a scalable recursive tree hash.
Then we will need write-only HDDs for our write-only swap space.
There once was such a thing as electroacoustic memory - a mercury cylinder with a piezo element at both ends, one to "write" and the other to "read".
DRAM chips use a grid pattern where a memory address simply specifies which column/row to read/write. This grid is built off tiny capacitors which slowly self-discharge by leakage currents, this is why DRAM requires refresh cycles. Also, the DRAM cells are read by connecting these femto-capacitors to internal bus lines. Those bus lines have capacitance of roughly the same scale as the cells' so DRAMs are "destructive read" devices. These buses terminate into line amplifiers, during a read operation, the amplifiers drive a row register and once the read cycle is done, the DRAM chip usually initiates a write cycle to rewrite the original data into the partially discharged cells. This internal read/write operation is the same as a refresh and before DRAM chips started featuring self-refresh, refresh was carried out by doing a dummy read operation for each DRAM row address.
If people out there are anything like me, many download stuff because they've seen it mentionned somewhere and never look back afterwards... then, a number of months/years later, they see these old files and wonder "what was this thing already?"
I'm using FF most of the time now since IE becomes much too annoying when scripts, controls and other stuff like that are on "prompt". Now that I got used to tabbed browsing and extensions such as flashblock, I am in no hurry to use IE. Other than a few minor layout bugs, FF works well enough for me.
Oooh! :)
Well, the unnecessary 'test eax,eax' is still there and it still uses LEA instead of plugging the target address calculation directly in XADD. It did chuck the MOVs and push/pops though, bringing it a whole six instructions closer to optimum.
Thanks for the tip, it will be useful if I start coding for AMD64 for which VC does not support inline ASM.
Since RAM IOs are somewhat expensive, removing an unnecessary write/read pair and two push/pop pairs along with one superfluous and two obsolesced ones, it seems reasonable to expect better than halving execution time.
The potentially most expensive instruction would be the JG which should be taken 99% of the time anyway so mispredicts should be relatively rare. And on a mispredict the following 'delete this' (from FinalRelease) is way more expensive than JG's mispredict.
Reference counting is nice but using it extensively with smart pointers becomes costly when you have thousands of objects and thousands of temporary smart pointers going out of scope or get re-assigned every second. Saving ~20 instructions in the AddRef/Release pair probably gives me a few milion more spare CPU cycles per second in some of my projects.
Note: even if latencies make it so my optimized code takes roughly the same time to execute on its own, I have a P4/HT and my programs are semi-massively multi-threaded (10-20 threads) so reducing instruction count still means more execution capacity for my other threads.
Unless you actually got the linker to inline InterlockedXXX, calling it still implies push+call+ret+pop. Interlocked[Increment|Decrement] is only five instructions long and calling it costs just about as many.
I sort of wish M$ had an inline assembler that could accept extended syntax like GNU's... but this is unlikely to happen considering MS apparently has no plans to allow inline ASM for x86-64.