And Canada is a confederation and our Head of State is Queen Elizabeth II. There's also no such thing as a Prime Minister according to our constitution.
Well, no, the Prime Minister is mentioned and given a legal basis in the consolidated parts of the Constitution.
See ss. 35.1 and 49 of The Constitution Act, 1982, and ss. 130-131 of The Constitution Act, 1867.
Moreover, the constitutional role and office of the Prime Minister is well established (i.e., given a definition and legal basis) part of the governance of Canada through other statutes, proclamations, orders and traditions which are legally part of the (unconsolidated) Constitution of Canada.
Section III of The Constitution Act, 1867, describing the Executive, establishes the Queen's Privy Council for Canada. The Governor-General acts for the Queen on advice of this Council. Traditionally, the Council recommends the appointment of Ministers, including the Prime Minister. It is tradition which drives the composition of the Privy Council and its deference to the Prime Minister. This is fundamentally Responsible Government, which requires the Government to be responsible to the House of Commons.
The Privy Council itself has two traditions. Firstly, the Cabinet is a committee of the Privy Council. All Cabinet Ministers are Privy Councillors. Secondly, ordinary quorum for Orders-in-Council include the Governor General or her Deputy, the President of the Privy Council, another Cabinet Minister -- often the Prime Minister -- and the Clerk of the Privy Council (who may act as the Prime Minister's Deputy). Thus the full Privy Council will not "gang up" on the Government of the Day.
These traditions are part of the greater Constitution, which includes not only the statutory instruments listed in s 52(2) of the Constitution Act (1982), including all the acts listed in the Schedule, but also statutes, rulings, orders, proclamations and traditions "of Constitutional weight", such as the Royal Marriages Act (1772) or the fate of governments which cannot secure the confidence of the House of Commons. The fact that extant itemizations have always been non-exhaustive lists of items of Constitutional weight is made explicit by the Supreme Court in Reference re Secession of Quebec, (1998) 2 S.C.R. 217. This requires one of the Amendment procedures in the Constitution Act (1982) to be used to change important aspects of Canadian governance, and (maybe amusingly, in the case of keeping the monarchy Protestant) protects related pre-Confederation British Legislation from being challenged by the Canadian Charter of Rights and Freedoms.
Incidentally, this follows the pattern of the British Constitution, which is largely unconsolidated (and not entirely "codified" in the sense of being written down). The Acquis Communitaire is similarly mainly unconsolidated, although the European Union is considering a proposed "clean-up" of the Acquis and consolidation into a single Constitution most of the treaties, directives, orders and rulings of the European Union to date that are obviously of constitutional weight.
EULAs are not well-tested in English law, but it is established in Scottish law (Beta Computers (Europe) Ltd v Adobe Systems (Europe) Ltd, 1997, Outer House of the Court of Session). The Court of Session is influential upon English and Welsh courts, and the Beta decision is considered sound.
In general the argument would be that the item you are purchasing is a limited right to copy the software included in the package. Ordinariy the law of copyright would make you liable if you did so without explicit permission, or if you exceeded the terms of a limited licence.
All other rights are reserved to the copyright holder, and indeed, it is an asset which is depreciated.
Penrose, in the Beta decision, used the following logic: without a EULA, there exists NO licence for Adobe to copy the software onto its computers, and therefore no legal way for Adobe to use the software at all. Therefore the EULA must be part of the contract, and enforceable by both parties. (Adobe enforces its right to copy pursuant to the licence, Beta enforces the limits within the grant of those rights, consideration is based on this meeting of minds).
Untested in English law is exactly how this interacts with section 50(c) of the current Copyright Designs and Patents Act, inserted to comply with an EU directive, which grants some rights to make copies as necessary to make software usable. That is, this is a statutory right to copy versus statutory and common law rights reserved to the copyright holder. It is likely that an English court would expand upon Beta and suggest that 50(c) applies only in the case where a limited licence is acquired which does not include wording with respect to "copying" by dragging from one partition to another on the same system for use by the same user, or by "copying" by transferring in and out of memory or by "copying" to a general set of backups which happen to overlap the software in question. This would be consistent with a civil code reading of the directive.
The salient point would be whether the software itself was acquired, or whether the limited licence to copy data from a sold medium to a useful medium was acquired. In the former case, the statute should apply, but this would be inconsistent with the reality of the past decade in the software market.
You are probably right that the contract completes upon (or very nearly upon) the copying of the software into the buyer's system, and that the seller cannot impose further restrictions from that point, including limits of liability and other terms that would conflict with the Unfair Contract Terms Act and the Unfair Terms in Consumer Contract Regulations. However, prior to that completion, the buyer has the ability to reject the terms of the EULA and not exercise the licence. This would make him or her eligible for a refund from the seller.
A copy made for a third party after completion would certainly be a cause for action under copyright law. There is ample statute and common law in this area.
If EULAs are valid, and the EULA assigned rights to an agent to pursue such action under the Contracts (Rights of Third Parties) Act, a suit in England likely would be successful under both copyright law and contract law. The argument would turn around whether EULAs are valid in England, and likely would follow some of the logic in the Beta case from Scotland.
The 1952 Pharmaceutical Society of Great Britain v Boots Cash Chemists decision in England which established that the contract is concluded at point of sale is not conclusive in the area of limited grants to copy. A solicitor who insisted that it is, and that this invalidates EULAs not clearly and fully displayed at the the point of sale despite the obvious hazards to natural equity, is not one I would wish to do business with.
Well, he's right, cold medicines interfere with the immune response to a viral infection.
However, otherwise healthy people can trade off feeling miserable with a slightly slower actual recovery. Moreover, treating unpleasant symptoms can prevent serious complications.
The most unpleasant common cold symptoms are part of the immune response to the virus.
Fever interferes with viral replication.
Inflammation and localized edema (stuffy nose, swelling) reduces the transport of viral particles to uninfected cells while attracting and activating white blood cells.
Increased mucus production (runny nose, phlegm), sneezing and coughing carry virus particles out of the body.
Headaches and other pain both trigger and result from all of the above.
A typical cold preparation contains: ASA (aspirin), acetaminophen (paracetamol), ibuprofen or some other pain-reliever; a pseudoephedrine salt or other decongestant; and possibly a cough suppressant or antihistamine.
The combination of these medicines remove large physical obstacles to infection.
In particular, medicines that reduce pain and swelling also consequently reduce the incidence of contact of white blood cells with infected cells. WBCs (macrophages, polymorphonuclear leukocytes) are phagocytes -- cell eaters -- they literally poison, envelop and digest infected cells to prevent them being used as virus-reproduction factories. This is also called antibody-mediated cellular cytotoxicity (AMCC or ADCC), and it is a human body's principal mechanism for dealing with viral infections.
AMCC is particularly effective when the viral infection is contained to a small volume of cells readily filled by lymph. Swelling, itching, and pain are side-effects of the containment and WBCs being transported in by lymph. Fever, runny nose, coughing, sneezing and watery eyes keep the virus from spreading especially to tissues which are less accessible to or more sensitive to AMCC. Even more importantly, they make it harder for other infections (bacteria, for example) to take hold as well.
Cold medicines may promote a simple viral infection into a serious disease.
On the other hand, high fever, widespread inflammation edema, constant coughing or totally blocked nose can dangerous. Faced with a serious flu -- these typically provoke a cytokine inflammatory response in the victim -- the downside risks of using cold medicines (especially anti-fever and anti-swelling drugs) are smaller than not interfering with immune responses which cause actual trauma. Modern cold medicines likely would have saved millions of lives in 1918.
However, much more commonly, cold medicines simply make the user much less miserable for the few days the viral infection lasts.
Pseudoephedrine salts are also regularly taken by people with recurring acute sinusitis. These people usually have an allergy to something nearly impossible to eliminate from the environment (dust mites, for example) and are prone to paranasal swelling. The swelling itself hurts, and also may cut off airflow between the paranasal sinuses and the outside of the body, leading to pressure differences that cause tissue stress and trauma inside the sinuses (and thus more pain and swelling). The pain can be excruciating and resilient against non-opiod pain relievers.
Worse, the lack of sinus drainage and the trauma to the sinus tissues encourage secondary infections of the sinuses and inside of the head, some of which can be extremely dangerous, as well as bronchitis and pneumonia.
Nasal decongestants -- particularly pseudoephedrine -- can prevent the initial swelling, terminate the vicious circle of an acute sinus attack, and are generally safer and more focused than aspirin, acetaminophen or other pain relievers or anti-inflammatory drugs, especially ones which contain opioids like codeine, hydrocodone or oxycodone.
The minor interference with the immune system by sinus sufferers using pseudoephedrine is alm
The Fischer-Tropsch process was not invented by the Nazis.
Franz Fischer and Hans Tropsch invented their process in the 1920s, while working for the Kaiser Wilhelm Institute for Coal Research.
Fischer died in 1932, before the Nazis came to power. Tropsch, a Czech, died in 1935, before the passage of e.g. the Nuremburg Laws and years before the Nazi occupation of the Czech lands.
In the 1920s, pre-Nazi Germany had lots of coal and practically no petroleum. Oil imports were expensive well before the Nazis. Processes to use coal as a fuel for small vehicles were an obvious and important area of research in Germany, even without war being a factor.
In any case, you seem to have little understanding of how European "democracy" works. European Commissioners are almost entirely unaccountable. Many are political rejects
The President of the Commission is nominated by the Council of the European Union, which comprises the 25 member states, represented by the elected government of the day in each country. The directly elected European Parliament must approve the Council's nomination.
The remaining Commissioners are selected by the Council and the confirmed President jointly.
Consensus politics has led to a convention wherein the Council is expected to propose a Commission with a Commissioner from each member-state, prepared to act in the interests of the European Union as a whole, and to act as a counter-weight to the governments of the day in each member-state as necessary. In particular, Commissioners are not supposed to take directions from the indivual member-states, especially not the ones from which they hail.
This results in the Commissioners from each member-state generally being people who have been in the leadership of an opposition or minority party, rather than the party of the government. Often this means "reject" politicians from a previous government.
However, the Commission is not self-selecting. It is selected by elected government officials in each member-state.
As to accountability, the Commission is responsible to the European Parliament.
A newly nominated Commission must be approved by the directly-elected European Parliament before its term can begin. The Parliament may withhold approval for whatever reason it wishes, and it has done so on a temporary basis at least twice.
The current Baroso Commission faced weeks of delay in confirmation by the Parliament, which insisited on changes to the proposed Commission. Those changes were made. In particular, Rocco Buttiglione and Ingrida Urde did not become Commissioners, and Laszlo Kovacs was moved to a different position (taxation and customs instead of energy).
The Commission can be removed as a whole by a 2/3 vote in the Parliament. This has been threatened a number of times.
The Parliament further asserts that it can remove individual Commissioners, however this has never been tested. The Santer Commission resigned in its entirety before the Parliament was able to agree on whether it could insist on the removal of Edith Cresson (then the Commissioner for Research, Science and Technology) on the grounds of fraud and corruption.
The Treaty Establishing a Constitution for Europe tweaks all of the above somewhat, increasing the relative power of the European Parliament. In particular, the Parliament is given clear and final approval and removal rights over each of the individual members of the Commission including the President; the Council must take into consideration the results of European Parliamentary elections when proposing a President; and the Parliament would become equal to the Council with respect to initiating legislation and giving direction to the Commission.
Whether and how the TCE will be established is uncertain at best, however it is clear that power is accreting in the directly elected European Parliament, and that it represents the best hope of removing both the real and perceived democratic deficit in the European Union. (MEPs are not uniformly good at being visibly democratic politicians, however...)
"The US way" (never mind that the pattern is just as likely to be used by large Swiss or Danish pharma companies as American ones) will run into the problem that there is a lot of similar work covered by patents in countries which have recently become full members of WIPO (and the European Union too) and thus by treaty have prior claim to patent protection in the USA.
However, actually engineering a better delivery mechanism or greater effectiveness could be extremely useful, whether it is promoted by or simply allowed by "the US way".
Your "clusterbomb" suggestion has two problems in that if the phage therapy is used to attack and an E. coli strain in the gut and get it to produce a bunch of antibiotic prior to being lyse, there is a risk that the antibiotic will kill the attacked bacteria before it explodes and releases copies of the bacteriophage (so, the antibiotic merely reduces the effectiveness of the virus and nothing else), or it will introduce tiny amounts of wide-spectrum antibiotic to succeptible microbes also in the gut (so, the antibiotic serves as a tiny selection pressure in favour of resistant genotypes).
Maybe a neater idea would be to manipulate the viral DNA to have it code a mutagen that affects the viral DNA itself in a way that encourages parallel evolution with surviving target bacteria, and another "edit" which makes the virus itself more susceptible to ex vivo conditions to limit its spread in the wild. (The latter seems like a very Monsanto thing to do...)
"Phage" is Greek for "eater". "Bacteriophage" is a virus that attacks bacteria.
Viruses are almost always entirely species specific, mostly because they rely upon the structure of the cells they attack. The structures can include any of the cellular membrane or cell wall, the various DNA transcriptase and polymerase enzymes and the nuclear or chromosomal DNA itself. Bacteria are simple eukaryotic organisms so lack a number of other structures that can be abused by viruses and virus-like agents, and consequently bacteriophages are relatively simple DNA viruses.
Bacteriophages are extremely common, particularly in bacteria-rich open water, especially in plankton-rich parts of the oceans, where there can be much more than 1E10 viruses per litre.
A typical human being will encounter billions of viruses a day, almost none of which will challenge the active immune system -- most will be blocked by the passive systems (the skin, the mucus membranes...).
Bacteriophage therapy bypasses the passive membranes entirely via direct application to an infected wound or by intravenous injection. Since the applied or carefully injected viruses are monoculture and highly species-specific, they do not challenge the body's primary immune response mechanisms except to the extent that any foreign protein in the blood would in dilute amounts.
The important consideration is that the rapidly-responding innate immune system is unlikely to challenge an injected bacteriophage. The viruses cannot infect the host cells and consequently do not distress tissues (danger model and simple phagocyte chemotaxis) and are unlikely to be associated with TLRs in the innate immune system, or even encounter NODs (PAMP/PRR model).
The adaptive immune system is much slower, which is why people are ill for several days when infected with a new pathogen. It essentially exists to memorize successful attacks against serious infectious diseases the host survives, so as to mitigate or prevent future infections by the same (or very similar) microbe.
The plausible risks to the therapeutic bacteriophage itself when introduced into a human being with a normal immune system are mainly that the human's fever and swelling responses triggered by the bacterial infection physically keep the viruses from infecting their target bacteria, or that the human had tissue insulted by a highly similar virus (improperly injected such that it remained at high concentration, perhaps) at some time in the past.
However, the amount of virus to be injected is tunable, and it is much more likely that in the short term the bacteriophages will find, attack and kill most of its target bacteria than they will be wiped out by the patient's immune system.
The major practical problems with bacteriophage therapy is that they are like very narrow-spectrum antibiotics. You need to culture the bacteria in vitro and check its susceptibility to specific virus strains, which can take a full day or more. Moreover, if there are multiple strains of infective bacteria, you can "miss" with the culturing and only partially treat the patient. The time and possibility of "misses" going undetected for a while account for the popularity of wide-spectrum antibiotics.
Unfortunately, wide-spectrum antibiotics are an evolutionary selection pressure on microbes succeptible to them... those that aren't killed because of some inheritable trait are likely to pass that trait onto their offspring. Staph. aureus, a common skin-infection bacterium, is particularly good at this, and there are strains which are resistant to very strong wide-spectrum antibiotics and even some semi-wide-spectrum ones targetting gram-positive bacteria like methicillin and vancomycin -- these are the frightening MRSA and VRSA "superbugs".
The scary thing is that Staph. aureus bacteria are often not the bacteria being treated with wide-spectrum antibiotics like penicillin, so they are overlooked. Survivors may pass on resistance.
Cutting up videos into "chapters" and encoding each on a different processor, as you previously suggested, would not possibly work for "live" encoding
Precisely, thus the multi-SPU pipeline approach.
This type of application is written as a pipeline anyway, QuickTime et al simply favour that programming model, and coincidentally benefit from spreading pipeline stages across multiple processors on a system that has them.
The EID is much much faster than main memory, and the Cell's internal mailboxes are much quicker synchronizers than any multiprocessor approach.
So, for pipelines dominated by floating point work, Cell is a winner.
can be done quite easily on a single purpose-built ASIC, and doesn't need multiple cell processors
Single-Cell systems would be cheaper than extant hardware solutions (single G5 Mac + Enigma or Altair for example). Sure, an ASIC or FPGA approach is thinkable, but not with the combination of cost and flexibility that a Cell system could. For that matter, a quad G5 system often outperforms extant hardware approaches, even though it has less than half the vector processors of a single Cell.
Still, no. All it requires is a memcpy
Huh?
Computation depends on the number of pixels. More pixels, more computation. More pixels in a given unit of time, more computation in that unit of time. Pixels over time is bandwidth or, alternatively, bitrate.
HD is lots of pixels per second and a typical source is lots of bits per pixel... mutating all the pixels in a frame is not computationallly free, and if you have timing requirements, this is important.
I don't see where memcpy cost comes into it. The dominant cost is e.g. the gamma function against every 24 bpp datum, or a 2D-FIR scale across every frame or field.
Memory can be a bottleneck, but that's feeding data into the floating-point processors... The idea is to avoid constantly blowing caches by either:
[possibly keeping code in cache, probably thrashing field data] - process field through mutation algorithm A (run to completion) - process field through mutation algorithm B (rtc) - process field through mutation algorithm C (rtc) - next field
[possibly thrashing code, probably not thrashing field data] - process pixel through mutation algorithm A - process pixel through mutation algorithm B - process pixel through mutation algorithm C - next pixel
It's likely you have to have some of the first approach if you take the second; some operations are going to work on full fields or frames.
A pipeline lets you do this if you have multiple processing units:
[on processor 1] - read pixel from source - process pixel through mutation algorithm A - write pixel to proc 2
[on processor 2] - read pixels from proc 1, assemble field - process field through mutation algorithm B (rtc) - write pixels to proc 3
[on processor 3] - read pixels from proc 2 - process field through mutation algorithm C - write pixels...
The Cell's SPUs are well-suited to this type of small program, and tends to favour small rtc algorithms.
You can do this with multiple standard processors too, but the "write to proc N+1" "read from proc N" pairs are likely to be much slower than SPU->SPU communication which benefits from the extremely fast EID.
Finally, for completeness, you can do it with one standard processor as well, although then overhead of what is ultimately a threaded/distributed functional programming style will be a performance drawback compared to a non-threaded monolithic style.
Sure, you can always have a strict GOP setting, and CBR encoding, but you will spent a lot more bits on much worse quality, as I've already said
Today's broadcast media (ATSC) are typically CBR anyway...
I think (and this is because of your reference to "Xvid, lavc, etc") that we are discussing totally different markets. My point is not that Cell is a good fit for Apple's mass market segments comprising home and casual hobbyist users.
I am suggesting that the Cell would be good for very high-end Apple customers processing HD "live" in the truck. The sort of people who have teams doing NLEs to allow for instant replays and the like, for full HDTV broadcast.
Organizations like Molinare for example, not people at home ripping DVDs into CD-sized mpeg4s.
That particular application would benefit from Cell precisely because the source and destination format bitrates are so high that cropping, scaling, gamma-correction and the like do use noticeable computation, enough to pose the risk of a delivery delay unacceptable to in-the-truck broadcasters' customers.
Incidentally, the formats being handled are HDV and MPEG2 at various bitrates. MPEG2 as a source format is laid out in GOPs; MPEG2 as a destination format has predictable (even settable) GOP layouts and settable data rates. Parallelization by GOP is precisely what happens in this type of application, whether it's done in a multiprocessor/multisystem rack or using multichip hardware compression engines.
However, in Moliere's workflow and any other Apple-using software-only setup, parallelization is mostly to access the Velocity Engines for floating point performance, and the overhead for this is high (network driver code on both machines, time on network, synchronization code) and for applications which parallelize over 4 dual core G5 XServes for access to their Velocity Engines, the Cell would eliminate the first of these two overheads entirely, and dramatically simplify the last.
When the target is HD and SD broadcast you benefit from parallel compression as I outlined. Yes, you can also benefit from this for delivery to other media (DVD, HD-DVD/Blu-Ray eventually, or even a video iPod compatible mpeg4) however most high-end customers know that offline formats don't need massive parallelization in the final preparation, just as you do.
In short, the mass market does less-time-sensitive workflows that would like to reduce (but are tolerant of) slow (or even no) NLE, and can wait hours for delivery of edited source material to non-broadcast formats.
Higher end customers want quicker NLE because they are paying professional editors and have budgets for expensive equipment. Those that are working on recorded content to be delivered at a particular time (film release date, TV show air date) are the customers that Cell would attract.
Moreover, video is not the only obvious high-end application as far as Apple's serious pro customers go -- almost every application listed in Apple's Pro (UK) page is heavily floating-point dependent and uses SIMD parallelization already. Several would benefit from the massive floating point performance available with the Cell architecture -- essentially the Cell would bring a greater than 4x increase in available Velocity Engine power per system compared to systems using G5s.
However, it's not clear that Cell would scale as well as denser and denser G5 systems for the ultra high end applications because the control logic for massive parallelization (especially just sourcing and sinking the data) could begin to push at the PPEs limitations compared to those of the G5's PPC core, or might wind up being called upon to do much more non-floating-point computation at some point in the future. Therefore, the larger cluster applications listed at Apple's (US) Pro page might not be suitable for the Cell. However, as with the UK page, many are.
So, there is a clear and profitable market segment that would benefit from the Cell enough to buy new Cell-based Macs. Whether that segment could pay for the software and hardware d
I wasn't proposing threading or parallizing in the video compression case, I was proposing streaming. This eliminates the overhead of context switching and the continual setup of the SIMD code of each stage of the stream within the PPE program itself. This trade-off involves the use of the Core architecture's mailboxes, which is mostly a SMOP.
You could think of this as if it were a UNIX pipeline:
where each process runs on its own processor, and the bandwidth through the pipes is very large.
Some of the CPUs will block waiting on the compress stage. That happens in reality, both in the heavyweight and lwp/thread models which exist today. However they are blocking/running/unblocking without taking away processor time from the compress stage, and that is likely to be a significant and noticeable improvement in overall workflow throughput.
Video processing often *is* highly amenable to parallel processing: the coordinating process ships off a discrete chunk of video -- a GOP perhaps, or a chapter -- and gets back a compressed version at some point in the future.
Finally there is a per-frame parallelization in a streaming approach that can *help* with quality, notably exhaustively searching fullpixel motion estimation in the compression stage is likely to be made quicker by doing different algorithms on different SPUs in parallel, and discarding the lower-quality results returned from them.
The multi-SPU large model programming model IBM likes to talk about is amenable to that sort of branch-and-prune streaming approach, which is useful in a number of floating-point intensive workflows. Video is one of them, obviously, but not just as the equivalent of GPU-style shader engines. (On the other hand, you could think of it as exactly the equivalent of GPU-style shader engines with output going to a file rather than to a screen -- and in that sense, Cell would be competing with a graphics subsystem that can *compress* to H.264 et al rather than just accelerate the decompression and display of them).
Never mind using the Cell's SPUs as shader engines -- your GPU will do that job just fine. What you want the SPU for is any streaming single-precision floating point workflow with multiple stages or parallel streams. The throughput ought to be much better on Cell than other high-end processor architectures, leading to an earlier finish of such a workflow. Time is money.
One obvious application is rendering and compressing. The Cell will let you pass the output of one SPU's miniprogram to the input of another's, so you can have the SPE process I/O and feed raw data in and out of a bunch of SPUs it sets up to cook the data. A set of SPUs can do the cropping, scaling, static denoise, temporal denoise, gamma adjustment and compression while another set of SPUs can adjust audio volume, dynamic range and compression. This approach would blow the socks off a fast standard core + single SIMD engine. A dual core on the same die would give a speedup of course, but given the heavy streaming floating-point activity the second PPE-equivalent might not be helpful compared to the second SIMD engine, and here you have two and not eight as in the Core. A multi-die solution giving 8 SIMD engines (and 8 cores) by comparison pushes at the limits of inter-package and memory bandwidths -- the Core's EID interconnect is amazingly fast.
Lots of Apple's pro apps (Final Cut et al, Logic et al) are used by people with workloads that would benefit from the Cell architecture by finishing a particular job earlier than on a multi-PPC or multi-Intel system. The two-issue/dual-thread in-order restrictions on the PPE won't be a problem for apps compiled and scheduled for the Cell -- Universal Binaries and gcc 4.0.1's Apple-specific -fast flags can do this easily.
Meanwhile, code built for Motorola G3s, Moto/Freescale G4s and IBM G5s (including VMX/Velocity Engine code) will run on the Cell's PPE without recompilation, but not as quickly as code explicitly (re)built for the Cell. Whether it would be *too* slow is an interesting question.
In principle, system performance on dedicated-use media processing workstations built around the Cell would be somewhere between fine and exceptional depending on how much the code relied upon VMX (aka Velocity Engine or Altivec). Worst case performance would occur when running lots of applications scheduled on much older PPC implementations, so simply booting a disk filled with apps built years ago would be the least optimal (but still working) start to a Cell system.
Slow but essentially full backwards compatibility is possibly a curse rather than a useful feature. It was for Itanium. Some of that is that most of the pressure to supply a processor-specific optimization of an application that works on the new processor is removed.
Apple is relying upon software ISA-to-ISA translation on the new Intel Core Duo systems, and the Cell likely would in all cases outperform Rosetta-on-Core-Duo in terms of speed and moreso in terms of running SIMD code, and compatibility issues like giving non-garbage results to exception routines...
A recompile into a Universal Binary probably would give the advantage back to an Intel Core Duo over a single Cell especially for multi-threaded apps using little SIMD. Heavily SIMD-using code would likely favour the Cell even if only the PPE's VMX was being used. The Cell would almost certainly beat the Core Duo for all tasks dominated by floating point operations, provided those operations were performed by the SPUs.
If Apple ever seriously considered the Cell architecture for market segments that do lots of real work dominated by floating point performance, it would be pretty clear that a smart thing to do would be to have most of the floating point code be hidden in Apple-supplied frameworks (libraries) tuned for particular processor implementations (e.g. the Core Duo, PPC 970 and Cell). Mac OS X already mostly does this with (among others) its Accelerate, QuickTime and Core* frameworks.
I don't think your concerns about the Cell are really applicable.
The Cell is a combination of an ordinary PowerPC (called the PPE) and eight floating-point vector processors (called the SPEs), interconnect and peripheral logic, on a single die.
The PPE (Power Processing Element) will have the standard 970 instruction set including the powerpc-gpopt and powerpc-gfxopt operands. It's a two-thread dual-issue 64-bit general purpose processor that will work pretty much exactly like the 970s in Apple's G5 systems. It has a shortened pipeline which favours well-optimized code (you could think of this as penalizing poorly-optimized code, too). It has a small 16kB L1 cache and a 512kB L2 cache, but can use the high-speed interconnect (EIB) to talk to other local memories. Moreover, it has a standard VMX vector engine (which Apple calls the Velocity Engine and most people call Altivec).
The PPE on its own would be a decent G5 system for running code built with the "-fast" flag in Apple's XCode-bundled gcc 4.0.1 and with standard Velocity Engine acceleration code. Most of the computation workhorse frameworks (QuickTime et al) ought to work well when compiled for this particular target. Fat (er, Universal) binary support could do this trivially.
On its own the PPE should be competitive with a single-core PPC 970 (Apple G5) for most of the uses one would make of a single-processor Mac. There is no reason why one could not use multiple Cell packages in a system, along the lines of the dual G5 systems. However, the dual-G5 packages (especially the quad G5 systems) ought to outperform PPE on code that is principally unvectorized G5 and VMX tasks.
That said, the 8 SPEs one gets on top of the VMX open up a new world.
The Synergistic Processing Elements (SPEs) could be looked at and programmed as if they were additional VMX units requiring a preamble and postamble when invoking a vectorized subroutine. Because of the overhead of uploading code to the SPE and syn chronizing between the SPE and PPE, the SPEs are more suited to processing large data blocks. This model would let the PPE (and VMX) focus on other tasks while a large data set mutation was being processed by an SPE.
Another approach would be to stream data through an SPE: the preamble would upload a small program (like a tiny operating system) into an SPE, which would then iterate over datasets as they became available. The PPE would notify the SPE when new data becomes available, and the SPE would notify the PPE when its processing finishes.
SPEs can also notify each other, so one could mix both of the above models, with some SPEs being notified by others (in a chain, most likely), and some being notified by the PPE.
In a Mac OS X environment, substituting SPE programs for Velocity Engine subroutines would be a SMOP for developers used to Velocity Engine programming. If anything, this is already becoming easier with the migration support for Intel's SSE3.
The Cell would be a good fit for an Apple workstation used for media processing tasks, especially processing video (NLE, rendering, transcoding, compressing). Chaining together several image mutating SPE-based programs in a large multi-SSE model would be a much higher throughput approach than current unvectorized-G5+VMX threads.
The Cell would also be a good fit for scientific programming that leans heavily on double-precision floating point. There is a large hit for using doubles instead of single precision in the SPEs, however they are both fast and numerous, and would work well for parallelizable tasks.
In single precision and in parallel the SPEs look a little like shader engines on modern 3D graphics cards.
The question you raise is whether general purpose computation-intensive code that was not opt
Directives come from the Council of the European Commission, which comprises every member state in the European Union. Typically a member state is represented by its head of government or a representative -- often a minister or a civil servant directly reporting to a minister.
The government of the moment of each and every EU country therefore is directly involved in originating directives of this nature. Each EU government is popularly and democratically elected.
Every directive must be reviewed and approved by the European Parliament, whose members are popularly elected directly by EU nationals.
The European Commission is also involved. Commissioners are appointed by the Council and approved the Parliament, and are collectively responsible to both bodies, either of which unilaterally may force the entire set of Commissioners out of office.
The Commission's role is typically advising the Council (sometimes making suggestions on directives to initiate, much more often providing technical and legal advice for whatever the Council cooks up on its own) through the legislative process, as well as trying to resolve any conflict between the Parliament and the Council when the former does not approve an initiative of the latter.
In any event, the Commission oversees the implementation of any directive finally agreed between the other two institutions, and may bring pressure to bear on members states which implement things the wrong way.
The defeated Constitution would have given more power to the Parliament to act as a check against the member states, on the grounds that MEPs are directly elected, represent finer-grained constituencies, and frequently are members of non-government parties (who have no direct say in the Council). The weakness of the Commission, where retired senior "opposition" politicians were the most common form of Commissioner suggested by each member state, was one reason. Another was the increasing tendency of several member state governments to run their local agenda through the existing process and then blame "Europe" for the results of their very own efforts in the Council. Finally, the hope was that a much stronger (as in more able to block the actions of the Council and review and repudiate the Commission) directly elected Parliament would solve some of the "democratic deficit" public relations disaster which has plagued the European Union.
This may be a case where Finland is blaming outside forces to disguise local politicians' pet projects. That this is both possible and plausible is what I think the greatest democratic deficit is: non-transparency.
Unfortunately, most of the other member states use the same tactic with some regularity and are unlikely to rebuke Finland for blaming the EU in general for something that none of its three institutions really approved.
Sadly, there are national polticians in every country who simply enjoy manipulating people into believing that it's all "Europe"'s fault when they decide themselves to do something unpopular.
Clients can request individual packets are resent to them alone (works well if packet loss is very low).
But it works badly when lots of clients observe packet loss. The worst case is if you have many many clients listening to a multicast source, and there is loss on the line between the source and its ISP. The source might be drowned in retransmit requests, much like in a DDOS attack.
Carousels are fine and dandy, but if you have missed just one chunk of a large file, you may have a long wait, and lots of bandwidth wasted by sitting on the multicast stream until the repeat. Scheduled rebroadcasts are an optimization: if you know when your missed piece is going to be rebroadcast, you can unsubscribe until a little before that time, so you don't have to receive all the bits you already have.
However, odds are that for any reasonably large file, you will be better off finding another client who did receive your missing bits, and retrieving them from it, than waiting for the "rerun" transmission.
Initially a full multicast transmission of the file would be done, and after that, the tracker could look and see which parts of the file were missing at the greatest number of clients.
If there are large numbers of clients, this operation could be very expensive for the tracker.
The other consideration with this approach, unfortunately, is that there is a serious mismatch between the rate at which the fastest-connected and slowest-connected clients can absorb the multicast traffic. If the source transmits at, say, 2Mbps, there will be about 50% packet loss observed by people with 1Mbps (down) DSL connections, with worse losses as you decrease the last-hop down bandwidth. The loss doesn't really matter to the source (there is no direct feedback), but you aren't going to make up for massive losses efficiently by repeating a multicast stream for the benefit of the clients observing the worst loss.
This is where the P2P+unicast-TCP distribution system can demonstrate its strength, if the P2P overlay routing system could take link/pair performance into account.
If that were the case, the apparent optimization of allowing fast/low-loss downloaders to receive file parts at high speed via multicast, would look less attractive than the current system where fast/low-loss downloaders may find themselves taking parts of files from dial-up users. Investing time in a fix for that kind of pessimal behaviour is a good idea, and probably more productive within the unicast-P2P framework than in working out a parallel multicast mechanism, not least because multicast is not widely available even to DSL-connected clients.
Imagine what would happen if ISPs started supporting IP multicast.
Some do. Ask yours. There are two principal availability models for native multicast that I know of. Both require asking your ISP to talk sparse-mode PIM and to exchange multicast NLRI with you via BGP. At least one large scale provider charges a nominal fee for doing this at all, at and least one large scale provider does this for free but caps the amount of multicast traffic you can send without making an extra arrangement.
The principal problems with multicast are operational (not many people know how to set up and debug it, although Sprint's mulitcast pages are an OK start. However, IP multicast is only reasonably scalable when you restrict yourself to single-source trees, but on the other hand SSM (with PIM-SM and BGP) is coincidentally the least operationally difficult approach.
The main engineering problem is that you inevitably create state in routers for each source that is being listened to (you can optimize out state for silent and unsubscribed sources) in all the routers from the source to each destination. In practice there is "collateral damage" state in most routers in a network in between sources and subscribers. This is cut down somewhat by using Rendezvous Points and distributing those using anycast and MSDP, which moves work from border and intermediate routeers into the RPs. This works well, but incurs a cost which increases as multicast traffic increases. (Essentially, you can drown your RP with traffic. You can distribute RP work, but that then increases control traffic on the routing or source-discovery planes, and there will be some limit.)
In short, the model which scales well enough to make multicast essentially "free" beyond the cost of IP connectivity, is limited by the number of multicast transmitters. The number of subscribers is barely a concern, and the sender's bandwidth is unlikely to pose an engineering issue at any speed less than a gigabit per second.
Making material with lots of FEC or which is loss-tolerant available via SSM is cheap and easy. An obvious application would be live TV content, and that could take advantage of multiple parallel groups -- clients would "slow start" by subscribing to a low-bandwidth stream, then graduate to other (or more) streams if reception works well. Likewise, if whatever stream they are subscribed suffers from too packet loss, the source can unsubscribe it and use a lower-bandwidth/lower-quality one instead.
From the originator's perspective, this is exceptionally easy: originator announces the sources and just blast multicast packets out to its ISP. The ISP will simply drop any traffic in groups that aren't subscribed-to by someone. The originator is thus limited by the bandwidth out to the provider, and nothing else.
If the originator has loss-tolerant content to begin with, or a loss-tolerant encoding (with lots of forward-error-correction or redundancy for example), the originator doesn't even have to cope with network losses. This means the audience can be *huge*.
A file distribution model is plausible using this type of system... you would just "build in" the retransmissions that inevitably would be required because of network losses. The problem is in feedback: you probably don't want to transmit if there are no listeners; you probably want to transmit at about the greatest minimum speed at which there is no congestion-related loss observed by your subscribers; you probably want to tune your retransmissions/redundant transmissions based on client needs. All of this requires a communication from receivers back to the source.
If there are lots and lots of receivers, you risk drowning the source in feedback.
If there are very few receivers, then this is a very heavyweight mechanism for sending data to them. Moreover, if the receivers can also be transmitters, you will get better performance by ha
Not to mention that Canada is the only major industrialized nation in the world to have ever given a country the direct capability to build nuclear weapons (i.e. India's use of a CANDU nuclear reactor to breed spontaneously fissile material for a bomb in 1974).
CIRUS, the Indian reactor in quesiton, was based on the NRX design. While it's a heavy-water-moderated/light-water-cooled design, it significantly predates CANDU. The latter is geared towards use in a nuclear power plant; NRX is geared towards materials testing, isotope production, and physics research. It is not especially better than any other research reactor at breeding isotopes -- it just that it trades off a need for (expensive) reactor grade heavy water against ordinary industrial production of the core. Other designs typically need a much much hotter and/or highly pressurized core, requiring heavy industrial processes which are harder and much more expensive.
Although the overall design was very similar NRX, and the C in CIRUS is for Canada, the "US" is there for a reason: the U.S. government provided the financing and the reactor grade heavy water to the project.
Certainly NRX, like many early reactor designes, can be coaxed into breeding weapons materials. There are even some aspects that make it easier, notably the on-line-adjustable pile and the facilities for irradiating test materials.
From a legal perspective, NRX wasn't covered by nonproliferation rules or under IAEA safeguards, mostly because most of those did not exist at the time of the sale of the relevant designs and components. Both C & US stipulated or had contract terms requiring that CIRUS be used only for peaceful purposes. India violated these terms, and both of the other parties cut off nuclear research ties for decades as a result.
breed spontaneously fissile material for a bomb
Breeding, yes... they needed a source of neutrons to bombard 238U. A 238U atom occasionally captures a neutron, becomes 239U, which decays into 239Np which decays into 239Pu.
238U much more readily captures a fast neutron than a slow one. Fast neutrons are emitted by Uranium fission. A moderator turns a fast neutron into a slow one. NRX, since it uses nearly pure heavy water as a neutron moderator, supplied slow neutrons efficiently. There are much more efficient designs if the goal is to produce lots of fast neutrons in order to breed plutonium from 238U, rather than lots of slow neutrons in order to sustain a uranium fission chain reaction.
In 1960, when the reactor was first turned on, the idea of using CIRUS as the basis of a nuclear weapons program was possibly genuinely surprising. I honestly don't know. However, it did take 14 years to go from activation of CIRUS to India's first nuclear weapons test. However in retrospect, with today's knowledge, the proliferation risk would be obvious.
spontaneously fissile material
The important quality of nuclear weapons material is not that it is spontaneously fissile, but rather that a small mass of it compressed into a small volume of space can sustain a highly energetic nuclear chain reaction.
Why should I as an anglophone business owner have to display French signs on my business in Quebec? What if I don't speak a word of French at all?
I don't agree with the "victim" mentality so common among the péquistes, however it might help to remember that there certainly was much worse in the years before la revolution tranquille of the late 60s and early 70s.
In the early 60s and before, in any sizable company in Montreal and Quebec City, and in any white-collar position at all, the working language was almost inevitably expected to be English. It wasn't just that an office full of francophones would be expected to accomodate a single anglophone when speaking with him (hey, not many "hers" in these situations back then), or in meetings where the anglophone was present, but even when discussing things amongst themselves. A watercooler discussion in French was grounds for termination -- you could get fired for speaking your own language together.
In large department stores in Montreal and Quebec City, you'd see English-only signs. Staff were taught to greet people in English, and to use English preferentially with customers who could speak either language. As in the case in many offices, no personal discussions in French would be allowed, or you'd be fired.
There was real oppression in the workplace -- it wasn't just a case of possible bias like thinking that maybe a francophone might be a little more bilingual than an anglophone and thus more suitable for a government job if all other qualifications were equal, it was: Speak English Or You're Fired.
"Maîtres chez nous" -- masters in our own home -- was one of the reactions to the social changes of the 60s. Many people took the view that the workplace language rules were not only oppressive, but they effectively enslaved francophone Quebecers, often at the hands of business owners and managers with no personal connection to Quebec beyond responsibility for the office, plant, branch, or facility in the province. Practically everyone who saw the situation as unfair wanted either to end the unfairness, or to outright turn the tables on the oppressors.
Camille Laurin ended up in the second group -- the revolutionaries -- and he ended up being the guiding force behind what in English is called Bill 101, which established French as the sole official language in Quebec.
Another group ended up supporting the recommendations of the Laurendeau-Dunton report (Royal Commission on Bilingualism and Biculturalism), many of which were championed by Pierre Trudeau, who introduced the Official Languages Act in 1969, and continued work in federal politics to place French on an equal footing with English, and to prevent discrimination against the francophone majority in Quebec, the anglophone minority in Quebec, and the francophone minorities in other parts of Canada.
René Lévesque wound up in the middle. He felt that legislating the status of French was a display of weakness, and a humiliating admission of the continuing colonial status of Quebec propped up by francophone Quebecers' lack of self confidence. However, he also agreed that Bill 101 was necessary anyway, and assiduously defended the law as long as he lived.
The most visible results include packaging labelled in both languages (only since 1974 for food), mutual complaints about government activity favouring people whose first language is the other language, and in Quebec ongoing battles among the inheritors of Laurin's "French Only", a milder "French First" that was closely associated with Robert Bourassa, and a "French and English Equally First, the rest maybe where possible" among the inheritors of the Laurendeau-Dunton official bilingualism.
The middle group has held primacy in Quebec language politics since the 1980s, and thus you find yourself in a situation where (in Quebec) you have to put up signs in French, and you have to allow your employees and customers to communicate to
Ah, OK, I had to think about this a bit... please correct me if I'm still misunderstanding you.
I now think you were using a simile or making an analogy to argue that compilers can benefit from careful construction of loops in the source code.
If so, then of course I agree with you.
Saying this in a much more general way: careful choice of syntax can make the semantics more clear to the compiler.
A high level language with "dotimes (count) { action }" syntax lets the compiler make good choices about loop unrolling and the counter's type.
A language where you have to test and modify your own counter lets the writer make good or incredibly awful choices about loop unrolling and the counter's type.
This version:
foo() {
double d = 1.0;
int x=1;
while(d > 0) {
x = x << 1;
d -= 0.1;
}
return x; }
is semantic brain-damage on a system with very slow very IEEE doubles, and loop-unrolling this naively is not going to help.
A compiler which realizes that this is a loop whose length is constant can unroll the loop fully, partially, or simply use a better/faster iterator like an integer. But should we end up with 0x400 or 0x800?
Haha, now throw side-effecting at your smart compiler by inserting a debugging
printf("d: %G, x: %x\n", d, x);
into the while loop... how should it optimize that?
Anyway, I think we're not really disagreeing. You can write loops stupidly, whether they're iterative (as above) or whether they're recursive. A compiler probably can't save you if you are particularly stupid. It might even make things worse.
For what it's worth, when I say your sentence to myself, I want to make the like bold, I guess to emphasize the simile.
Slashdot Mirror
Well, no, the Prime Minister is mentioned and given a legal basis in the consolidated parts of the Constitution.
See ss. 35.1 and 49 of The Constitution Act, 1982, and ss. 130-131 of The Constitution Act, 1867.
Moreover, the constitutional role and office of the Prime Minister is well established (i.e., given a definition and legal basis) part of the governance of Canada through other statutes, proclamations, orders and traditions which are legally part of the (unconsolidated) Constitution of Canada.
Section III of The Constitution Act, 1867, describing the Executive, establishes the Queen's Privy Council for Canada. The Governor-General acts for the Queen on advice of this Council. Traditionally, the Council recommends the appointment of Ministers, including the Prime Minister. It is tradition which drives the composition of the Privy Council and its deference to the Prime Minister. This is fundamentally Responsible Government, which requires the Government to be responsible to the House of Commons.
The Privy Council itself has two traditions. Firstly, the Cabinet is a committee of the Privy Council. All Cabinet Ministers are Privy Councillors. Secondly, ordinary quorum for Orders-in-Council include the Governor General or her Deputy, the President of the Privy Council, another Cabinet Minister -- often the Prime Minister -- and the Clerk of the Privy Council (who may act as the Prime Minister's Deputy). Thus the full Privy Council will not "gang up" on the Government of the Day.
These traditions are part of the greater Constitution, which includes not only the statutory instruments listed in s 52(2) of the Constitution Act (1982), including all the acts listed in the Schedule, but also statutes, rulings, orders, proclamations and traditions "of Constitutional weight", such as the Royal Marriages Act (1772) or the fate of governments which cannot secure the confidence of the House of Commons. The fact that extant itemizations have always been non-exhaustive lists of items of Constitutional weight is made explicit by the Supreme Court in Reference re Secession of Quebec, (1998) 2 S.C.R. 217. This requires one of the Amendment procedures in the Constitution Act (1982) to be used to change important aspects of Canadian governance, and (maybe amusingly, in the case of keeping the monarchy Protestant) protects related pre-Confederation British Legislation from being challenged by the Canadian Charter of Rights and Freedoms.
Incidentally, this follows the pattern of the British Constitution, which is largely unconsolidated (and not entirely "codified" in the sense of being written down). The Acquis Communitaire is similarly mainly unconsolidated, although the European Union is considering a proposed "clean-up" of the Acquis and consolidation into a single Constitution most of the treaties, directives, orders and rulings of the European Union to date that are obviously of constitutional weight.
EULAs are not well-tested in English law, but it is established in Scottish law (Beta Computers (Europe) Ltd v Adobe Systems (Europe) Ltd, 1997, Outer House of the Court of Session). The Court of Session is influential upon English and Welsh courts, and the Beta decision is considered sound.
In general the argument would be that the item you are purchasing is a limited right to copy the software included in the package. Ordinariy the law of copyright would make you liable if you did so without explicit permission, or if you exceeded the terms of a limited licence.
All other rights are reserved to the copyright holder, and indeed, it is an asset which is depreciated.
Penrose, in the Beta decision, used the following logic: without a EULA, there exists NO licence for Adobe to copy the software onto its computers, and therefore no legal way for Adobe to use the software at all. Therefore the EULA must be part of the contract, and enforceable by both parties. (Adobe enforces its right to copy pursuant to the licence, Beta enforces the limits within the grant of those rights, consideration is based on this meeting of minds).
Untested in English law is exactly how this interacts with section 50(c) of the current Copyright Designs and Patents Act, inserted to comply with an EU directive, which grants some rights to make copies as necessary to make software usable. That is, this is a statutory right to copy versus statutory and common law rights reserved to the copyright holder. It is likely that an English court would expand upon Beta and suggest that 50(c) applies only in the case where a limited licence is acquired which does not include wording with respect to "copying" by dragging from one partition to another on the same system for use by the same user, or by "copying" by transferring in and out of memory or by "copying" to a general set of backups which happen to overlap the software in question. This would be consistent with a civil code reading of the directive.
The salient point would be whether the software itself was acquired, or whether the limited licence to copy data from a sold medium to a useful medium was acquired. In the former case, the statute should apply, but this would be inconsistent with the reality of the past decade in the software market.
You are probably right that the contract completes upon (or very nearly upon) the copying of the software into the buyer's system, and that the seller cannot impose further restrictions from that point, including limits of liability and other terms that would conflict with the Unfair Contract Terms Act and the Unfair Terms in Consumer Contract Regulations. However, prior to that completion, the buyer has the ability to reject the terms of the EULA and not exercise the licence. This would make him or her eligible for a refund from the seller.
A copy made for a third party after completion would certainly be a cause for action under copyright law. There is ample statute and common law in this area.
If EULAs are valid, and the EULA assigned rights to an agent to pursue such action under the Contracts (Rights of Third Parties) Act, a suit in England likely would be successful under both copyright law and contract law. The argument would turn around whether EULAs are valid in England, and likely would follow some of the logic in the Beta case from Scotland.
The 1952 Pharmaceutical Society of Great Britain v Boots Cash Chemists decision in England which established that the contract is concluded at point of sale is not conclusive in the area of limited grants to copy. A solicitor who insisted that it is, and that this invalidates EULAs not clearly and fully displayed at the the point of sale despite the obvious hazards to natural equity, is not one I would wish to do business with.
Well, he's right, cold medicines interfere with the immune response to a viral infection.
However, otherwise healthy people can trade off feeling miserable with a slightly slower actual recovery. Moreover, treating unpleasant symptoms can prevent serious complications.
The most unpleasant common cold symptoms are part of the immune response to the virus.
Fever interferes with viral replication.
Inflammation and localized edema (stuffy nose, swelling) reduces the transport of viral particles to uninfected cells while attracting and activating white blood cells.
Increased mucus production (runny nose, phlegm), sneezing and coughing carry virus particles out of the body.
Headaches and other pain both trigger and result from all of the above.
A typical cold preparation contains: ASA (aspirin), acetaminophen (paracetamol), ibuprofen or some other pain-reliever; a pseudoephedrine salt or other decongestant; and possibly a cough suppressant or antihistamine.
The combination of these medicines remove large physical obstacles to infection.
In particular, medicines that reduce pain and swelling also consequently reduce the incidence of contact of white blood cells with infected cells. WBCs (macrophages, polymorphonuclear leukocytes) are phagocytes -- cell eaters -- they literally poison, envelop and digest infected cells to prevent them being used as virus-reproduction factories. This is also called antibody-mediated cellular cytotoxicity (AMCC or ADCC), and it is a human body's principal mechanism for dealing with viral infections.
AMCC is particularly effective when the viral infection is contained to a small volume of cells readily filled by lymph. Swelling, itching, and pain are side-effects of the containment and WBCs being transported in by lymph. Fever, runny nose, coughing, sneezing and watery eyes keep the virus from spreading especially to tissues which are less accessible to or more sensitive to AMCC. Even more importantly, they make it harder for other infections (bacteria, for example) to take hold as well.
Cold medicines may promote a simple viral infection into a serious disease.
On the other hand, high fever, widespread inflammation edema, constant coughing or totally blocked nose can dangerous. Faced with a serious flu -- these typically provoke a cytokine inflammatory response in the victim -- the downside risks of using cold medicines (especially anti-fever and anti-swelling drugs) are smaller than not interfering with immune responses which cause actual trauma. Modern cold medicines likely would have saved millions of lives in 1918.
However, much more commonly, cold medicines simply make the user much less miserable for the few days the viral infection lasts.
Pseudoephedrine salts are also regularly taken by people with recurring acute sinusitis. These people usually have an allergy to something nearly impossible to eliminate from the environment (dust mites, for example) and are prone to paranasal swelling. The swelling itself hurts, and also may cut off airflow between the paranasal sinuses and the outside of the body, leading to pressure differences that cause tissue stress and trauma inside the sinuses (and thus more pain and swelling). The pain can be excruciating and resilient against non-opiod pain relievers.
Worse, the lack of sinus drainage and the trauma to the sinus tissues encourage secondary infections of the sinuses and inside of the head, some of which can be extremely dangerous, as well as bronchitis and pneumonia.
Nasal decongestants -- particularly pseudoephedrine -- can prevent the initial swelling, terminate the vicious circle of an acute sinus attack, and are generally safer and more focused than aspirin, acetaminophen or other pain relievers or anti-inflammatory drugs, especially ones which contain opioids like codeine, hydrocodone or oxycodone.
The minor interference with the immune system by sinus sufferers using pseudoephedrine is alm
The Fischer-Tropsch process was not invented by the Nazis.
Franz Fischer and Hans Tropsch invented their process in the 1920s, while working for the Kaiser Wilhelm Institute for Coal Research.
Fischer died in 1932, before the Nazis came to power. Tropsch, a Czech, died in 1935, before the passage of e.g. the Nuremburg Laws and years before the Nazi occupation of the Czech lands.
In the 1920s, pre-Nazi Germany had lots of coal and practically no petroleum. Oil imports were expensive well before the Nazis. Processes to use coal as a fuel for small vehicles were an obvious and important area of research in Germany, even without war being a factor.
The President of the Commission is nominated by the Council of the European Union, which comprises the 25 member states, represented by the elected government of the day in each country. The directly elected European Parliament must approve the Council's nomination.
The remaining Commissioners are selected by the Council and the confirmed President jointly.
Consensus politics has led to a convention wherein the Council is expected to propose a Commission with a Commissioner from each member-state, prepared to act in the interests of the European Union as a whole, and to act as a counter-weight to the governments of the day in each member-state as necessary. In particular, Commissioners are not supposed to take directions from the indivual member-states, especially not the ones from which they hail.
This results in the Commissioners from each member-state generally being people who have been in the leadership of an opposition or minority party, rather than the party of the government. Often this means "reject" politicians from a previous government.
However, the Commission is not self-selecting. It is selected by elected government officials in each member-state.
As to accountability, the Commission is responsible to the European Parliament.
A newly nominated Commission must be approved by the directly-elected European Parliament before its term can begin. The Parliament may withhold approval for whatever reason it wishes, and it has done so on a temporary basis at least twice.
The current Baroso Commission faced weeks of delay in confirmation by the Parliament, which insisited on changes to the proposed Commission. Those changes were made. In particular, Rocco Buttiglione and Ingrida Urde did not become Commissioners, and Laszlo Kovacs was moved to a different position (taxation and customs instead of energy).
The Commission can be removed as a whole by a 2/3 vote in the Parliament. This has been threatened a number of times.
The Parliament further asserts that it can remove individual Commissioners, however this has never been tested. The Santer Commission resigned in its entirety before the Parliament was able to agree on whether it could insist on the removal of Edith Cresson (then the Commissioner for Research, Science and Technology) on the grounds of fraud and corruption.
The Treaty Establishing a Constitution for Europe tweaks all of the above somewhat, increasing the relative power of the European Parliament. In particular, the Parliament is given clear and final approval and removal rights over each of the individual members of the Commission including the President; the Council must take into consideration the results of European Parliamentary elections when proposing a President; and the Parliament would become equal to the Council with respect to initiating legislation and giving direction to the Commission.
Whether and how the TCE will be established is uncertain at best, however it is clear that power is accreting in the directly elected European Parliament, and that it represents the best hope of removing both the real and perceived democratic deficit in the European Union. (MEPs are not uniformly good at being visibly democratic politicians, however...)
Liberty needs you too, Kraut.
Oops, eu are right, I made an edit-o. :(
"The US way" (never mind that the pattern is just as likely to be used by large Swiss or Danish pharma companies as American ones) will run into the problem that there is a lot of similar work covered by patents in countries which have recently become full members of WIPO (and the European Union too) and thus by treaty have prior claim to patent protection in the USA.
However, actually engineering a better delivery mechanism or greater effectiveness could be extremely useful, whether it is promoted by or simply allowed by "the US way".
Your "clusterbomb" suggestion has two problems in that if the phage therapy is used to attack and an E. coli strain in the gut and get it to produce a bunch of antibiotic prior to being lyse, there is a risk that the antibiotic will kill the attacked bacteria before it explodes and releases copies of the bacteriophage (so, the antibiotic merely reduces the effectiveness of the virus and nothing else), or it will introduce tiny amounts of wide-spectrum antibiotic to succeptible microbes also in the gut (so, the antibiotic serves as a tiny selection pressure in favour of resistant genotypes).
Maybe a neater idea would be to manipulate the viral DNA to have it code a mutagen that affects the viral DNA itself in a way that encourages parallel evolution with surviving target bacteria, and another "edit" which makes the virus itself more susceptible to ex vivo conditions to limit its spread in the wild. (The latter seems like a very Monsanto thing to do...)
"Phage" is Greek for "eater". "Bacteriophage" is a virus that attacks bacteria.
Viruses are almost always entirely species specific, mostly because they rely upon the structure of the cells they attack. The structures can include any of the cellular membrane or cell wall, the various DNA transcriptase and polymerase enzymes and the nuclear or chromosomal DNA itself. Bacteria are simple eukaryotic organisms so lack a number of other structures that can be abused by viruses and virus-like agents, and consequently bacteriophages are relatively simple DNA viruses.
Bacteriophages are extremely common, particularly in bacteria-rich open water, especially in plankton-rich parts of the oceans, where there can be much more than 1E10 viruses per litre.
A typical human being will encounter billions of viruses a day, almost none of which will challenge the active immune system -- most will be blocked by the passive systems (the skin, the mucus membranes...).
Bacteriophage therapy bypasses the passive membranes entirely via direct application to an infected wound or by intravenous injection. Since the applied or carefully injected viruses are monoculture and highly species-specific, they do not challenge the body's primary immune response mechanisms except to the extent that any foreign protein in the blood would in dilute amounts.
The important consideration is that the rapidly-responding innate immune system is unlikely to challenge an injected bacteriophage. The viruses cannot infect the host cells and consequently do not distress tissues (danger model and simple phagocyte chemotaxis) and are unlikely to be associated with TLRs in the innate immune system, or even encounter NODs (PAMP/PRR model).
The adaptive immune system is much slower, which is why people are ill for several days when infected with a new pathogen. It essentially exists to memorize successful attacks against serious infectious diseases the host survives, so as to mitigate or prevent future infections by the same (or very similar) microbe.
The plausible risks to the therapeutic bacteriophage itself when introduced into a human being with a normal immune system are mainly that the human's fever and swelling responses triggered by the bacterial infection physically keep the viruses from infecting their target bacteria, or that the human had tissue insulted by a highly similar virus (improperly injected such that it remained at high concentration, perhaps) at some time in the past.
However, the amount of virus to be injected is tunable, and it is much more likely that in the short term the bacteriophages will find, attack and kill most of its target bacteria than they will be wiped out by the patient's immune system.
The major practical problems with bacteriophage therapy is that they are like very narrow-spectrum antibiotics. You need to culture the bacteria in vitro and check its susceptibility to specific virus strains, which can take a full day or more. Moreover, if there are multiple strains of infective bacteria, you can "miss" with the culturing and only partially treat the patient. The time and possibility of "misses" going undetected for a while account for the popularity of wide-spectrum antibiotics.
Unfortunately, wide-spectrum antibiotics are an evolutionary selection pressure on microbes succeptible to them... those that aren't killed because of some inheritable trait are likely to pass that trait onto their offspring. Staph. aureus, a common skin-infection bacterium, is particularly good at this, and there are strains which are resistant to very strong wide-spectrum antibiotics and even some semi-wide-spectrum ones targetting gram-positive bacteria like methicillin and vancomycin -- these are the frightening MRSA and VRSA "superbugs".
The scary thing is that Staph. aureus bacteria are often not the bacteria being treated with wide-spectrum antibiotics like penicillin, so they are overlooked. Survivors may pass on resistance.
Very narrow-spectr
Precisely, thus the multi-SPU pipeline approach.
This type of application is written as a pipeline anyway, QuickTime et al simply favour that programming model, and coincidentally benefit from spreading pipeline stages across multiple processors on a system that has them.
The EID is much much faster than main memory, and the Cell's internal mailboxes are much quicker synchronizers than any multiprocessor approach.
So, for pipelines dominated by floating point work, Cell is a winner.
Single-Cell systems would be cheaper than extant hardware solutions (single G5 Mac + Enigma or Altair for example). Sure, an ASIC or FPGA approach is thinkable, but not with the combination of cost and flexibility that a Cell system could. For that matter, a quad G5 system often outperforms extant hardware approaches, even though it has less than half the vector processors of a single Cell.
Huh?
...
Computation depends on the number of pixels. More pixels, more computation. More pixels in a given unit of time, more computation in that unit of time. Pixels over time is bandwidth or, alternatively, bitrate.
HD is lots of pixels per second and a typical source is lots of bits per pixel... mutating all the pixels in a frame is not computationallly free, and if you have timing requirements, this is important.
I don't see where memcpy cost comes into it. The dominant cost is e.g. the gamma function against every 24 bpp datum, or a 2D-FIR scale across every frame or field.
Memory can be a bottleneck, but that's feeding data into the floating-point processors... The idea is to avoid constantly blowing caches by either:
[possibly keeping code in cache, probably thrashing field data]
- process field through mutation algorithm A (run to completion)
- process field through mutation algorithm B (rtc)
- process field through mutation algorithm C (rtc)
- next field
[possibly thrashing code, probably not thrashing field data]
- process pixel through mutation algorithm A
- process pixel through mutation algorithm B
- process pixel through mutation algorithm C
- next pixel
It's likely you have to have some of the first approach if you take the second; some operations are going to work on full fields or frames.
A pipeline lets you do this if you have multiple processing units:
[on processor 1]
- read pixel from source
- process pixel through mutation algorithm A
- write pixel to proc 2
[on processor 2]
- read pixels from proc 1, assemble field
- process field through mutation algorithm B (rtc)
- write pixels to proc 3
[on processor 3]
- read pixels from proc 2
- process field through mutation algorithm C
- write pixels
The Cell's SPUs are well-suited to this type of small program, and tends to favour small rtc algorithms.
You can do this with multiple standard processors too, but the "write to proc N+1" "read from proc N" pairs are likely to be much slower than SPU->SPU communication which benefits from the extremely fast EID.
Finally, for completeness, you can do it with one standard processor as well, although then overhead of what is ultimately a threaded/distributed functional programming style will be a performance drawback compared to a non-threaded monolithic style.
Today's broadcast media (ATSC) are typically CBR anyway...
I think (and this is because of your reference to "Xvid, lavc, etc") that we are discussing totally different markets. My point is not that Cell is a good fit for Apple's mass market segments comprising home and casual hobbyist users.
I am suggesting that the Cell would be good for very high-end Apple customers processing HD "live" in the truck. The sort of people who have teams doing NLEs to allow for instant replays and the like, for full HDTV broadcast.
Organizations like Molinare for example, not people at home ripping DVDs into CD-sized mpeg4s.
That particular application would benefit from Cell precisely because the source and destination format bitrates are so high that cropping, scaling, gamma-correction and the like do use noticeable computation, enough to pose the risk of a delivery delay unacceptable to in-the-truck broadcasters' customers.
Incidentally, the formats being handled are HDV and MPEG2 at various bitrates. MPEG2 as a source format is laid out in GOPs; MPEG2 as a destination format has predictable (even settable) GOP layouts and settable data rates. Parallelization by GOP is precisely what happens in this type of application, whether it's done in a multiprocessor/multisystem rack or using multichip hardware compression engines.
However, in Moliere's workflow and any other Apple-using software-only setup, parallelization is mostly to access the Velocity Engines for floating point performance, and the overhead for this is high (network driver code on both machines, time on network, synchronization code) and for applications which parallelize over 4 dual core G5 XServes for access to their Velocity Engines, the Cell would eliminate the first of these two overheads entirely, and dramatically simplify the last.
When the target is HD and SD broadcast you benefit from parallel compression as I outlined. Yes, you can also benefit from this for delivery to other media (DVD, HD-DVD/Blu-Ray eventually, or even a video iPod compatible mpeg4) however most high-end customers know that offline formats don't need massive parallelization in the final preparation, just as you do.
In short, the mass market does less-time-sensitive workflows that would like to reduce (but are tolerant of) slow (or even no) NLE, and can wait hours for delivery of edited source material to non-broadcast formats.
Higher end customers want quicker NLE because they are paying professional editors and have budgets for expensive equipment. Those that are working on recorded content to be delivered at a particular time (film release date, TV show air date) are the customers that Cell would attract.
Moreover, video is not the only obvious high-end application as far as Apple's serious pro customers go -- almost every application listed in Apple's Pro (UK) page is heavily floating-point dependent and uses SIMD parallelization already. Several would benefit from the massive floating point performance available with the Cell architecture -- essentially the Cell would bring a greater than 4x increase in available Velocity Engine power per system compared to systems using G5s.
However, it's not clear that Cell would scale as well as denser and denser G5 systems for the ultra high end applications because the control logic for massive parallelization (especially just sourcing and sinking the data) could begin to push at the PPEs limitations compared to those of the G5's PPC core, or might wind up being called upon to do much more non-floating-point computation at some point in the future. Therefore, the larger cluster applications listed at Apple's (US) Pro page might not be suitable for the Cell. However, as with the UK page, many are.
So, there is a clear and profitable market segment that would benefit from the Cell enough to buy new Cell-based Macs. Whether that segment could pay for the software and hardware d
I wasn't proposing threading or parallizing in the video compression case, I was proposing streaming. This eliminates the overhead of context switching and the continual setup of the SIMD code of each stage of the stream within the PPE program itself. This trade-off involves the use of the Core architecture's mailboxes, which is mostly a SMOP.
... | compress | dd of=video.mp4
You could think of this as if it were a UNIX pipeline:
cat video.mp2 | decompress | crop | scale |
where each process runs on its own processor, and the bandwidth through the pipes is very large.
Some of the CPUs will block waiting on the compress stage. That happens in reality, both in the heavyweight and lwp/thread models which exist today. However they are blocking/running/unblocking without taking away processor time from the compress stage, and that is likely to be a significant and noticeable improvement in overall workflow throughput.
Video processing often *is* highly amenable to parallel processing: the coordinating process ships off a discrete chunk of video -- a GOP perhaps, or a chapter -- and gets back a compressed version at some point in the future.
Finally there is a per-frame parallelization in a streaming approach that can *help* with quality, notably exhaustively searching fullpixel motion estimation in the compression stage is likely to be made quicker by doing different algorithms on different SPUs in parallel, and discarding the lower-quality results returned from them.
The multi-SPU large model programming model IBM likes to talk about is amenable to that sort of branch-and-prune streaming approach, which is useful in a number of floating-point intensive workflows. Video is one of them, obviously, but not just as the equivalent of GPU-style shader engines. (On the other hand, you could think of it as exactly the equivalent of GPU-style shader engines with output going to a file rather than to a screen -- and in that sense, Cell would be competing with a graphics subsystem that can *compress* to H.264 et al rather than just accelerate the decompression and display of them).
Never mind using the Cell's SPUs as shader engines -- your GPU will do that job just fine. What you want the SPU for is any streaming single-precision floating point workflow with multiple stages or parallel streams. The throughput ought to be much better on Cell than other high-end processor architectures, leading to an earlier finish of such a workflow. Time is money.
One obvious application is rendering and compressing. The Cell will let you pass the output of one SPU's miniprogram to the input of another's, so you can have the SPE process I/O and feed raw data in and out of a bunch of SPUs it sets up to cook the data. A set of SPUs can do the cropping, scaling, static denoise, temporal denoise, gamma adjustment and compression while another set of SPUs can adjust audio volume, dynamic range and compression. This approach would blow the socks off a fast standard core + single SIMD engine. A dual core on the same die would give a speedup of course, but given the heavy streaming floating-point activity the second PPE-equivalent might not be helpful compared to the second SIMD engine, and here you have two and not eight as in the Core. A multi-die solution giving 8 SIMD engines (and 8 cores) by comparison pushes at the limits of inter-package and memory bandwidths -- the Core's EID interconnect is amazingly fast.
Lots of Apple's pro apps (Final Cut et al, Logic et al) are used by people with workloads that would benefit from the Cell architecture by finishing a particular job earlier than on a multi-PPC or multi-Intel system. The two-issue/dual-thread in-order restrictions on the PPE won't be a problem for apps compiled and scheduled for the Cell -- Universal Binaries and gcc 4.0.1's Apple-specific -fast flags can do this easily.
Meanwhile, code built for Motorola G3s, Moto/Freescale G4s and IBM G5s (including VMX/Velocity Engine code) will run on the Cell's PPE without recompilation, but not as quickly as code explicitly (re)built for the Cell. Whether it would be *too* slow is an interesting question.
In principle, system performance on dedicated-use media processing workstations built around the Cell would be somewhere between fine and exceptional depending on how much the code relied upon VMX (aka Velocity Engine or Altivec). Worst case performance would occur when running lots of applications scheduled on much older PPC implementations, so simply booting a disk filled with apps built years ago would be the least optimal (but still working) start to a Cell system.
Slow but essentially full backwards compatibility is possibly a curse rather than a useful feature. It was for Itanium. Some of that is that most of the pressure to supply a processor-specific optimization of an application that works on the new processor is removed.
Apple is relying upon software ISA-to-ISA translation on the new Intel Core Duo systems, and the Cell likely would in all cases outperform Rosetta-on-Core-Duo in terms of speed and moreso in terms of running SIMD code, and compatibility issues like giving non-garbage results to exception routines...
A recompile into a Universal Binary probably would give the advantage back to an Intel Core Duo over a single Cell especially for multi-threaded apps using little SIMD. Heavily SIMD-using code would likely favour the Cell even if only the PPE's VMX was being used. The Cell would almost certainly beat the Core Duo for all tasks dominated by floating point operations, provided those operations were performed by the SPUs.
If Apple ever seriously considered the Cell architecture for market segments that do lots of real work dominated by floating point performance, it would be pretty clear that a smart thing to do would be to have most of the floating point code be hidden in Apple-supplied frameworks (libraries) tuned for particular processor implementations (e.g. the Core Duo, PPC 970 and Cell). Mac OS X already mostly does this with (among others) its Accelerate, QuickTime and Core* frameworks.
The
I don't think your concerns about the Cell are really applicable.
The Cell is a combination of an ordinary PowerPC (called the PPE) and eight floating-point vector processors (called the SPEs), interconnect and peripheral logic, on a single die.
The PPE (Power Processing Element) will have the standard 970 instruction set including the powerpc-gpopt and powerpc-gfxopt operands. It's a two-thread dual-issue 64-bit general purpose processor that will work pretty much exactly like the 970s in Apple's G5 systems. It has a shortened pipeline which favours well-optimized code (you could think of this as penalizing poorly-optimized code, too). It has a small 16kB L1 cache and a 512kB L2 cache, but can use the high-speed interconnect (EIB) to talk to other local memories. Moreover, it has a standard VMX vector engine (which Apple calls the Velocity Engine and most people call Altivec).
The PPE on its own would be a decent G5 system for running code built with the "-fast" flag in Apple's XCode-bundled gcc 4.0.1 and with standard Velocity Engine acceleration code. Most of the computation workhorse frameworks (QuickTime et al) ought to work well when compiled for this particular target. Fat (er, Universal) binary support could do this trivially.
On its own the PPE should be competitive with a single-core PPC 970 (Apple G5) for most of the uses one would make of a single-processor Mac. There is no reason why one could not use multiple Cell packages in a system, along the lines of the dual G5 systems. However, the dual-G5 packages (especially the quad G5 systems) ought to outperform PPE on code that is principally unvectorized G5 and VMX tasks.
That said, the 8 SPEs one gets on top of the VMX open up a new world.
The Synergistic Processing Elements (SPEs) could be looked at and programmed as if they were additional VMX units requiring a preamble and postamble when invoking a vectorized subroutine. Because of the overhead of uploading code to the SPE and syn chronizing between the SPE and PPE, the SPEs are more suited to processing large data blocks. This model would let the PPE (and VMX) focus on other tasks while a large data set mutation was being processed by an SPE.
Another approach would be to stream data through an SPE: the preamble would upload a small program (like a tiny operating system) into an SPE, which would then iterate over datasets as they became available. The PPE would notify the SPE when new data becomes available, and the SPE would notify the PPE when its processing finishes.
SPEs can also notify each other, so one could mix both of the above models, with some SPEs being notified by others (in a chain, most likely), and some being notified by the PPE.
IBM has an online overview of the SPE programming models (see towards the middle of the article).
In a Mac OS X environment, substituting SPE programs for Velocity Engine subroutines would be a SMOP for developers used to Velocity Engine programming. If anything, this is already becoming easier with the migration support for Intel's SSE3.
The Cell would be a good fit for an Apple workstation used for media processing tasks, especially processing video (NLE, rendering, transcoding, compressing). Chaining together several image mutating SPE-based programs in a large multi-SSE model would be a much higher throughput approach than current unvectorized-G5+VMX threads.
The Cell would also be a good fit for scientific programming that leans heavily on double-precision floating point. There is a large hit for using doubles instead of single precision in the SPEs, however they are both fast and numerous, and would work well for parallelizable tasks.
In single precision and in parallel the SPEs look a little like shader engines on modern 3D graphics cards.
The question you raise is whether general purpose computation-intensive code that was not opt
Directives come from the Council of the European Commission, which comprises every member state in the European Union. Typically a member state is represented by its head of government or a representative -- often a minister or a civil servant directly reporting to a minister.
The government of the moment of each and every EU country therefore is directly involved in originating directives of this nature. Each EU government is popularly and democratically elected.
Every directive must be reviewed and approved by the European Parliament, whose members are popularly elected directly by EU nationals.
The European Commission is also involved. Commissioners are appointed by the Council and approved the Parliament, and are collectively responsible to both bodies, either of which unilaterally may force the entire set of Commissioners out of office.
The Commission's role is typically advising the Council (sometimes making suggestions on directives to initiate, much more often providing technical and legal advice for whatever the Council cooks up on its own) through the legislative process, as well as trying to resolve any conflict between the Parliament and the Council when the former does not approve an initiative of the latter.
In any event, the Commission oversees the implementation of any directive finally agreed between the other two institutions, and may bring pressure to bear on members states which implement things the wrong way.
The defeated Constitution would have given more power to the Parliament to act as a check against the member states, on the grounds that MEPs are directly elected, represent finer-grained constituencies, and frequently are members of non-government parties (who have no direct say in the Council). The weakness of the Commission, where retired senior "opposition" politicians were the most common form of Commissioner suggested by each member state, was one reason. Another was the increasing tendency of several member state governments to run their local agenda through the existing process and then blame "Europe" for the results of their very own efforts in the Council. Finally, the hope was that a much stronger (as in more able to block the actions of the Council and review and repudiate the Commission) directly elected Parliament would solve some of the "democratic deficit" public relations disaster which has plagued the European Union.
This may be a case where Finland is blaming outside forces to disguise local politicians' pet projects. That this is both possible and plausible is what I think the greatest democratic deficit is: non-transparency.
Unfortunately, most of the other member states use the same tactic with some regularity and are unlikely to rebuke Finland for blaming the EU in general for something that none of its three institutions really approved.
Sadly, there are national polticians in every country who simply enjoy manipulating people into believing that it's all "Europe"'s fault when they decide themselves to do something unpopular.
But it works badly when lots of clients observe packet loss. The worst case is if you have many many clients listening to a multicast source, and there is loss on the line between the source and its ISP. The source might be drowned in retransmit requests, much like in a DDOS attack.
Carousels are fine and dandy, but if you have missed just one chunk of a large file, you may have a long wait, and lots of bandwidth wasted by sitting on the multicast stream until the repeat. Scheduled rebroadcasts are an optimization: if you know when your missed piece is going to be rebroadcast, you can unsubscribe until a little before that time, so you don't have to receive all the bits you already have.
However, odds are that for any reasonably large file, you will be better off finding another client who did receive your missing bits, and retrieving them from it, than waiting for the "rerun" transmission.
If there are large numbers of clients, this operation could be very expensive for the tracker.
The other consideration with this approach, unfortunately, is that there is a serious mismatch between the rate at which the fastest-connected and slowest-connected clients can absorb the multicast traffic. If the source transmits at, say, 2Mbps, there will be about 50% packet loss observed by people with 1Mbps (down) DSL connections, with worse losses as you decrease the last-hop down bandwidth. The loss doesn't really matter to the source (there is no direct feedback), but you aren't going to make up for massive losses efficiently by repeating a multicast stream for the benefit of the clients observing the worst loss.
This is where the P2P+unicast-TCP distribution system can demonstrate its strength, if the P2P overlay routing system could take link/pair performance into account.
If that were the case, the apparent optimization of allowing fast/low-loss downloaders to receive file parts at high speed via multicast, would look less attractive than the current system where fast/low-loss downloaders may find themselves taking parts of files from dial-up users. Investing time in a fix for that kind of pessimal behaviour is a good idea, and probably more productive within the unicast-P2P framework than in working out a parallel multicast mechanism, not least because multicast is not widely available even to DSL-connected clients.
Some do. Ask yours. There are two principal availability models for native multicast that I know of. Both require asking your ISP to talk sparse-mode PIM and to exchange multicast NLRI with you via BGP. At least one large scale provider charges a nominal fee for doing this at all, at and least one large scale provider does this for free but caps the amount of multicast traffic you can send without making an extra arrangement.
The principal problems with multicast are operational (not many people know how to set up and debug it, although Sprint's mulitcast pages are an OK start. However, IP multicast is only reasonably scalable when you restrict yourself to single-source trees, but on the other hand SSM (with PIM-SM and BGP) is coincidentally the least operationally difficult approach.
The main engineering problem is that you inevitably create state in routers for each source that is being listened to (you can optimize out state for silent and unsubscribed sources) in all the routers from the source to each destination. In practice there is "collateral damage" state in most routers in a network in between sources and subscribers. This is cut down somewhat by using Rendezvous Points and distributing those using anycast and MSDP, which moves work from border and intermediate routeers into the RPs. This works well, but incurs a cost which increases as multicast traffic increases. (Essentially, you can drown your RP with traffic. You can distribute RP work, but that then increases control traffic on the routing or source-discovery planes, and there will be some limit.)
In short, the model which scales well enough to make multicast essentially "free" beyond the cost of IP connectivity, is limited by the number of multicast transmitters. The number of subscribers is barely a concern, and the sender's bandwidth is unlikely to pose an engineering issue at any speed less than a gigabit per second.
Making material with lots of FEC or which is loss-tolerant available via SSM is cheap and easy. An obvious application would be live TV content, and that could take advantage of multiple parallel groups -- clients would "slow start" by subscribing to a low-bandwidth stream, then graduate to other (or more) streams if reception works well. Likewise, if whatever stream they are subscribed suffers from too packet loss, the source can unsubscribe it and use a lower-bandwidth/lower-quality one instead.
From the originator's perspective, this is exceptionally easy: originator announces the sources and just blast multicast packets out to its ISP. The ISP will simply drop any traffic in groups that aren't subscribed-to by someone. The originator is thus limited by the bandwidth out to the provider, and nothing else.
If the originator has loss-tolerant content to begin with, or a loss-tolerant encoding (with lots of forward-error-correction or redundancy for example), the originator doesn't even have to cope with network losses. This means the audience can be *huge*.
A file distribution model is plausible using this type of system... you would just "build in" the retransmissions that inevitably would be required because of network losses. The problem is in feedback: you probably don't want to transmit if there are no listeners; you probably want to transmit at about the greatest minimum speed at which there is no congestion-related loss observed by your subscribers; you probably want to tune your retransmissions/redundant transmissions based on client needs. All of this requires a communication from receivers back to the source.
If there are lots and lots of receivers, you risk drowning the source in feedback.
If there are very few receivers, then this is a very heavyweight mechanism for sending data to them. Moreover, if the receivers can also be transmitters, you will get better performance by ha
Have you ever been to Washington, D.C., the capital of the world's richest country? The District's streets are barely paved at all!
Whole busses get lost in the potholes, you know.
CIRUS, the Indian reactor in quesiton, was based on the NRX design. While it's a heavy-water-moderated/light-water-cooled design, it significantly predates CANDU. The latter is geared towards use in a nuclear power plant; NRX is geared towards materials testing, isotope production, and physics research. It is not especially better than any other research reactor at breeding isotopes -- it just that it trades off a need for (expensive) reactor grade heavy water against ordinary industrial production of the core. Other designs typically need a much much hotter and/or highly pressurized core, requiring heavy industrial processes which are harder and much more expensive.
Although the overall design was very similar NRX, and the C in CIRUS is for Canada, the "US" is there for a reason: the U.S. government provided the financing and the reactor grade heavy water to the project.
Certainly NRX, like many early reactor designes, can be coaxed into breeding weapons materials. There are even some aspects that make it easier, notably the on-line-adjustable pile and the facilities for irradiating test materials.
From a legal perspective, NRX wasn't covered by nonproliferation rules or under IAEA safeguards, mostly because most of those did not exist at the time of the sale of the relevant designs and components. Both C & US stipulated or had contract terms requiring that CIRUS be used only for peaceful purposes. India violated these terms, and both of the other parties cut off nuclear research ties for decades as a result.
Breeding, yes... they needed a source of neutrons to bombard 238U. A 238U atom occasionally captures a neutron, becomes 239U, which decays into 239Np which decays into 239Pu.
238U much more readily captures a fast neutron than a slow one. Fast neutrons are emitted by Uranium fission. A moderator turns a fast neutron into a slow one. NRX, since it uses nearly pure heavy water as a neutron moderator, supplied slow neutrons efficiently. There are much more efficient designs if the goal is to produce lots of fast neutrons in order to breed plutonium from 238U, rather than lots of slow neutrons in order to sustain a uranium fission chain reaction.
In 1960, when the reactor was first turned on, the idea of using CIRUS as the basis of a nuclear weapons program was possibly genuinely surprising. I honestly don't know. However, it did take 14 years to go from activation of CIRUS to India's first nuclear weapons test. However in retrospect, with today's knowledge, the proliferation risk would be obvious.
The important quality of nuclear weapons material is not that it is spontaneously fissile, but rather that a small mass of it compressed into a small volume of space can sustain a highly energetic nuclear chain reaction.
I don't agree with the "victim" mentality so common among the péquistes, however it might help to remember that there certainly was much worse in the years before la revolution tranquille of the late 60s and early 70s.
In the early 60s and before, in any sizable company in Montreal and Quebec City, and in any white-collar position at all, the working language was almost inevitably expected to be English. It wasn't just that an office full of francophones would be expected to accomodate a single anglophone when speaking with him (hey, not many "hers" in these situations back then), or in meetings where the anglophone was present, but even when discussing things amongst themselves. A watercooler discussion in French was grounds for termination -- you could get fired for speaking your own language together.
In large department stores in Montreal and Quebec City, you'd see English-only signs. Staff were taught to greet people in English, and to use English preferentially with customers who could speak either language. As in the case in many offices, no personal discussions in French would be allowed, or you'd be fired.
There was real oppression in the workplace -- it wasn't just a case of possible bias like thinking that maybe a francophone might be a little more bilingual than an anglophone and thus more suitable for a government job if all other qualifications were equal, it was: Speak English Or You're Fired.
"Maîtres chez nous" -- masters in our own home -- was one of the reactions to the social changes of the 60s. Many people took the view that the workplace language rules were not only oppressive, but they effectively enslaved francophone Quebecers, often at the hands of business owners and managers with no personal connection to Quebec beyond responsibility for the office, plant, branch, or facility in the province. Practically everyone who saw the situation as unfair wanted either to end the unfairness, or to outright turn the tables on the oppressors.
Camille Laurin ended up in the second group -- the revolutionaries -- and he ended up being the guiding force behind what in English is called Bill 101, which established French as the sole official language in Quebec.
Another group ended up supporting the recommendations of the Laurendeau-Dunton report (Royal Commission on Bilingualism and Biculturalism), many of which were championed by Pierre Trudeau, who introduced the Official Languages Act in 1969, and continued work in federal politics to place French on an equal footing with English, and to prevent discrimination against the francophone majority in Quebec, the anglophone minority in Quebec, and the francophone minorities in other parts of Canada.
René Lévesque wound up in the middle. He felt that legislating the status of French was a display of weakness, and a humiliating admission of the continuing colonial status of Quebec propped up by francophone Quebecers' lack of self confidence. However, he also agreed that Bill 101 was necessary anyway, and assiduously defended the law as long as he lived.
The most visible results include packaging labelled in both languages (only since 1974 for food), mutual complaints about government activity favouring people whose first language is the other language, and in Quebec ongoing battles among the inheritors of Laurin's "French Only", a milder "French First" that was closely associated with Robert Bourassa, and a "French and English Equally First, the rest maybe where possible" among the inheritors of the Laurendeau-Dunton official bilingualism.
The middle group has held primacy in Quebec language politics since the 1980s, and thus you find yourself in a situation where (in Quebec) you have to put up signs in French, and you have to allow your employees and customers to communicate to
Yes! Centred right on the Apple!
Maybe he claims this, but we can't be certain.
Yes :-)
I now think you were using a simile or making an analogy to argue that compilers can benefit from careful construction of loops in the source code.
If so, then of course I agree with you.
Saying this in a much more general way: careful choice of syntax can make the semantics more clear to the compiler.
A high level language with "dotimes (count) { action }" syntax lets the compiler make good choices about loop unrolling and the counter's type.
A language where you have to test and modify your own counter lets the writer make good or incredibly awful choices about loop unrolling and the counter's type.
This version:is semantic brain-damage on a system with very slow very IEEE doubles, and loop-unrolling this naively is not going to help.
A compiler which realizes that this is a loop whose length is constant can unroll the loop fully, partially, or simply use a better/faster iterator like an integer. But should we end up with 0x400 or 0x800?
Haha, now throw side-effecting at your smart compiler by
inserting a debugging into the while loop
Anyway, I think we're not really disagreeing. You can write loops stupidly, whether they're iterative (as above) or whether they're recursive. A compiler probably can't save you if you are particularly stupid. It might even make things worse.
For what it's worth, when I say your sentence to myself, I want to make the like bold, I guess to emphasize the simile.