You need to first look at Haitz's Law. If Haitz's Law holds for 3 more years, then the bulb should half in price.
If you use a certain light a LOT, then $40 may make sense today. Looking 3 years out; you would want to save at least saved $20(half the cost) over an incandescent. You would have to be paying $7.43/year to light your current 60W bulb for this replacement to make sense.
IF you need both heat and light, incandescent are still great. LED bulbs are still too expensive to jump on, and there are plenty of negative side-effects of CFLs that have put me off switching.
The mercury vapor in the bulb is an issue. The 3-5mg of mercury in the bulb isn't a problem if you recycle it or if you break the bulb and let it dissipate to safe levels, but it's still not good.
The mercury released while manufacturing CFLs
In the US(where I live) we manufacture incandescent bulbs, all CFLs are shipped from China. This means more diesel used to ship the bulbs.
The harmonic power factor is terrible. Most CFLs have a power factor of around 0.5. This won't raise your bills, but you are actually using twice the rated Watts.
A pack of 4 incandescent bulbs is $0.75 at Walmart and I pay $0.08462/kWh after all taxes with my monthly bill totaling ~$40. The savings are not significant.
Opportunity cost. LEDs are still improving by leaps and bounds. Haitz's Law says that LEDs improve by a factor of 10 every 10 years, and the law has held for a long time.
First of all, that's the OFFICIAL Palm Pre Dev Wiki, NOT the Homebrew scene. They have a few more restrictions on them as an official arm of Palm. It would help to actually RTFA you are linking to.
The homebrew scene exists by piggy backing on the official dev kit. Sprint could call up Palm at any time and stop homebrew if they decided it was hurting their network. The Pre homebrew scene relies on being able to easily access developers mode, without that it would grind to a halt (or rely on rooted/pwned phones like iPhone's hombrew scene).
While homebrew tethering programs are available for many platforms, most of those are NOT Open Source platforms and are easily locked out, much as Apple has locked out tethering on the iPhone.
I'd hardly call the Palm Pre and open-source platform. You can get some components of it under the GPL, but you can't build the whole thing yourself. That's like saying OSX and iPhoneOS are open-source because you can get the kernel source code.
Tethering isn't an "official" option for iPhone users either, as NONE of them are "officially" allowed by AT&T. So that point is stupid and moot.
I never said it was official, just that Apple had built tethering into the iPhone. ATT didn't enable it, but plenty of people figured out how to turn it on by themselves. The 3.1 update makes it so that you need a signed certificate from your provider to enable tethering(so now I guess it's official).
Palm/Sprint and Apple/ATT have the same position here; that tethering is not available. The main difference is that Apple charges $100 to develop and Palm gives it away.
There are homebrew tethering options for pretty much every unlocked phone. People were installing proxy servers on their iPhones before Apple added their tethering option.
The Sprint Simply Everything plan doesn't include tethering, if you get caught tethering you will be billed $40/month(or whatever Sprint is currently selling tethering for). Where did you get the $1000 figure from?
Oops, the first GCD and future example aren't really doing the same thing.
The first GCD example
creates 128 tasks
blocks until they all return on the main thread
adds the numbers on the main thread
The future example
creates 128 tasks
Blocks on the main thread for each task individually in the order they were queued and adds them.
The second GCD example
creates 128 tasks
each tasks adds it's value to the sum before it ends
blocks on the main thread until all tasks are done.
Since we are just adding the complex calculations together, the first GCD and future examples are probably pretty much tied on speed. GCD only has one block on the main thread, where the future example gets to add numbers as they come in. The future example would take a penalty for continually waking the main thread just to add a number.
The async accumulator is adding the values into the sum as they are computed rather than waiting for them to complete in order like they do in my first example and your future example. This means you don't have to have an array and only have to have one block on the main thread for the sum, rather than 128 blocks for each value in the array. You need an upvalue to do this, and it seems most future implementations don't have them because it makes the syntax hard to read.
High speed external disk access is the only thing that USB2 is really missing. I'm sure we'll move past USB2 in the next few years, but I'm not sure the future is USB3. Since you can combine USB and eSATA in the same port, you can get the utility of USB2, along with the high speed of SATA, at a fraction of what USB3 will cost in the near-term.
The 900mA power bump in USB3 is just about perfect though. This is just enough to run pretty much any 2.5" hard disk or laptop cdrom.
Creating and destroying thread pools has negligible overhead, so Windows isn't losing much
Having lots of threads running isn't a performance problem because any operating system will run out of memory before it can create enough threads to bog it down
My response:
Can you find a thread pooling article that doesn't include something like "there is a lot of overhead associated with creating and destroying a thread that has nothing to do with the work that the thread was created to perform in the first place"? http://msdn.microsoft.com/en-us/magazine/cc164139.aspx
Pools trying to tighten their number of threads on an unloaded system will take an even bigger hit; the difference between 5 and 20 concurrent threads can be several orders of magnitude.
The only benefit to a thread pool is that the threads are pre-allocated for what you're using them for.
In a per-process pool-thread setup, a lot of time is spent creating and destroying threads in each processes's pool. Having a global pool means you just keep the optimal number of threads around for the number of CPUs you have.
Windows doesn't do this because it's retarded. This entire concept is a simplification of a more advanced thread API. It sounds like Apple is advertising a lack of resolution in the ability to manipulate threads. There is likely no performance improvement gained from this behavior, or at least there wouldn't be in a system with an intelligent threading model like Windows... there simply isn't anything to optimize
Are you saying you can't bog down a Windows machine by creating way too many threads? Thread pools are great and can speed up a lot of tasks, but if every process created it's own thread pool your system would be unusable.
Modern application development on Windows is supposed to take place using.NET, which marshals and threads on a level quite beyond what OS X can offer.
however
.NET is not really targeted at major applications. Its a rapid development environment for windows customers, in the same way that large parts of Solaris aren't written in Java and large parts of Mac OS X aren't written in Cocoa.
Most Mac applications are written in Cocoa. The Finder was re-written in Cocoa for Snow Leopard from Carbon/C++ with some really nice speed boosts. Photoshop is still Carbon, but the next version is switching to Cocoa (they have no choice since Carbon64 was binned and they NEED the speed boost).
There are quite a lot of major programs written in Java because it is very cross-platform.(i.e. Eclipse and most of Oracle's tools). Nobody is delusional enough to think they would get a speed boost by switching to Java though...
I am almost positive that.NET's threading pool is at least.NET-wide.
.Net's thread pool sizes are managed by each process... so no.
Why couldn't you just say SMP at first? Is it because you were trying to drop in smarmy Mac FUD and just hope that no one knew anything about multi-threaded applications? Calling Windows 95 "single-threaded" and meaning that it's a single processor system seems a bit misleading.
Win95 wasn't multi-threaded in any meaningful way.
Win95/98 were normally run in preemptive multitasking mode, but since any program could turn off the preemption in Win95/98, and often did, it wasn't any more stable. Technically, some Win3.1 programs were multi-threaded, and there are several thread implementations for DOS, so you could say Microsoft has never shipped an OS that doesn't support multi-threading...
Windows Vista has an aggressive thread pooling API
.Net/Windows creates thread pools per process, which is exactly what all older thread pools do. GCD uses a system-wide thread pooling system which brings the cost of creating threads down to a few instructions.
If you've never heard anyone champion the performance potential of.NET, then you're clearly spending too much time around Apple people.
Like most Apple people, you're quick to the condescension but not very bright. Windows 3.1 was indeed quite single threaded, but Windows 95 presented a diverse range of multi-threaded models through COM and the Win32 API.
These threading models meant you launched the thread on the alternate CPU and your application was completely in control of the secondary CPU(s), the OS has nothing to do with threading. These threading models existed in Win3.1 via libraries and in MacOS 7.5.
SMP threading(where the OS assigns applications/threads to CPUs) is where OSs actually come into play, and that was only introduced in the NT kernels.
Modern application development on Windows is supposed to take place using.NET, which marshals and threads on a level quite beyond what OS X can offer.
I've never heard anyone champion.Net for performance. Anyone care to elaborate on how Microsoft has taken threading to "a level quite beyond what OS X can offer" with.Net?.Net objects inherently support marshaling(unless you use unsafe code), but I didn't know that they are doing anything special with threads.
Secondly, the major benefit here is intelligent system-wide thread management with thread-pools. You can do thread-pooling per application on Windows, but that is only beneficial on large applications and will likely harm smaller applications. System-wide thread-pooling minimizes any penalties while also allowing the OS to schedule the tasks on cores so that you don't blow up the system. http://en.wikipedia.org/wiki/Thread_pool_pattern
The main thing GCD and Blocks are adding is allowing the compiler/OS to be aware of closures. This is what allows GCD to schedule the work in a closure intelligently... hopefully
Apple's closure syntax is pretty nice and works in C, C++, ObjC, and ObjC++. I don't think any existing syntax would work in an ObjC++ environment.
What's wrong with square brackets? At least ObjC was designed to be a superset of C instead of a bastard language. I prefer ObjC over C++, but regularly mix them within projects. If C++0x ever becomes a standard, then it will be interesting to see how Apple deals with it in Objective-C++.
Should it still be named C++0x? The final draft is slated for 2010 and it isn't going to be published until 2011.
Who identifies the work units which can run in parallel? A compiler or the application programmer? Who identifies the decomposition of the application data model into the work units and their state sharing and synchronization? A compiler or the application programmer? Who identifies the strategy for gathering work unit results back into the sequentially consistent form required after they all complete? A compiler or the application programmer?
The new thing here seems to be the system-wide scheduler for these work blocks. Rather than just having the OS manage threads, this allows the OS to schedule short-lived tasks on whatever resources it has. I don't know if there has ever been system-wide management of light-wieght threads before... or if it is a good idea.
I'm going to play with this later today. Even if the current version's performance isn't awesome, it lays the foundation for some really nice boosts by allowing you to express what you want to the compiler better.
USB3/xHCI is adding the capability for USB controllers to do DMA transfers, which will help offload the CPU on bulk-transfers.
I'm guessing USB3 bulk-transfers are still scheduled after every other request is satisfied. USB is designed to be a very low-latency bus for keyboards/mice and bulk-transfers will suffer if they are done when another device is chatting away on the same bus. It will be interesting to see what the real-world performance of USB3 bulk-transfers will be.
I think the disparity with firewire drives and USB drives mainly came out to the quality of the bridge chips used. Each generation of bridge chips keeps getting better.
I'd guess that 99% of the high-bandwidth use of USB is disk-drives. Going through a bridge chip to convert USB to SATA is always going to be slower than just using SATA.
4G is slated to be able to achieve 1Gb/sec, but I doubt that will be common anytime soon.
After accounting for the 8b10b encoding and command overhead, SATA 3Gb has ~288Mbytes/sec of real-world data bandwidth possible. Intel's SATA SSDs sustain 280Mbytes/sec. SATA 6Gb is just a faster clocked SATA 3Gb. The USB3 410Mbytes/sec is purely theoretical and pulled from wikipedia.
The speeds that marketing uses are:
SATA 6Gb = 6Gb/s = 768MB/s (600MB/sec after 8b10b encoding)
USB3 = 4.8Gb/s = 614.4MB/s (491.5MB/sec after 8b10b encoding)
Both USB3 and SATA use 8b10b encoding, which means the max theoretical throughput can only be 80% of their transmission speed. USB3 likely has more overhead since it's made to be used with a wider range of devices.
USB3 is going to be an expensive upgrade. The only controller chip currently available are $15/chip http://en.wikipedia.org/wiki/Universal_Serial_Bus#Availability The thicker more expensive cables required to make USB3 work are also a problem. USB1.2->USB2.0 technically wanted you to have higher-quality cables, but you didn't really need to.
Slashdot Mirror
You need to first look at Haitz's Law. If Haitz's Law holds for 3 more years, then the bulb should half in price.
If you use a certain light a LOT, then $40 may make sense today. Looking 3 years out; you would want to save at least saved $20(half the cost) over an incandescent. You would have to be paying $7.43/year to light your current 60W bulb for this replacement to make sense.
($20/3years)*(1+(6.9W/60W))=$7.43/year
First of all, that's the OFFICIAL Palm Pre Dev Wiki, NOT the Homebrew scene. They have a few more restrictions on them as an official arm of Palm. It would help to actually RTFA you are linking to.
The homebrew scene exists by piggy backing on the official dev kit. Sprint could call up Palm at any time and stop homebrew if they decided it was hurting their network. The Pre homebrew scene relies on being able to easily access developers mode, without that it would grind to a halt (or rely on rooted/pwned phones like iPhone's hombrew scene).
While homebrew tethering programs are available for many platforms, most of those are NOT Open Source platforms and are easily locked out, much as Apple has locked out tethering on the iPhone.
I'd hardly call the Palm Pre and open-source platform. You can get some components of it under the GPL, but you can't build the whole thing yourself. That's like saying OSX and iPhoneOS are open-source because you can get the kernel source code.
Tethering isn't an "official" option for iPhone users either, as NONE of them are "officially" allowed by AT&T. So that point is stupid and moot.
I never said it was official, just that Apple had built tethering into the iPhone. ATT didn't enable it, but plenty of people figured out how to turn it on by themselves. The 3.1 update makes it so that you need a signed certificate from your provider to enable tethering(so now I guess it's official).
Palm/Sprint and Apple/ATT have the same position here; that tethering is not available. The main difference is that Apple charges $100 to develop and Palm gives it away.
This isn't about homebrew tethering(that's always been on the iPhone and still works). This is about activating the built-in tethering via a hack.
in the US, a Sprint Simply Everything plan (includes Unlimited data use) is around $1000.00 cheaper a year to have.
is FUD.
That article is over a year old and talks about saving $1000 over 2 years.
It really looks like Palm doesn't want homebrew tethering http://www.engadget.com/2009/06/15/palm-webos-system-upgrades-mandatory-hacking-scene-forbidden-fr/
There are homebrew tethering options for pretty much every unlocked phone. People were installing proxy servers on their iPhones before Apple added their tethering option.
The Sprint Simply Everything plan doesn't include tethering, if you get caught tethering you will be billed $40/month(or whatever Sprint is currently selling tethering for). Where did you get the $1000 figure from?
Since we are just adding the complex calculations together, the first GCD and future examples are probably pretty much tied on speed. GCD only has one block on the main thread, where the future example gets to add numbers as they come in. The future example would take a penalty for continually waking the main thread just to add a number.
The async accumulator is adding the values into the sum as they are computed rather than waiting for them to complete in order like they do in my first example and your future example. This means you don't have to have an array and only have to have one block on the main thread for the sum, rather than 128 blocks for each value in the array. You need an upvalue to do this, and it seems most future implementations don't have them because it makes the syntax hard to read.
High speed external disk access is the only thing that USB2 is really missing. I'm sure we'll move past USB2 in the next few years, but I'm not sure the future is USB3. Since you can combine USB and eSATA in the same port, you can get the utility of USB2, along with the high speed of SATA, at a fraction of what USB3 will cost in the near-term.
The 900mA power bump in USB3 is just about perfect though. This is just enough to run pretty much any 2.5" hard disk or laptop cdrom.
I don't see how a dedicated thread pool would drastically reduce this overhead for a common usage scenario.
Fine, don't see it.
My response:
You are simply wrong
The only benefit to a thread pool is that the threads are pre-allocated for what you're using them for.
In a per-process pool-thread setup, a lot of time is spent creating and destroying threads in each processes's pool. Having a global pool means you just keep the optimal number of threads around for the number of CPUs you have.
Windows doesn't do this because it's retarded. This entire concept is a simplification of a more advanced thread API. It sounds like Apple is advertising a lack of resolution in the ability to manipulate threads. There is likely no performance improvement gained from this behavior, or at least there wouldn't be in a system with an intelligent threading model like Windows... there simply isn't anything to optimize
Are you saying you can't bog down a Windows machine by creating way too many threads? Thread pools are great and can speed up a lot of tasks, but if every process created it's own thread pool your system would be unusable.
Modern application development on Windows is supposed to take place using .NET, which marshals and threads on a level quite beyond what OS X can offer.
however
.NET is not really targeted at major applications. Its a rapid development environment for windows customers, in the same way that large parts of Solaris aren't written in Java and large parts of Mac OS X aren't written in Cocoa.
Most Mac applications are written in Cocoa. The Finder was re-written in Cocoa for Snow Leopard from Carbon/C++ with some really nice speed boosts. Photoshop is still Carbon, but the next version is switching to Cocoa (they have no choice since Carbon64 was binned and they NEED the speed boost).
There are quite a lot of major programs written in Java because it is very cross-platform.(i.e. Eclipse and most of Oracle's tools). Nobody is delusional enough to think they would get a speed boost by switching to Java though...
I am almost positive that .NET's threading pool is at least .NET-wide.
.Net's thread pool sizes are managed by each process... so no.
Why couldn't you just say SMP at first? Is it because you were trying to drop in smarmy Mac FUD and just hope that no one knew anything about multi-threaded applications? Calling Windows 95 "single-threaded" and meaning that it's a single processor system seems a bit misleading.
Win95 wasn't multi-threaded in any meaningful way.
Win95/98 were normally run in preemptive multitasking mode, but since any program could turn off the preemption in Win95/98, and often did, it wasn't any more stable. Technically, some Win3.1 programs were multi-threaded, and there are several thread implementations for DOS, so you could say Microsoft has never shipped an OS that doesn't support multi-threading...
Windows Vista has an aggressive thread pooling API
.Net/Windows creates thread pools per process, which is exactly what all older thread pools do. GCD uses a system-wide thread pooling system which brings the cost of creating threads down to a few instructions.
If you've never heard anyone champion the performance potential of .NET, then you're clearly spending too much time around Apple people.
CLR performance seems to be comparable to Java's VM. Are any major programs written in .Net? http://dotneverland.blogspot.com/2008/07/yet-another-benchmark-of-clr-vs-jvm.html
Like most Apple people, you're quick to the condescension but not very bright. Windows 3.1 was indeed quite single threaded, but Windows 95 presented a diverse range of multi-threaded models through COM and the Win32 API.
These threading models meant you launched the thread on the alternate CPU and your application was completely in control of the secondary CPU(s), the OS has nothing to do with threading. These threading models existed in Win3.1 via libraries and in MacOS 7.5.
SMP threading(where the OS assigns applications/threads to CPUs) is where OSs actually come into play, and that was only introduced in the NT kernels.
Modern application development on Windows is supposed to take place using .NET, which marshals and threads on a level quite beyond what OS X can offer.
I've never heard anyone champion .Net for performance. Anyone care to elaborate on how Microsoft has taken threading to "a level quite beyond what OS X can offer" with .Net? .Net objects inherently support marshaling(unless you use unsafe code), but I didn't know that they are doing anything special with threads.
Windows 7 finally has a half intelligent thread scheduler, but it's nothing like this. http://www.tomshardware.com/reviews/intel-core-i5,2410-8.html
The main thing GCD and Blocks are adding is allowing the compiler/OS to be aware of closures. This is what allows GCD to schedule the work in a closure intelligently ... hopefully
Apple's closure syntax is pretty nice and works in C, C++, ObjC, and ObjC++. I don't think any existing syntax would work in an ObjC++ environment.
What's wrong with square brackets? At least ObjC was designed to be a superset of C instead of a bastard language. I prefer ObjC over C++, but regularly mix them within projects. If C++0x ever becomes a standard, then it will be interesting to see how Apple deals with it in Objective-C++.
Should it still be named C++0x? The final draft is slated for 2010 and it isn't going to be published until 2011.
Who identifies the work units which can run in parallel? A compiler or the application programmer? Who identifies the decomposition of the application data model into the work units and their state sharing and synchronization? A compiler or the application programmer? Who identifies the strategy for gathering work unit results back into the sequentially consistent form required after they all complete? A compiler or the application programmer?
It seems the programmer identifies the work units(called "object blocks") and has explicit control over synchronization, but gives up control over scheduling those tasks. A decent doc at http://developer.apple.com/mac/articles/cocoa/introblocksgcd.html
The new thing here seems to be the system-wide scheduler for these work blocks. Rather than just having the OS manage threads, this allows the OS to schedule short-lived tasks on whatever resources it has. I don't know if there has ever been system-wide management of light-wieght threads before... or if it is a good idea.
And even use an async accumulator across them
http://developer.apple.com/mac/articles/cocoa/introblocksgcd.html
I'm going to play with this later today. Even if the current version's performance isn't awesome, it lays the foundation for some really nice boosts by allowing you to express what you want to the compiler better.
USB3/xHCI is adding the capability for USB controllers to do DMA transfers, which will help offload the CPU on bulk-transfers.
I'm guessing USB3 bulk-transfers are still scheduled after every other request is satisfied. USB is designed to be a very low-latency bus for keyboards/mice and bulk-transfers will suffer if they are done when another device is chatting away on the same bus. It will be interesting to see what the real-world performance of USB3 bulk-transfers will be.
I think the disparity with firewire drives and USB drives mainly came out to the quality of the bridge chips used. Each generation of bridge chips keeps getting better.
I'd guess that 99% of the high-bandwidth use of USB is disk-drives. Going through a bridge chip to convert USB to SATA is always going to be slower than just using SATA.
4G is slated to be able to achieve 1Gb/sec, but I doubt that will be common anytime soon.
The speeds that marketing uses are:
Both USB3 and SATA use 8b10b encoding, which means the max theoretical throughput can only be 80% of their transmission speed. USB3 likely has more overhead since it's made to be used with a wider range of devices.
eSATA seems like a much better solution.
I hope Apple starts putting eSATA/USB combined ports on their laptops soon.