But Apple's emphasis on the future processors leads me to believe that Intel has something *big* up their sleeve. Probably something to compete with the Cell processor, but on a much broader scale (i.e. - not focused so much on gaming performance).
Yes, and the Itanium is proof that we can trust Intel's "BIG" ideas.. In fact, it has only ever been when Intel has thought "small" that they've succeeded. By thinking small, they've reduced the opportunity cost for vendors and end-users, no risk, lots of head-room, no re-marketing, etc. A Pentium 4 D (or the 0x986 or 0x1086 if they'd kept to original naming) is proof of incremental change which permiates Intel. AMD, in comparison hasn't had much choice; they've had to make micro-changes.. 3d NOW and x86-64 are a new trend for AMD, violating outward compatibility.. They lost on 3DNow, but won on x86-64. Previously, AMD's purchase of NexGen's K5 architecture was a big step (RISC based internal processing), but obviously held 100% functional compatibility so the zero-risk paradigm was maintained.
To mention the "cell" is likely to ignore the above history of success. The cell ISN'T a product upgrade path like P3 -> P4 -> P4x2. It's a software architectural change. And this is akin to the P4 -> Itanium shift, which failed miserably. The Itanium looked bueatiful on paper, but apparently was an embarrasement in what they were able to deliver, and never mind the almost complete lack of x86 viability (thus removing an original design goal of reduced end-user risk). When the Itanium group said they were looking to have heterogenous motherboards which included both Itanium and P4's, I knew the writing was on the wall.
To migrate to "cell" means you're re-evalutaing the ENTIRE platform, and when doing so, you have to look at all options on the table. Microsoft has taken forever to support x86-64 officially.. Driver makers have taken even longer. To migrate to cell is a non-trivial task, and would be easier to simply start a new architecture (like a video game console.. gee, notice a pattern here?)
Next, lets look at the choice of Intel v.s. AMD.. Intel has a history of reliable delivery.. Apple was hit several times by CPU delivery problems by moterola/IBM. I'm sure Apple is looking to have a highly custom motherboard, so it will be non-trivial to swap AMD v.s. Intel. Currently we rely on vendors like VIA to bridge the gap, but Apple won't see the value in supporting two platforms.. Thus to bet the next 5 years of development, they're going to want quality + reliability + stability in architectural design. AMD MIGHT be able to produce sufficient CPU's, but can apple rely on it into the next generation CPU? Intel has never failed on reliability (even the Pentium division bug was quickly resolved, and this was back in the day of crashing cyrix/AMD K5 CPUs).
Why? Given that the exact action is hidden, I don't see why a byte read couldn't be microcoded as a word read followed by a byte extraction, if that is really faster.
Well, two things here.. First lets compare the same instruction on RISC and x86. At best, the x86 instruction becomes 1, 2 or 3 micro-opt instructions to perform a byte-load, hitting the lowest level cache and not requiring a virtual address decode stage (which on x86-32 requires an ADD instruction). The Alpha performs virtual address translation on every cache load (because it only requires a logical and), so it takes the same amount of work whether it comes from L1, 2 or main mem.. Only difference is latency. Now older Alphas did NOT have OOE (purposefully since the Alpha design team didn't like the extra load on processing), so you could argue that they won't handle latency as well.
But now, lets consider non word-aligned operations (say 16bit, or even 32bit memory which falls across a natural word bountry, say address 0x0003). You can get this with compacted C-datastructures that are dynamically allocated (if the compiler doesn't pad empty-space to keep alignment happy). In the alpha this is a highly discouraged practice, and most compilers will sacrifice memory-space for word alignment. But in the event that a word MUST fall out of alignment, then the align-instruction must be manually called by the compiler. In the x86, there is no such explicit alignment, so the CPU must at least CHECK for such an alignment issue on every instruction. That test is very likely to be an extra micro-opt.
Now lets consider normal operation of the x86. It is not to load a byte into memory, but to perform a CISC "op [addr x2 + offset] [addr x2 + offset] [addr x2 + offset]". So, what you have are 3 address-shifted memory accesses for say the same byte-sized operation. So now to what-ever extent the x86 is slower at non word-aligned operations, it is amplified by the fact that it has to perform the operation a greater number of times PER instruction (on average). Yes there are behind the scenes tricks to reduce this effect, but that's extra otherwise wasted horse-power, since it represents an abstraction layer between the "virtual" instructions and the real capabilities of the CPU.
I wouldn't say size is the problem.. You could always hook an external monitor through a proprietary interface, and keyboard/mouse through bluetooth. Moreover, solid-state data-storeing is about to hit it's prime (with 16Gig IDE drives this fall). The problem is CPU horse-power.. The ARM CPU is simply too wimpy to handle instensive load.. At least, not without killing the battery in short order. The ARM is a bueatiful architecture for power desipation, and not much else.
I've seen some crazy ideas to compromise between horse-power and power dessipation.. For example, lowering the voltage until you get a 1% error rate in your computation, then provide extra hardware/software to detect/correct these errors in a manner transparent to the application. Or take advantage of multi-processing techniques to identify applications which can be periodically put to sleep to reduce average power consumption. Or cache banks which go into sleep modes when not in use, but require longer access time when first hit.
Transmetta had some great ideas too; but notice this involved trying to migrate a prolific architecture into an optimized architecture... These days, if you've got a hand-held, you can afford recompiling all your apps to the optimized platform. Of course, proliferating Java on these hand-helds isn't exactly helping in the performance market.
I still think in 10 years the CPU will be a wrist-watch, and IO will be some external media.. The consolidation in the cell phone market took longer than I expected.. Now we have GPS, MP3, MS office, cell, SD-memory, external-keyboard-capability all in one device. But as said, horsepower is lacking... I'm ignoring, of course the PSP, but consider that too close to a laptop to really count as a hand-held. (That's a dual-hand-held.:)
64bit isn't some magical spec that solves all your computing needs. Sun Microsystem's Ultra SPARC CPUs have been 64 bit since the 90's. Ditto for Alpha.
And they are vastly superior CPUs except for price/performance. Not because of the 64bitness mind-you. But when your architecture is designed around native large-words, your compiler can take advantage of all sorts of things. Most of which center around higher bandwidth and lower latency.. Take, for instance the Alpha's complete lack of byte-addressing. In order to look at a character in a string, you have to manually align/unalign the data (grab 3'rd byte from word in reg X, place in reg Y). It the compiler is optimized around this process, then dereferencing c-structures can be faster as you are effectively pre-fetched several items and now have an optimized way of breaking it up. In x86 land, you have byte-addressable instructions, but it's highly probable that these will be micro-opt'd into lesser efficient accesses. So 1, 8 or 16 bit operations should actually be faster on an Alpha than on an x86 or worse yet and AMD-64 (with even more indirectness due to 64bit extensions).
And this is to say nothing of the highly optimized 64bit integer arithmetic. You don't have layer upon layer of internal multiplexors to handle dozens of different word lenghts.
Of course the Alpha is mostly a memory; didn't have the volume to sustain itself.. And the Sparc is on it's way out. Being server oriented, they had too much "meat" to ever make their way to the $60 pricetag (even if ever built in bulk).
PowerPC's have/had a chance, but they've stalled for too long and looks like Apple's changing ships. IBM probably couldn't promise them a significant enough road-map for the next year.
While it's great that x86 is hitting 64bit, the bad is that there is simply too many watts of power being dessipated on legacy emulation.. Not to mention a compiler can't know for sure how to optimize instructions, since an optimize compilation won't work best for older CPUs and probably not for newer CPUs. A PPC, SPARC or Alpha design hasn't had tremendous change, so such compilers stood a much better chance of being optimal. Poor gcc.
Lets see, 100Watt for P4 v.s. what 50W for PPC? (someone correct me here).. Lets says 50 Million 100Watt units... We'll say 150Million 80Watt and 300Million 60Watt x86 machines.. We'll average that to 500 Million 80Watt x86 machines.. Compare that to say 40Watt average RISC machines.. If machines are on an average of 2 hours a day, then that's 40 Gigwatt-hours / day wasted because of historical proliferation of a legacy architecture.
At 7 cents / Kilowatt-hour, that's $2.8M / day wasted because of PCs (v.s. a decent RISC alternative).
It looks like the entire industry is converging on AMD / Intel.. Intel will benifit most, but it's Ironic that Intel is doing so off AMD's back (course they still have to write off a couple more billion on that whole Itanium side-track).
MMX was introduced by Intel to kill off those initiatives.
Except that the path to the GPU was still formed and is essentially winning the specialized device wars over Intel. So while you still do find occasional systems with primative graphics devices thereby using the CPU for transformation purposes, the original point of MMX has largely been lost (with the exception of a 515% boost in performance here or there in applications that bother using it's legacy (SSE3)). I don't know about the on-board audio chips.. I know that 3D audio was previously off-loaded from the CPU, but the on-board audio chips are considered just as good these days, and I don't know if they rely on the CPU to do most of their work. So Intel might be considered a winner in this department.
eh, no? 33 bits would be twice as much space as 32 bits. we're talking 2^32 times as many possible adresses!
No, he said "word" with quotes. Meaning the physical space it takes up. 64bit computers take up twice as much data cache. It implicit that the concents of the word have greater value, though it is not specified.
Instead of having a range between 0 and 0.8 volts = 0 and a range between 2 and 5 volts = 1, you make the chip recognize (for example) 0-0.8 = 0, 1.5-3 = 1, 3.6-5 = 2. Wow, a trinary computer.
Bringing it from the transistor level to the practical level, a bit harder....
As an EE: Consider this analogy. Fiber-optics verses copper. Which is faster? fiber you say. Ok why? Because the medium allows for higher bandwidth capabilities? Ok, sure.. But here's an interestin factoid, fiber is usually base-band, while copper often is voltage-varied. Consider the phone line which uses frequency to transmit info (more recently it has effectively evolved to voltage sampling as you reference), but fiber is still 0 or 1; presense or absense of light.
Next, consider parallel v.s. serial BUSes. It is intuitive that parallel buses provide greater bandwidth for a comparable medium, so why did we shift to serial? It wasn't just because it takes up less space / clogs less air (though that's a bonus).
While fiber is a common denominator in both examples, you might ask yourself, if it's possible to send full-spectrum signals in fiber and it's possible to put fiber in parallel like a BUS, why don't we do this with with BUSes and phone lines? Well, the obvoius answer is that the jump in speed was enough to satisfy current demands; there simply aren't 1GBps hard drives yet. But there is another, more practical answer.
Because it's cheaper to use base-band, serial technology.. Computer busses use to be serial on low-end computers in the 70's. It was cheaper to write software on both transmitting and recieving end to serialize/decerialize the material. Plus the computers were FASTER than the medium's bandwidth.
Likewise, modems were analog devices; frequencies were measurable by capacitors; you'd get voltage on one of several tuned sensors, representing bit-patterns. This was originally faster than performing a fast-fourier-transform on the signal and extracting signal-noise compensation, yadda-yadda (which modern home-modems do). The sender, obviously can just digitally generate a voltage-pattern representing error-corrective code-patterns, but due to the phone-line standard, they must ultimately represent sine-waves (unlike say ethernet or direct serial buses).
Today fiber is faster than the computational power, so encoding/decoding signals isn't practical. And the issue with parallel bus synchronization is likely as expensive in fiber sysems as in copper. Thus it is only when the bandwith is really hurting are we going to see parallel buses.. Fiber external RAID hard drives have parallel fiber BUT one in each direction (which is the cheapest way to "double" the bandwidth).
The main advantate of digital v.s. analog was error rejection. When you have a signal that if beyond a threshold is definatively 1 and else 0, then you can amplify it with little fear of INTRODUCING error. With analog amplification, the amplifier ALWAYS introduces some non-linear distortion or power-generation flutuations, etc. So even if you had a perfectly clean input signal (which is nearly impossible), you are garunteed to distort the output signal. Having several amplification hops means noise in inherently introduced into the signal. Then take into account external noise (that isn't compensated for by cabling techniques). Trans-continental phone services were a joke. Introduce bi-state logic. Here you NEVER let voltages get near the quasi-zone, you jack them up signficantly higher than the threshold transition voltage. Now so long as noise voltage doesn't exceed 50% of your voltage, you will never have an in-advertant transition from 0 to 1. Cabling noise-cancellation techniques do wonders to minimize the voltage of noise. So now you can repeat a signal an infinite number of times and not introduce new noise into the system. (Though there is always a statistical chance that it will be intoduced somewhere).
Why does amplification matter? Consider your CPU BUS.. your
First, each checkin should ideally be a legitimate build.. You shouldn't check in to the main branch things that are knowingly broken.
Whoa there cowboy. There will be many cases where this isn't always practical.
Notice I said "should". Obviously the alternative is to check in half-working code as your example implies.
IF, your test/staging environment is automatically pulling from the version-control back-end (via checkin-triggers or polling), then this is still a problem for you.. A human being has to determine when the checkin is valid. In the article's description, they were applying a "sticky" tag. Here, whatever process was applying that tag would be applying the checkin number.
If all checkins are assumed to be valid (backed by unit-tests), then the trigger could perform the auto-posting. This is often a good idea anyway to have some side validation deployment which on each checkin performs a full unit-test suite and flags the checkin as valid or not. In eXtreme Programming or Test-Driven-Design, I've seen the recommendation for the dual lava-lamps (red/green) being auto-triggered based on the most recent check-in.
Obviously some things are hard to unit tests (like web apps/ hardware-based applications), and some projects aren't willing to budget in unit testing. That's just a fact of life. But in these sub-optimal environments, there must be manual analysis.. ergo manual application of checkin numbers.
First, each checkin should ideally be a legitimate build.. You shouldn't check in to the main branch things that are knowingly broken.
I assume you have a staging environment which would pull from the latest main-branch build.. It's easy to see what checkin version staging is using..
Once you have staging in an acceptible state ready for deployment, simply take the associated checkin-number (this SHOULD be a manual process) and post that to production.
In other words, ditch the remapping of tags as you used in CVS. This is an error prone process which destroys history.
In our development environment, we have a wiki that we (manually) update whenever we post things, and each deployment (to test, stage, production instanceX) has an associated svn checkin number.
If there is some memorable tag that we need, we svn cp a tag.. And obviously long-term modifications get their own branches.
While I'm not as happy with SVN's lack of relocatable tags, I do really like the idea that when using svn + fsfs as a backend, you have read-only back-versions. You can see everything associated with the checkin-number. CVS, on the other hand only lets you see the current state of the rcs files.. Sure there's a lot of history in there, but there is no associated "undo".. Yout have to use the cvs tools, and then you have to keep your fingers crossed that you're doing it right.
Nor do I. I think you missed part of my point. I was countering this idea that if I want to hand out my music to anybod who wants to hear it, I can't because of the RIAA. This just isn't true. They don't own all music in the world.
I have no problem with what you wrote, nor do I think my response contradicted you, or your main point of ownership.. I was expanding on the two posts, and focusing on practical terms.. Yes you can own your own music, and yes there are open distribution channels. But the money streams (in it's current form) is channeled and controlled.
It use to be that local radio was a great outlet for local music. It was cheap for radio broadcasters, and was a great exposier for artists; who could win local gigs. But as of 12 years ago (when I last listened to music radio) it was mostly, if not all centralized music. You merely chose the radio station that focused on alternative older, or oldernative younger audiences, etc. Or you simply lived in between two major cities like I did, and had sister channels with slightly different content to which you could flip back and forth in your genre of choice.
My point is that consolidation of the market is likely to dry up tolerance for independent labels by consumers. Without exposure, people like myself don't even bother wasting time looking through up-starts that might or might not be good. When it was forced on me in between songs that I already liked, I could get into a local band. On rare occasion I'd accompany a friend to a bar where a local band played, and I really enjoyed it, so I know I have a taste for it.. But I have no desire to surf the net for random selections of music. I don't know how representative I am of the general public, but I do know that people are inherently lazy and value time above most things.
The big problem is that if we're talking about suing against the next cheapest legal option; apparently yahoo isn't providing unlimited downloads of songs for a flat rate.. I saw somewhere else in this post that you can only stream music from yahoo; meaning a max of 1 song / couple minutes. And sub-CD quality at that.
There is also another issue here. Lets assume that an illicit uploader has taken the time to convert from a DRM-ish media (such as a generic 1990's style CD who's DRM consists the primitive fact that it's material instead of digital) to a DRM-less media such as an MP3/ogg-vorbis file. Prior to the conversion, the media could not propagate freely (costs money or human-energy to move around). Plus the media is non-duplicatable for free. It was your input that produced a new form of media who's production was not free (opportunity cost of time of server spent ripping+encoding), but has set a new resale price to $0. You are in essense a re-distributor, though in most cases (minus marketing rebates) you never see redistributors sell for less than the cost of raw materials.
So you are selling a new product which is based off a different product for less than the base part.. If countries did this, it would be called dumping, and is penalizable for the difference in price..
The difference here over anti-dumping law (IANAL) is that anti-dumping law covers physical assets, so it's not 1-1 corresponding with the problem at hand. It may cover digital assets as well, but that doesn't help clearify the conceptual dillema. Material asset dumping is important to recognize because it represents coersive tactics which are semi-universally opposed (except maybe by economists, of which which I am lay).
Technically, the individual that acquires the license-violating DRM-less material and redistributes it again is only in violation of "possessoin of stolen goods" or "sale of stolen goods".. Now obviously it would be difficult to determine if the commodity is indeed stolen, if not for the general knowledge that there is no legitimate distribution of DRM-less media.. As far as I know you can't even broadcast music without paying royalties (I've heard about gas stations being sued for playing their personal radios loud enough for customers to hear). In other words, it would be a diffcult case to make that you were not aware of the fact that your possession of the Metalica song in a digital format that you didn't directly rip from CD for backup purposes wasn't illegal. If you knew for a fact that an indi-label was given free songs away on the internet, and you downloaded that song from a friend, then redistributed it, you would be ok. Mostly because nobody would sue you if they only ever caught you distributing that song. But also because you could demonstrate that you acquired a product from a vendor who set their price to $0. Redistributing music, likewise assumes you've purchased the music for something like $0 from a legitimate venue (even if it's a friend). But plausible knowledge that the material is hot is punishable. I could be off on my details here though.
So even if you can prove that you don't own any original CD's or have never paid for licensed music thus you could not possibly have been the perpetrator of the illegal extraction of DRM from the media, you are still in violation because of posession of identifiably illegally produced material. And possibly sale (again, even at $0).
It's not too different than home possession of $100 casino chips. Many states make it illegal to have them (to help in the fight against fradulent counter-fitting). I believe mere possession of counterfit money is also prosecutable.
So while I don't know for sure the particulars of the law that facilitates the RIAA in suing little kids, I suspect the "fines" are an aggregation of both possession and direct initial license-violation.
The reason they have to tie the lawsuit to uploading, is that it ISN'T illegal to copy a VHS tape or rip a CD. So you couldn't just
I think it's a little bit of both of you being right. I agree with you that you can take an independent path; the parent is technically incorrect since the RIAA or whatever doesn't have a monopoly.. But that's like saying MS didn't have a monopoly in the late 90's.. Yes there was DR DOS and Linux and SCO UNIX, and OS/2. But they were like 1% of the market.
Likewise, I'm sure the indi venue is an insignificant portion of the audience market but I have no numbers to back me up.
The music radio is mostly clear-channel. I'm sure Satalite radio is clear-channel controlled. MTV is certainly biased towards the establishment. The only large distribution you have left are sound-tracks of big-end movies. With the possible exception of indi-films that at least get a lot of spot-light, if not popularity.
The industry has calculated methods of maximizing profit; tuning various demographics to particular sounds and focusing on particular artists of the month to build sensationalism which causes people to flock to the fad-of-the-month and thus increase revenue. To facilitate this brainwashing, they need LOTS of airtime for their target projects, and this leaves no room for anything else.. With the consolidation of media outlets, the drive to "advertise" a particular label means even less airtime for variety.
So there IS an establishment that is trying to squash unsigned material, albeit indirectly through the reduction of avenues of distribution.
As a disclaimer, I have no association with the musical profession.
Brian Greens' book "The elegant Universe" talks about the history of string theory and if I recall correctly, there were many branches of string theory. One breakthrough in the 80's was M-Theory which tried to consolidate the ideas of 2, 3 and higher-dimensional string-derivative theories. Unless I have the order mixed up, it was then that super-symmetry was introduced. If I am correct, then super-symmetry was part of an exciting theory that was a superset of conflicting theories which provided a semblance of unification (the fabled grand unification theory).
The point is that, unless my memory of the order of progress is wrong, super-symmetry is relatively new to string-theory and definitely wasn't part of the original models. I do not know that disproving super-symmetry disproves all branches of string-theory. No branch yet has experimental prudence, so it's still possible that after back-tracking, one of the earlier branches was on the right track.
Not just wishful thinking, I'm demonstrating that the disproof of super-symmetry does not end string theory; just string theory as we (read me) know it.
What are you proposing? I seriously don't see what you're getting at...
How about this: cell-camera has crappy image quality. Even if in 5 years cameras have ultra-hi-res, they're still not going to be SLR, so the "highest end" is still going to be separated. Ideally, the PDA/cell will be USB input capable such that you can connect the high-end camera to the central-hub device (the cellphone/PDA). Of course the only reason you'd want to do that is if the phone has multiple gig worth of data and or the ability to upload/download effectively for free (a la black-berry internet, minus the expansion of memory)
Next is audio capability. The iPod has external stereo audio hookup, but most cell phones only have mono output along with the more proprietary input. (Though I think iPod had a proprietary connector as well). Having a single industry standard bi-directory audio port would allow interfacing to your car (as with current (new) high-end cars) or a premium stereo system. Ideally the audio out would allow multiple audio channels (to perform digital-dolby), but this would require an AC3 digital out. Of course, copy-right being what it is these days, that's highly unlikely to happen. So basically we've taken a step back in music quality by shifting fromm CD's to AAC/MP3. No blasting high-end music through central stereo; our music collections are to be listened to on portable device and MAYBE your PC (if the device lets you transfer it to the appropriate machine).
Next is screen-size. I like a large screen on my hand-held, but the larger the device the less portable it is. While people are getting comfortable with Treo-sized devices, this definitely doesn't suite all; especially the athletic type. The blackberry is rather light and compact, but it is very scratch prone. Thus having tiered sized devices with screens may be more suitable for some people.. Take a super-mini laptop like the sony VAIO or power-book as sort of an over-sized PDA, then take a mirco-sized and rugged phone for begin on the go.. The laptop sits in the car and the phone goes with you. Otherwise you might want a super-sized and heavy PDA but need to lug a power-adaptor with you everywhere (like I do).
Ideally in the future these new nano-tube based LCD displays allowing 1024x768 on 5" along with zooming capability should allow for some serious laptop substitutes. I believe we still need a higher horse-power CPU for the laptop replacement to be viable.
Satalite radio is another "component" that isn't likely to consolidate into your cell phone. Unless XM and Sirius allow a common reader device, then you're segregating the market between cell-pda-camera-music-radio that support XM or Sirius. Likely there are licensing fees associated with such a consolidation as well, so it will most likely not take off. Again having an connector (preferably USB) which connects your satalite radio to your portable-audio device would be ideal.
Yes, we're talking about carrying lots of things around, but the need for independent hardware is always there.. The single BIGGEST reason to componentize is to fully allow for future upgrades.. I can connect a turntable, scratch-table, cd-player, digital-cd-player, cd-jukebox, dvd-player, tv, vcr to my pre-amp device. They all comply with the RCA pre-amp standard. By encouraging a common inter-device connections (like USB and associated transfer protocols), you encourage the market to build on itself.. Sellers can more easily get new concepts out into the market, and consumers have more options, more competition and cheaper prices.
When you have all-in-one, then you either have super-cheap or super-expensive (like AIWA or bose). And with BOSE (e.g. high-end), you are stuck with older technology because to make quality parts, they needed a long development cycle.
Everything pre-2.5 was pretty bad for interactivity, but 2.6 is excellent.
Don't really share your user experience.. Being a college student at the time, I salivated over a dual system for years, and finally found the opportunity with the dual Pentium II-class celeron motherboards by Abit. That brief window in history when you could have a full dual processor system for under $250. It was dual 433's overclocked to 466. At the exact same time, I had an AMD K5-400 as my main machine. The dual ran on Red Hat 8 I believe originally, and is still running to this day as my main home-server, and I've only upgraded it to Red Hat 9.0 (main because if it ain't broke, I ain't fixen it). So as I look at uname, it's still only running kernel 2.4.20-31.9smp. I remember running this puppy side-by-side to the K5-400, and later my K6 Thunderbird 800MHZ. The Thunderbird should have blown away with dual 466, but it didn't. I had better throughput of mp3 encoding on the duelies (which I was doing a lot of at the time, farming out all my machines at home and at work 24/hours a day some weeks). One of the features I specificly played with was encoding single-threadedly with grip+lame v.s. dual threadedly. When dual threaded. Obviously single-threadedly the system was almost perfectly responsive (since lame isn't HD or even memory bound), but even when dual-threaded, the system was more responsive than my faster single-CPU K6. I quickly fell in love with the dual processor concept, and used it as my main home-station for just about anything that wasn't video games.. When my K5 literally exploded one day due to moisture damage, I was rather forced to migrate over to the new machine; but it was a welcome change from a mostly windows unresponsive environment.
I am convinced that even Linux 2.4 was more smooth operating with multiple CPUs than windows. Perhaps it is because X is single threaded, but graphical thinking occurs in the application-space and is thus inherently multi-processed. Thus you get the best mixture of non-race-conditions streamlined code with concurrent processing capability. This is purely speculative. Whatever the deal, it was great.
Unfortuntaely, I don't remember if the standard Linux benchmark of doing a parallel make of the kernel was faster on the dual 466 v.s. the single 800. I guess one of these day's I'll have to fire that 800 back up again to check; the dual's still chugging along fine as my server.
Unfortunately I haven't had the luxury of having ANY affordable dualies in the past 5 years, so I've just gone for greater single-threaded horse-power for work-stations.
As for the point of this thread. I seem to recall that the 2.6 kernel had more overhead than the 2.4 kernel. This along with my anxiety for changing a back-end special-purpose servers' OS kept me from wanting to up the now ancient machine. Most likely this overhead is compensated for by the better MT-support, and is especially unnoticeable at the 2GHZ range. But I find it hard to believe a perceptible difference in UI responsiveness could be found between the 2.4 and 2.6 kernels. Perhaps measureably in application benchmarks, but surely not on the GUI.
Sadly, as I've said, I can not provide empirical data as I don't have $1,500 to spend on a simple file-server.
Of course, a cheaper solution would be a better scheduler with a real "idle only and if that means that the damn thing will starve then so be it !" priority.
Not to be sacraligeous, but didn't windows (and probably the MAC) have event-based threads which were only called when there was NOTHING else the OS had to do. I don't believe they were threads, so much as registered GUI-event callbacks. Such handlers were used for background disk-defragmentation, screen savers, and a few other things I've forgotten. I don't remember ever seeing anything like this in a UNIX/Linux API, which seemed like a waste.
That is exactly what I meant. Synchronization is a tricky issue but I'd consider it far more rare than the problem of cycle hogging single-threaded apps.
Bugs might be more rare, but "hacks" to allow multi-threading by having universal locks are a serious issue. I know that perl 5.5 has a few global locks which REALLY impeeded multi-threading. This is of course because perl wasn't originally designed for MT and people were experimenting with different possible migration paths. Java was pretty good at allowing for MT, but early garbage collection had the same general universal-lock effect. I've been impressed with various MT memory management schemes I've seen in glibc and by SUN (magazine cells), but that's somewhat of a digression.
The thing is that it's easy to write a piece of code to be MT-safe; just never use globals, and when you do;synchronize the hell out of it. THe most common aspect of java these days (EJB's or servlets) are all inherently MT, and the design paradigms generally make it easy to work with; you hardly ever have to think about MT (unless you're being evil and creating static variables (e.g. globals)).
But the hard thing is writing some optimized for speed, because you're VERY prone to take short-cuts.. You have to have the entire variable-space mapped out in your head so you know all the special conditions, side-effects, and use-cases. You're likely to cut any corners you don't expressly see a need to keep "elegant". Thankfully such optimized code tends to be restricted to a very small piece of functionality, lest the whole project be doomed to managerial anarchy. But such pieces of code are serious issues for MT, especially since their goal is high performance. Pray you need never be tasked to do this. If you can divide and conquer by threads, then you can likely divide and conquer by independent pieces of hardware and thus literally throw money at the problem whilst using a more elegant programming paradigm.
Bull. The vast majority of really bad locking issues with multithreading never surface with singe CPU systems.
I disagree.. I've often managed to discover race conditions on a single-CPU machine.. Thanks to pre-emptive multi-tasking. The fact that there's a lower probability of context switching out doesn't preclude situations when un-safe race-condition code-blocks are called extremely often (such as memory management, etc). Push the machine to memory-swap such that every hundreth instruction will incur a context-switch and your problem exacerbates.
win 3.0 and MacOS 8 (and maybe even 9; don't remember) used cooperative multi-tasking so they didn't have this problem as badly.
For servers, I've found that having onboard video isn't too bad; especially if you can reduce it's system-memory to 2, 4 or 8 meg.. On a 1+ gigabyte system, the last 8 meg shouldn't be much trouble. If we're talking a budget server ($300 or so), then the money savings can often be worth it.
Lowering the power consumption per core is a first step to upping the number of cores
I find this odd, considering one of the main advantages of having dual-core computers is the lower power consumption for a given performance level.:)
Course who says, "yes, that's enough horsepower for me all-else-considered".. I would think most would say, what's the max horsepower I can get for my money (including other requirements). But still, it's feasible that laptops are where power-consuption is most concerned, so dual-proc 1.5GHZ machines might be desirable to keep power low and Horse-power high.
If you're buying a 720p (or close to 720p as many are slightly off) set that is less than ~3,000 USD the answer is easy: All of them.
The problem though is that it's BS that the cost of the processing represents affects the price of a multi-thousand dollar system. I can't imagine that a simple $100 PC video card couldn't be stripped of it's bare chips and used as the filter between what-ever proprietary system they use and the input signal processor. It can't possibly cost more than $500 to push an off-the-shelf component into their system. Since base HD-TV's are just above $1,000 these days.. Then such a low-end system of superior down-sampling shouldn't cost more than $1,500.
I understand that most of these monitors have end-to-end proprietary solutions, and thus are internally limited to processing power and not extensible as I've said above. But if you can make a high-cost low-volume chip, then somebody else can make another one that IS extensible for no greater cost.
The problem ISN'T that it costs them a lot to make, but that they would prefer to sell the high-cost (and thereby high profit-margin) sets. So if they're going to sell a cheap-o $1,000 set, then they want to artificially restrict it's capabilities. So they use a $50 CPU instead of a $150 CPU (made up numbers). Of course I'd rather pay $1,100 than $1,000 for a TV that uses a better CPU. But they'd rather me buy the $1,000 set now and when I can afford a $5,000 set, buy it again.
Note these are unsubstantiated allegations; take them at face value.
Since XML is an abstraction on top of plain text files, there's absolutely no way it could be simpler than a plain text file to begin with!
Not true. By text files, we tend to mean line-oriented files. Often to be useful, it must also be field-delimited files.. colon-delimited in password files, or worse with cron-files a mixture of space-delimiting and position-dependence. (after first sevearl spaces, remaining spaces are no longer delimiters).
With XML you are no longer rectangular in your data-structure; no longer rows and columns (and potentially sub-colums), but instead you can more naturally represent the data however complexly it needs, and not have to worry about escaping arbitrarily complex characters, because all XML files use the same escaping.
You're looking at this from the perspective of someone who understands and remembers the differences in a dozen config file formats. Most people don't.
RTFM!!
Seriously, if you're going to be editing a file.. XML doesn't make it easier to understand the contents. Having an XSD or DTD doesn't really help you to know what is supposed to go into the material (and XSD is harder to read than a man page, thank you very much).
You're missing one very important point. x86-64 has hardly anything to do with being 64 bits, and almost everything to do with adding a new execution mode to the CPU (a la SSE). This new execution mode uses a totally different virtual memory manager (which is NOT backwardly compatible with DOS-mode on the x86-32). The dropping of backward compatibility means we can use logical AND instead of logical addition to construct physical memory addresses.
AMD has doubled the number of registers. This is a HUGE factor. Unreal was able to achieve 15% improved performance on x86-64 mode on the same chip compared to x86-32 mode, and they specifically mention the register augmentation as a main factor.
If you aren't privy, registers are critical resources which determine how the assembly code is structured.. If you have enough registers, you can perform register-to-register operations and avoid memory/cache/register-renaming overhead. Every RISC chip today has at least 32 general purpose addressible registers, while the x86 has a scant 8. Moreoever, many of the 8 registers have specialized functions (loop iteration, accumulation, array indexing, etc). While CPU's have gotten VERY good over the years making use of more than 8 registers (through out-of-order, register-renaming, etc), this can add delay into the execution pipeline which hurts critical-paths of execution with non-sequential execution.
I hate when marketers use extremely simple to remember things like 32bit is better than 16 bit, 64bit is better than 32 bit. This isn't a 64bit machine, this is a step closer to a RISC machine, while maintaining 100% of the 32-bit user-mode instructions. Incidently, as some posts have marginally mentioned, 64bit computing itself does nothing to enhance 32bit data-structures. And needlessly moving to 64bit datastructures only serves to waste cache space (thereby reducing performance). There are definitely things that can make use of 64bit data-structures. Encryption, integer manipulation of AMD-NOW / SSE data-packets, large-file manipulation, millisecond-time stamp operation (as used in java), etc. But if you're going to loop through the records in a file, you most likely still only want a 32bit integer. Iterating over a 64bit integer might very well incur an additional propagation delay / extra clock-tick or two PER increment and comparison. It takes longer to operate on more bits since with arithmetic, multiplication and division, you have to carry each digit.. Yes there are neat tricks to minimize the propagation delay, but it's still got to hurt for mult/div. And with array indexing for non-power-of-two dimensions, we're talking full blown 64bit multiplication.
I love 64bit, but that's because I'm a programmer, and I find more and more places that it would be REALLY nice to have 64bit integers and know they are native. I also REALLY like using up lots and lots and lots of memory.. I can't wait to get motherboards which let me put 4 gig of memory in them using lots of cheap DIMMS (instead of very expensive high-capacity chips). I currently use 1Gig of memory on ALL my machines, and STILL find occasions where I could use more. I litterally feel the pain of using only 768M. As servers start using 64Gig, the cost of higher-density chips will drop and 2 Gig sticks will finally be practically priced.
These are the benifits of 64bit computing, but all we here is 64bit.. WOW that must be fast.. twice as fast even.... sigh
Slashdot Mirror
But Apple's emphasis on the future processors leads me to believe that Intel has something *big* up their sleeve. Probably something to compete with the Cell processor, but on a much broader scale (i.e. - not focused so much on gaming performance).
Yes, and the Itanium is proof that we can trust Intel's "BIG" ideas.. In fact, it has only ever been when Intel has thought "small" that they've succeeded. By thinking small, they've reduced the opportunity cost for vendors and end-users, no risk, lots of head-room, no re-marketing, etc. A Pentium 4 D (or the 0x986 or 0x1086 if they'd kept to original naming) is proof of incremental change which permiates Intel. AMD, in comparison hasn't had much choice; they've had to make micro-changes.. 3d NOW and x86-64 are a new trend for AMD, violating outward compatibility.. They lost on 3DNow, but won on x86-64. Previously, AMD's purchase of NexGen's K5 architecture was a big step (RISC based internal processing), but obviously held 100% functional compatibility so the zero-risk paradigm was maintained.
To mention the "cell" is likely to ignore the above history of success. The cell ISN'T a product upgrade path like P3 -> P4 -> P4x2. It's a software architectural change. And this is akin to the P4 -> Itanium shift, which failed miserably. The Itanium looked bueatiful on paper, but apparently was an embarrasement in what they were able to deliver, and never mind the almost complete lack of x86 viability (thus removing an original design goal of reduced end-user risk). When the Itanium group said they were looking to have heterogenous motherboards which included both Itanium and P4's, I knew the writing was on the wall.
To migrate to "cell" means you're re-evalutaing the ENTIRE platform, and when doing so, you have to look at all options on the table. Microsoft has taken forever to support x86-64 officially.. Driver makers have taken even longer. To migrate to cell is a non-trivial task, and would be easier to simply start a new architecture (like a video game console.. gee, notice a pattern here?)
Next, lets look at the choice of Intel v.s. AMD.. Intel has a history of reliable delivery.. Apple was hit several times by CPU delivery problems by moterola/IBM. I'm sure Apple is looking to have a highly custom motherboard, so it will be non-trivial to swap AMD v.s. Intel. Currently we rely on vendors like VIA to bridge the gap, but Apple won't see the value in supporting two platforms.. Thus to bet the next 5 years of development, they're going to want quality + reliability + stability in architectural design. AMD MIGHT be able to produce sufficient CPU's, but can apple rely on it into the next generation CPU? Intel has never failed on reliability (even the Pentium division bug was quickly resolved, and this was back in the day of crashing cyrix/AMD K5 CPUs).
Why? Given that the exact action is hidden, I don't see why a byte read couldn't be microcoded as a word read followed by a byte extraction, if that is really faster.
Well, two things here.. First lets compare the same instruction on RISC and x86. At best, the x86 instruction becomes 1, 2 or 3 micro-opt instructions to perform a byte-load, hitting the lowest level cache and not requiring a virtual address decode stage (which on x86-32 requires an ADD instruction). The Alpha performs virtual address translation on every cache load (because it only requires a logical and), so it takes the same amount of work whether it comes from L1, 2 or main mem.. Only difference is latency. Now older Alphas did NOT have OOE (purposefully since the Alpha design team didn't like the extra load on processing), so you could argue that they won't handle latency as well.
But now, lets consider non word-aligned operations (say 16bit, or even 32bit memory which falls across a natural word bountry, say address 0x0003). You can get this with compacted C-datastructures that are dynamically allocated (if the compiler doesn't pad empty-space to keep alignment happy). In the alpha this is a highly discouraged practice, and most compilers will sacrifice memory-space for word alignment. But in the event that a word MUST fall out of alignment, then the align-instruction must be manually called by the compiler. In the x86, there is no such explicit alignment, so the CPU must at least CHECK for such an alignment issue on every instruction. That test is very likely to be an extra micro-opt.
Now lets consider normal operation of the x86. It is not to load a byte into memory, but to perform a CISC "op [addr x2 + offset] [addr x2 + offset] [addr x2 + offset]". So, what you have are 3 address-shifted memory accesses for say the same byte-sized operation. So now to what-ever extent the x86 is slower at non word-aligned operations, it is amplified by the fact that it has to perform the operation a greater number of times PER instruction (on average). Yes there are behind the scenes tricks to reduce this effect, but that's extra otherwise wasted horse-power, since it represents an abstraction layer between the "virtual" instructions and the real capabilities of the CPU.
no, pdas are too small to be of any use
:)
I wouldn't say size is the problem.. You could always hook an external monitor through a proprietary interface, and keyboard/mouse through bluetooth. Moreover, solid-state data-storeing is about to hit it's prime (with 16Gig IDE drives this fall). The problem is CPU horse-power.. The ARM CPU is simply too wimpy to handle instensive load.. At least, not without killing the battery in short order. The ARM is a bueatiful architecture for power desipation, and not much else.
I've seen some crazy ideas to compromise between horse-power and power dessipation.. For example, lowering the voltage until you get a 1% error rate in your computation, then provide extra hardware/software to detect/correct these errors in a manner transparent to the application. Or take advantage of multi-processing techniques to identify applications which can be periodically put to sleep to reduce average power consumption. Or cache banks which go into sleep modes when not in use, but require longer access time when first hit.
Transmetta had some great ideas too; but notice this involved trying to migrate a prolific architecture into an optimized architecture... These days, if you've got a hand-held, you can afford recompiling all your apps to the optimized platform. Of course, proliferating Java on these hand-helds isn't exactly helping in the performance market.
I still think in 10 years the CPU will be a wrist-watch, and IO will be some external media.. The consolidation in the cell phone market took longer than I expected.. Now we have GPS, MP3, MS office, cell, SD-memory, external-keyboard-capability all in one device. But as said, horsepower is lacking... I'm ignoring, of course the PSP, but consider that too close to a laptop to really count as a hand-held. (That's a dual-hand-held.
64bit isn't some magical spec that solves all your computing needs. Sun Microsystem's Ultra SPARC CPUs have been 64 bit since the 90's. Ditto for Alpha.
And they are vastly superior CPUs except for price/performance. Not because of the 64bitness mind-you. But when your architecture is designed around native large-words, your compiler can take advantage of all sorts of things. Most of which center around higher bandwidth and lower latency.. Take, for instance the Alpha's complete lack of byte-addressing. In order to look at a character in a string, you have to manually align/unalign the data (grab 3'rd byte from word in reg X, place in reg Y). It the compiler is optimized around this process, then dereferencing c-structures can be faster as you are effectively pre-fetched several items and now have an optimized way of breaking it up. In x86 land, you have byte-addressable instructions, but it's highly probable that these will be micro-opt'd into lesser efficient accesses. So 1, 8 or 16 bit operations should actually be faster on an Alpha than on an x86 or worse yet and AMD-64 (with even more indirectness due to 64bit extensions).
And this is to say nothing of the highly optimized 64bit integer arithmetic. You don't have layer upon layer of internal multiplexors to handle dozens of different word lenghts.
Of course the Alpha is mostly a memory; didn't have the volume to sustain itself.. And the Sparc is on it's way out. Being server oriented, they had too much "meat" to ever make their way to the $60 pricetag (even if ever built in bulk).
PowerPC's have/had a chance, but they've stalled for too long and looks like Apple's changing ships. IBM probably couldn't promise them a significant enough road-map for the next year.
While it's great that x86 is hitting 64bit, the bad is that there is simply too many watts of power being dessipated on legacy emulation.. Not to mention a compiler can't know for sure how to optimize instructions, since an optimize compilation won't work best for older CPUs and probably not for newer CPUs. A PPC, SPARC or Alpha design hasn't had tremendous change, so such compilers stood a much better chance of being optimal. Poor gcc.
Lets see, 100Watt for P4 v.s. what 50W for PPC? (someone correct me here).. Lets says 50 Million 100Watt units... We'll say 150Million 80Watt and 300Million 60Watt x86 machines.. We'll average that to 500 Million 80Watt x86 machines.. Compare that to say 40Watt average RISC machines.. If machines are on an average of 2 hours a day, then that's 40 Gigwatt-hours / day wasted because of historical proliferation of a legacy architecture.
At 7 cents / Kilowatt-hour, that's $2.8M / day wasted because of PCs (v.s. a decent RISC alternative).
It looks like the entire industry is converging on AMD / Intel.. Intel will benifit most, but it's Ironic that Intel is doing so off AMD's back (course they still have to write off a couple more billion on that whole Itanium side-track).
MMX was introduced by Intel to kill off those initiatives.
Except that the path to the GPU was still formed and is essentially winning the specialized device wars over Intel. So while you still do find occasional systems with primative graphics devices thereby using the CPU for transformation purposes, the original point of MMX has largely been lost (with the exception of a 515% boost in performance here or there in applications that bother using it's legacy (SSE3)). I don't know about the on-board audio chips.. I know that 3D audio was previously off-loaded from the CPU, but the on-board audio chips are considered just as good these days, and I don't know if they rely on the CPU to do most of their work. So Intel might be considered a winner in this department.
eh, no? 33 bits would be twice as much space as 32 bits. we're talking 2^32 times as many possible adresses!
:)
No, he said "word" with quotes. Meaning the physical space it takes up. 64bit computers take up twice as much data cache. It implicit that the concents of the word have greater value, though it is not specified.
Just being picky about you being picky.
Instead of having a range between 0 and 0.8 volts = 0 and a range between 2 and 5 volts = 1, you make the chip recognize (for example) 0-0.8 = 0, 1.5-3 = 1, 3.6-5 = 2. Wow, a trinary computer.
Bringing it from the transistor level to the practical level, a bit harder....
As an EE: Consider this analogy. Fiber-optics verses copper. Which is faster? fiber you say. Ok why? Because the medium allows for higher bandwidth capabilities? Ok, sure.. But here's an interestin factoid, fiber is usually base-band, while copper often is voltage-varied. Consider the phone line which uses frequency to transmit info (more recently it has effectively evolved to voltage sampling as you reference), but fiber is still 0 or 1; presense or absense of light.
Next, consider parallel v.s. serial BUSes. It is intuitive that parallel buses provide greater bandwidth for a comparable medium, so why did we shift to serial? It wasn't just because it takes up less space / clogs less air (though that's a bonus).
While fiber is a common denominator in both examples, you might ask yourself, if it's possible to send full-spectrum signals in fiber and it's possible to put fiber in parallel like a BUS, why don't we do this with with BUSes and phone lines? Well, the obvoius answer is that the jump in speed was enough to satisfy current demands; there simply aren't 1GBps hard drives yet. But there is another, more practical answer.
Because it's cheaper to use base-band, serial technology.. Computer busses use to be serial on low-end computers in the 70's. It was cheaper to write software on both transmitting and recieving end to serialize/decerialize the material. Plus the computers were FASTER than the medium's bandwidth.
Likewise, modems were analog devices; frequencies were measurable by capacitors; you'd get voltage on one of several tuned sensors, representing bit-patterns. This was originally faster than performing a fast-fourier-transform on the signal and extracting signal-noise compensation, yadda-yadda (which modern home-modems do). The sender, obviously can just digitally generate a voltage-pattern representing error-corrective code-patterns, but due to the phone-line standard, they must ultimately represent sine-waves (unlike say ethernet or direct serial buses).
Today fiber is faster than the computational power, so encoding/decoding signals isn't practical. And the issue with parallel bus synchronization is likely as expensive in fiber sysems as in copper. Thus it is only when the bandwith is really hurting are we going to see parallel buses.. Fiber external RAID hard drives have parallel fiber BUT one in each direction (which is the cheapest way to "double" the bandwidth).
The main advantate of digital v.s. analog was error rejection. When you have a signal that if beyond a threshold is definatively 1 and else 0, then you can amplify it with little fear of INTRODUCING error. With analog amplification, the amplifier ALWAYS introduces some non-linear distortion or power-generation flutuations, etc. So even if you had a perfectly clean input signal (which is nearly impossible), you are garunteed to distort the output signal. Having several amplification hops means noise in inherently introduced into the signal. Then take into account external noise (that isn't compensated for by cabling techniques). Trans-continental phone services were a joke. Introduce bi-state logic. Here you NEVER let voltages get near the quasi-zone, you jack them up signficantly higher than the threshold transition voltage. Now so long as noise voltage doesn't exceed 50% of your voltage, you will never have an in-advertant transition from 0 to 1. Cabling noise-cancellation techniques do wonders to minimize the voltage of noise. So now you can repeat a signal an infinite number of times and not introduce new noise into the system. (Though there is always a statistical chance that it will be intoduced somewhere).
Why does amplification matter? Consider your CPU BUS.. your
Notice I said "should". Obviously the alternative is to check in half-working code as your example implies.
IF, your test/staging environment is automatically pulling from the version-control back-end (via checkin-triggers or polling), then this is still a problem for you.. A human being has to determine when the checkin is valid. In the article's description, they were applying a "sticky" tag. Here, whatever process was applying that tag would be applying the checkin number.
If all checkins are assumed to be valid (backed by unit-tests), then the trigger could perform the auto-posting. This is often a good idea anyway to have some side validation deployment which on each checkin performs a full unit-test suite and flags the checkin as valid or not. In eXtreme Programming or Test-Driven-Design, I've seen the recommendation for the dual lava-lamps (red/green) being auto-triggered based on the most recent check-in.
Obviously some things are hard to unit tests (like web apps/ hardware-based applications), and some projects aren't willing to budget in unit testing. That's just a fact of life. But in these sub-optimal environments, there must be manual analysis.. ergo manual application of checkin numbers.
First, each checkin should ideally be a legitimate build.. You shouldn't check in to the main branch things that are knowingly broken.
I assume you have a staging environment which would pull from the latest main-branch build.. It's easy to see what checkin version staging is using..
Once you have staging in an acceptible state ready for deployment, simply take the associated checkin-number (this SHOULD be a manual process) and post that to production.
In other words, ditch the remapping of tags as you used in CVS. This is an error prone process which destroys history.
In our development environment, we have a wiki that we (manually) update whenever we post things, and each deployment (to test, stage, production instanceX) has an associated svn checkin number.
If there is some memorable tag that we need, we svn cp a tag.. And obviously long-term modifications get their own branches.
While I'm not as happy with SVN's lack of relocatable tags, I do really like the idea that when using svn + fsfs as a backend, you have read-only back-versions. You can see everything associated with the checkin-number. CVS, on the other hand only lets you see the current state of the rcs files.. Sure there's a lot of history in there, but there is no associated "undo".. Yout have to use the cvs tools, and then you have to keep your fingers crossed that you're doing it right.
Nor do I. I think you missed part of my point. I was countering this idea that if I want to hand out my music to anybod who wants to hear it, I can't because of the RIAA. This just isn't true. They don't own all music in the world.
I have no problem with what you wrote, nor do I think my response contradicted you, or your main point of ownership.. I was expanding on the two posts, and focusing on practical terms.. Yes you can own your own music, and yes there are open distribution channels. But the money streams (in it's current form) is channeled and controlled.
It use to be that local radio was a great outlet for local music. It was cheap for radio broadcasters, and was a great exposier for artists; who could win local gigs. But as of 12 years ago (when I last listened to music radio) it was mostly, if not all centralized music. You merely chose the radio station that focused on alternative older, or oldernative younger audiences, etc. Or you simply lived in between two major cities like I did, and had sister channels with slightly different content to which you could flip back and forth in your genre of choice.
My point is that consolidation of the market is likely to dry up tolerance for independent labels by consumers. Without exposure, people like myself don't even bother wasting time looking through up-starts that might or might not be good. When it was forced on me in between songs that I already liked, I could get into a local band. On rare occasion I'd accompany a friend to a bar where a local band played, and I really enjoyed it, so I know I have a taste for it.. But I have no desire to surf the net for random selections of music. I don't know how representative I am of the general public, but I do know that people are inherently lazy and value time above most things.
The big problem is that if we're talking about suing against the next cheapest legal option; apparently yahoo isn't providing unlimited downloads of songs for a flat rate.. I saw somewhere else in this post that you can only stream music from yahoo; meaning a max of 1 song / couple minutes. And sub-CD quality at that.
There is also another issue here. Lets assume that an illicit uploader has taken the time to convert from a DRM-ish media (such as a generic 1990's style CD who's DRM consists the primitive fact that it's material instead of digital) to a DRM-less media such as an MP3/ogg-vorbis file. Prior to the conversion, the media could not propagate freely (costs money or human-energy to move around). Plus the media is non-duplicatable for free. It was your input that produced a new form of media who's production was not free (opportunity cost of time of server spent ripping+encoding), but has set a new resale price to $0. You are in essense a re-distributor, though in most cases (minus marketing rebates) you never see redistributors sell for less than the cost of raw materials.
So you are selling a new product which is based off a different product for less than the base part.. If countries did this, it would be called dumping, and is penalizable for the difference in price..
The difference here over anti-dumping law (IANAL) is that anti-dumping law covers physical assets, so it's not 1-1 corresponding with the problem at hand. It may cover digital assets as well, but that doesn't help clearify the conceptual dillema. Material asset dumping is important to recognize because it represents coersive tactics which are semi-universally opposed (except maybe by economists, of which which I am lay).
Technically, the individual that acquires the license-violating DRM-less material and redistributes it again is only in violation of "possessoin of stolen goods" or "sale of stolen goods".. Now obviously it would be difficult to determine if the commodity is indeed stolen, if not for the general knowledge that there is no legitimate distribution of DRM-less media.. As far as I know you can't even broadcast music without paying royalties (I've heard about gas stations being sued for playing their personal radios loud enough for customers to hear). In other words, it would be a diffcult case to make that you were not aware of the fact that your possession of the Metalica song in a digital format that you didn't directly rip from CD for backup purposes wasn't illegal. If you knew for a fact that an indi-label was given free songs away on the internet, and you downloaded that song from a friend, then redistributed it, you would be ok. Mostly because nobody would sue you if they only ever caught you distributing that song. But also because you could demonstrate that you acquired a product from a vendor who set their price to $0. Redistributing music, likewise assumes you've purchased the music for something like $0 from a legitimate venue (even if it's a friend). But plausible knowledge that the material is hot is punishable. I could be off on my details here though.
So even if you can prove that you don't own any original CD's or have never paid for licensed music thus you could not possibly have been the perpetrator of the illegal extraction of DRM from the media, you are still in violation because of posession of identifiably illegally produced material. And possibly sale (again, even at $0).
It's not too different than home possession of $100 casino chips. Many states make it illegal to have them (to help in the fight against fradulent counter-fitting). I believe mere possession of counterfit money is also prosecutable.
So while I don't know for sure the particulars of the law that facilitates the RIAA in suing little kids, I suspect the "fines" are an aggregation of both possession and direct initial license-violation.
The reason they have to tie the lawsuit to uploading, is that it ISN'T illegal to copy a VHS tape or rip a CD. So you couldn't just
I think it's a little bit of both of you being right. I agree with you that you can take an independent path; the parent is technically incorrect since the RIAA or whatever doesn't have a monopoly.. But that's like saying MS didn't have a monopoly in the late 90's.. Yes there was DR DOS and Linux and SCO UNIX, and OS/2. But they were like 1% of the market.
Likewise, I'm sure the indi venue is an insignificant portion of the audience market but I have no numbers to back me up.
The music radio is mostly clear-channel. I'm sure Satalite radio is clear-channel controlled. MTV is certainly biased towards the establishment. The only large distribution you have left are sound-tracks of big-end movies. With the possible exception of indi-films that at least get a lot of spot-light, if not popularity.
The industry has calculated methods of maximizing profit; tuning various demographics to particular sounds and focusing on particular artists of the month to build sensationalism which causes people to flock to the fad-of-the-month and thus increase revenue. To facilitate this brainwashing, they need LOTS of airtime for their target projects, and this leaves no room for anything else.. With the consolidation of media outlets, the drive to "advertise" a particular label means even less airtime for variety.
So there IS an establishment that is trying to squash unsigned material, albeit indirectly through the reduction of avenues of distribution.
As a disclaimer, I have no association with the musical profession.
Brian Greens' book "The elegant Universe" talks about the history of string theory and if I recall correctly, there were many branches of string theory. One breakthrough in the 80's was M-Theory which tried to consolidate the ideas of 2, 3 and higher-dimensional string-derivative theories. Unless I have the order mixed up, it was then that super-symmetry was introduced. If I am correct, then super-symmetry was part of an exciting theory that was a superset of conflicting theories which provided a semblance of unification (the fabled grand unification theory).
The point is that, unless my memory of the order of progress is wrong, super-symmetry is relatively new to string-theory and definitely wasn't part of the original models. I do not know that disproving super-symmetry disproves all branches of string-theory. No branch yet has experimental prudence, so it's still possible that after back-tracking, one of the earlier branches was on the right track.
Not just wishful thinking, I'm demonstrating that the disproof of super-symmetry does not end string theory; just string theory as we (read me) know it.
What are you proposing? I seriously don't see what you're getting at...
How about this:
cell-camera has crappy image quality. Even if in 5 years cameras have ultra-hi-res, they're still not going to be SLR, so the "highest end" is still going to be separated. Ideally, the PDA/cell will be USB input capable such that you can connect the high-end camera to the central-hub device (the cellphone/PDA). Of course the only reason you'd want to do that is if the phone has multiple gig worth of data and or the ability to upload/download effectively for free (a la black-berry internet, minus the expansion of memory)
Next is audio capability. The iPod has external stereo audio hookup, but most cell phones only have mono output along with the more proprietary input. (Though I think iPod had a proprietary connector as well). Having a single industry standard bi-directory audio port would allow interfacing to your car (as with current (new) high-end cars) or a premium stereo system. Ideally the audio out would allow multiple audio channels (to perform digital-dolby), but this would require an AC3 digital out. Of course, copy-right being what it is these days, that's highly unlikely to happen. So basically we've taken a step back in music quality by shifting fromm CD's to AAC/MP3. No blasting high-end music through central stereo; our music collections are to be listened to on portable device and MAYBE your PC (if the device lets you transfer it to the appropriate machine).
Next is screen-size. I like a large screen on my hand-held, but the larger the device the less portable it is. While people are getting comfortable with Treo-sized devices, this definitely doesn't suite all; especially the athletic type. The blackberry is rather light and compact, but it is very scratch prone. Thus having tiered sized devices with screens may be more suitable for some people.. Take a super-mini laptop like the sony VAIO or power-book as sort of an over-sized PDA, then take a mirco-sized and rugged phone for begin on the go.. The laptop sits in the car and the phone goes with you. Otherwise you might want a super-sized and heavy PDA but need to lug a power-adaptor with you everywhere (like I do).
Ideally in the future these new nano-tube based LCD displays allowing 1024x768 on 5" along with zooming capability should allow for some serious laptop substitutes. I believe we still need a higher horse-power CPU for the laptop replacement to be viable.
Satalite radio is another "component" that isn't likely to consolidate into your cell phone. Unless XM and Sirius allow a common reader device, then you're segregating the market between cell-pda-camera-music-radio that support XM or Sirius. Likely there are licensing fees associated with such a consolidation as well, so it will most likely not take off. Again having an connector (preferably USB) which connects your satalite radio to your portable-audio device would be ideal.
Yes, we're talking about carrying lots of things around, but the need for independent hardware is always there.. The single BIGGEST reason to componentize is to fully allow for future upgrades.. I can connect a turntable, scratch-table, cd-player, digital-cd-player, cd-jukebox, dvd-player, tv, vcr to my pre-amp device. They all comply with the RCA pre-amp standard. By encouraging a common inter-device connections (like USB and associated transfer protocols), you encourage the market to build on itself.. Sellers can more easily get new concepts out into the market, and consumers have more options, more competition and cheaper prices.
When you have all-in-one, then you either have super-cheap or super-expensive (like AIWA or bose). And with BOSE (e.g. high-end), you are stuck with older technology because to make quality parts, they needed a long development cycle.
Everything pre-2.5 was pretty bad for interactivity, but 2.6 is excellent.
Don't really share your user experience.. Being a college student at the time, I salivated over a dual system for years, and finally found the opportunity with the dual Pentium II-class celeron motherboards by Abit. That brief window in history when you could have a full dual processor system for under $250. It was dual 433's overclocked to 466. At the exact same time, I had an AMD K5-400 as my main machine. The dual ran on Red Hat 8 I believe originally, and is still running to this day as my main home-server, and I've only upgraded it to Red Hat 9.0 (main because if it ain't broke, I ain't fixen it). So as I look at uname, it's still only running kernel 2.4.20-31.9smp. I remember running this puppy side-by-side to the K5-400, and later my K6 Thunderbird 800MHZ. The Thunderbird should have blown away with dual 466, but it didn't. I had better throughput of mp3 encoding on the duelies (which I was doing a lot of at the time, farming out all my machines at home and at work 24/hours a day some weeks). One of the features I specificly played with was encoding single-threadedly with grip+lame v.s. dual threadedly. When dual threaded. Obviously single-threadedly the system was almost perfectly responsive (since lame isn't HD or even memory bound), but even when dual-threaded, the system was more responsive than my faster single-CPU K6. I quickly fell in love with the dual processor concept, and used it as my main home-station for just about anything that wasn't video games.. When my K5 literally exploded one day due to moisture damage, I was rather forced to migrate over to the new machine; but it was a welcome change from a mostly windows unresponsive environment.
I am convinced that even Linux 2.4 was more smooth operating with multiple CPUs than windows. Perhaps it is because X is single threaded, but graphical thinking occurs in the application-space and is thus inherently multi-processed. Thus you get the best mixture of non-race-conditions streamlined code with concurrent processing capability. This is purely speculative. Whatever the deal, it was great.
Unfortuntaely, I don't remember if the standard Linux benchmark of doing a parallel make of the kernel was faster on the dual 466 v.s. the single 800. I guess one of these day's I'll have to fire that 800 back up again to check; the dual's still chugging along fine as my server.
Unfortunately I haven't had the luxury of having ANY affordable dualies in the past 5 years, so I've just gone for greater single-threaded horse-power for work-stations.
As for the point of this thread. I seem to recall that the 2.6 kernel had more overhead than the 2.4 kernel. This along with my anxiety for changing a back-end special-purpose servers' OS kept me from wanting to up the now ancient machine. Most likely this overhead is compensated for by the better MT-support, and is especially unnoticeable at the 2GHZ range. But I find it hard to believe a perceptible difference in UI responsiveness could be found between the 2.4 and 2.6 kernels. Perhaps measureably in application benchmarks, but surely not on the GUI.
Sadly, as I've said, I can not provide empirical data as I don't have $1,500 to spend on a simple file-server.
Of course, a cheaper solution would be a better scheduler with a real "idle only and if that means that the damn thing will starve then so be it !" priority.
Not to be sacraligeous, but didn't windows (and probably the MAC) have event-based threads which were only called when there was NOTHING else the OS had to do. I don't believe they were threads, so much as registered GUI-event callbacks. Such handlers were used for background disk-defragmentation, screen savers, and a few other things I've forgotten. I don't remember ever seeing anything like this in a UNIX/Linux API, which seemed like a waste.
That is exactly what I meant. Synchronization is a tricky issue but I'd consider it far more rare than the problem of cycle hogging single-threaded apps.
;synchronize the hell out of it. THe most common aspect of java these days (EJB's or servlets) are all inherently MT, and the design paradigms generally make it easy to work with; you hardly ever have to think about MT (unless you're being evil and creating static variables (e.g. globals)).
Bugs might be more rare, but "hacks" to allow multi-threading by having universal locks are a serious issue. I know that perl 5.5 has a few global locks which REALLY impeeded multi-threading. This is of course because perl wasn't originally designed for MT and people were experimenting with different possible migration paths. Java was pretty good at allowing for MT, but early garbage collection had the same general universal-lock effect. I've been impressed with various MT memory management schemes I've seen in glibc and by SUN (magazine cells), but that's somewhat of a digression.
The thing is that it's easy to write a piece of code to be MT-safe; just never use globals, and when you do
But the hard thing is writing some optimized for speed, because you're VERY prone to take short-cuts.. You have to have the entire variable-space mapped out in your head so you know all the special conditions, side-effects, and use-cases. You're likely to cut any corners you don't expressly see a need to keep "elegant". Thankfully such optimized code tends to be restricted to a very small piece of functionality, lest the whole project be doomed to managerial anarchy. But such pieces of code are serious issues for MT, especially since their goal is high performance. Pray you need never be tasked to do this. If you can divide and conquer by threads, then you can likely divide and conquer by independent pieces of hardware and thus literally throw money at the problem whilst using a more elegant programming paradigm.
Bull. The vast majority of really bad locking issues with multithreading never surface with singe CPU systems.
I disagree.. I've often managed to discover race conditions on a single-CPU machine.. Thanks to pre-emptive multi-tasking. The fact that there's a lower probability of context switching out doesn't preclude situations when un-safe race-condition code-blocks are called extremely often (such as memory management, etc). Push the machine to memory-swap such that every hundreth instruction will incur a context-switch and your problem exacerbates.
win 3.0 and MacOS 8 (and maybe even 9; don't remember) used cooperative multi-tasking so they didn't have this problem as badly.
The terminal is how my grandaddy admins his web-server, dang-it!
How about sshd? That's how I admin mine.
For servers, I've found that having onboard video isn't too bad; especially if you can reduce it's system-memory to 2, 4 or 8 meg.. On a 1+ gigabyte system, the last 8 meg shouldn't be much trouble. If we're talking a budget server ($300 or so), then the money savings can often be worth it.
Lowering the power consumption per core is a first step to upping the number of cores
:)
I find this odd, considering one of the main advantages of having dual-core computers is the lower power consumption for a given performance level.
Course who says, "yes, that's enough horsepower for me all-else-considered".. I would think most would say, what's the max horsepower I can get for my money (including other requirements). But still, it's feasible that laptops are where power-consuption is most concerned, so dual-proc 1.5GHZ machines might be desirable to keep power low and Horse-power high.
If you're buying a 720p (or close to 720p as many are slightly off) set that is less than ~3,000 USD the answer is easy: All of them.
The problem though is that it's BS that the cost of the processing represents affects the price of a multi-thousand dollar system. I can't imagine that a simple $100 PC video card couldn't be stripped of it's bare chips and used as the filter between what-ever proprietary system they use and the input signal processor. It can't possibly cost more than $500 to push an off-the-shelf component into their system. Since base HD-TV's are just above $1,000 these days.. Then such a low-end system of superior down-sampling shouldn't cost more than $1,500.
I understand that most of these monitors have end-to-end proprietary solutions, and thus are internally limited to processing power and not extensible as I've said above. But if you can make a high-cost low-volume chip, then somebody else can make another one that IS extensible for no greater cost.
The problem ISN'T that it costs them a lot to make, but that they would prefer to sell the high-cost (and thereby high profit-margin) sets. So if they're going to sell a cheap-o $1,000 set, then they want to artificially restrict it's capabilities. So they use a $50 CPU instead of a $150 CPU (made up numbers). Of course I'd rather pay $1,100 than $1,000 for a TV that uses a better CPU. But they'd rather me buy the $1,000 set now and when I can afford a $5,000 set, buy it again.
Note these are unsubstantiated allegations; take them at face value.
Since XML is an abstraction on top of plain text files, there's absolutely no way it could be simpler than a plain text file to begin with!
Not true. By text files, we tend to mean line-oriented files. Often to be useful, it must also be field-delimited files.. colon-delimited in password files, or worse with cron-files a mixture of space-delimiting and position-dependence. (after first sevearl spaces, remaining spaces are no longer delimiters).
With XML you are no longer rectangular in your data-structure; no longer rows and columns (and potentially sub-colums), but instead you can more naturally represent the data however complexly it needs, and not have to worry about escaping arbitrarily complex characters, because all XML files use the same escaping.
You're looking at this from the perspective of someone who understands and remembers the differences in a dozen config file formats. Most people don't.
RTFM!!
Seriously, if you're going to be editing a file.. XML doesn't make it easier to understand the contents. Having an XSD or DTD doesn't really help you to know what is supposed to go into the material (and XSD is harder to read than a man page, thank you very much).
You're missing one very important point. x86-64 has hardly anything to do with being 64 bits, and almost everything to do with adding a new execution mode to the CPU (a la SSE). This new execution mode uses a totally different virtual memory manager (which is NOT backwardly compatible with DOS-mode on the x86-32). The dropping of backward compatibility means we can use logical AND instead of logical addition to construct physical memory addresses.
AMD has doubled the number of registers. This is a HUGE factor. Unreal was able to achieve 15% improved performance on x86-64 mode on the same chip compared to x86-32 mode, and they specifically mention the register augmentation as a main factor.
If you aren't privy, registers are critical resources which determine how the assembly code is structured.. If you have enough registers, you can perform register-to-register operations and avoid memory/cache/register-renaming overhead. Every RISC chip today has at least 32 general purpose addressible registers, while the x86 has a scant 8. Moreoever, many of the 8 registers have specialized functions (loop iteration, accumulation, array indexing, etc). While CPU's have gotten VERY good over the years making use of more than 8 registers (through out-of-order, register-renaming, etc), this can add delay into the execution pipeline which hurts critical-paths of execution with non-sequential execution.
I hate when marketers use extremely simple to remember things like 32bit is better than 16 bit, 64bit is better than 32 bit. This isn't a 64bit machine, this is a step closer to a RISC machine, while maintaining 100% of the 32-bit user-mode instructions. Incidently, as some posts have marginally mentioned, 64bit computing itself does nothing to enhance 32bit data-structures. And needlessly moving to 64bit datastructures only serves to waste cache space (thereby reducing performance). There are definitely things that can make use of 64bit data-structures. Encryption, integer manipulation of AMD-NOW / SSE data-packets, large-file manipulation, millisecond-time stamp operation (as used in java), etc. But if you're going to loop through the records in a file, you most likely still only want a 32bit integer. Iterating over a 64bit integer might very well incur an additional propagation delay / extra clock-tick or two PER increment and comparison. It takes longer to operate on more bits since with arithmetic, multiplication and division, you have to carry each digit.. Yes there are neat tricks to minimize the propagation delay, but it's still got to hurt for mult/div. And with array indexing for non-power-of-two dimensions, we're talking full blown 64bit multiplication.
I love 64bit, but that's because I'm a programmer, and I find more and more places that it would be REALLY nice to have 64bit integers and know they are native. I also REALLY like using up lots and lots and lots of memory.. I can't wait to get motherboards which let me put 4 gig of memory in them using lots of cheap DIMMS (instead of very expensive high-capacity chips). I currently use 1Gig of memory on ALL my machines, and STILL find occasions where I could use more. I litterally feel the pain of using only 768M. As servers start using 64Gig, the cost of higher-density chips will drop and 2 Gig sticks will finally be practically priced.
These are the benifits of 64bit computing, but all we here is 64bit.. WOW that must be fast.. twice as fast even.... sigh