Now I think Rambus is getting a lot of unnecessary bad press. I think Tom's reviews are a little narrow minded, not to mention Tom has always been a little hot headed ( I can recall an incident or two when he was in a pissing contest with some other news boards. And I recall him having to appologize for some non-professional letters ). All in all, I like his site, but I take this sort of criticizm ( also remembering a complete emotional rejection of 3Dfx ) with a grain of salt. Point one. Intel has had a very long term strategy ever since the Pentium Pro. A simple fact is that the longer a CPU pipeline is, the more efficiently you can crunch numbers. The only other alternative is to make redundant CPU components and a seriously more complex internal bus ( you'd have to have more parallel ports to the register set, plus more complex scheduling ). Where-as, if you had to perfect 50 independant calculations, and you had 50 fully pipelined stages, you could chuck out an instruction/ clock. And at 1,500MHZ, that's pretty fscking sweet. This is completely the path of the Alpha chip. You get a hell of a lot more bang for your buck, since it takes a tiny bit more silicon to add an additional stage ( buffer plus redundant operations ), while a parallel stage requires 100% redundancy of functional unit plus additional bus interconnections a deeper, more complex and less efficient scheduler and a heavier load on the register set ( all of which degrade overall performance unless you can achieve a decent instruction level parallelism ). Unfortuntaly, pipelining has it's own can of worms. First of all data-dependancy can really kill you if the pipe is too deep. Secondly, you need higher speeds to achieve the same throughput as a wider CPU. ( 750MHZ single but deep pipeline CPU should be similar to a 500MHZ short double pipe ). Higher speeds means greater memory latency dependancy. Thus a 500MHZ CPU will feel less memory latency effects than that of a 1,000MHZ CPU. So if you had a 4-way 500MHZ machine, it would probably overtake the single way 1,000MHZ machine simply because of memory latency. Even though Intel has designed n-way machines, they have been focusing on widening the pipeline ( in both CPU and graphics chips.. even though they've reduced/dropped support for that market ). Wide pipes in graphics are especially useful because you are working on seriously complex operations. In order to alleviate this problem, Intel has made many ventures into the memory market. They started with their Pentium Pro by using some seriously fast L2-cache. Sadly this was rediculously expensive ( over $2,000 for a 1Meg chip ). Just before this, we were seeing motherboards with 2, 4 or even 8 Meg of L2 cache. I personally was having hopes that we would eventually see 64 or 128Meg of L2 cache and could finally replace DRAM with SRAM and eliminate most of the decades old limitations. We would have a much simpler system, and the power, heat and silicon costs would eventually be worked away, simply because of economies of scale. Unfortunately the PPro's cache was too hot, power-hungry, expensive, and low yield / volume. It was killed in favor of the P-II's significantly simpler ( and seperately purchased ) L2 cache. This direction virtually killed the mother-board based cache, and thus my hopes of a replacement of DRAM any time soon. Soon celerons started seeing on-die implimentations, and now we're seeing coppermines taking this aproach. This approach ( which we saw years ago with the Alpha's 92 or so K of L2 cache on-die ), basically eliminates the viability of 64+ Meg of memory on CPU's at least until they reach.1 micron sizes. In any case, caches can only temporarily hide the latencies of extremely slow memory. Believe it or not, DRAM has been consistently around 16MHZ for the past 10 years with barely any fundamental advancements. Sure, there are some neat tricks like making the pipe really wide ( 256 bits read out in 4 sequential bursts ), having intelligently refreshed rows, and allowing nearly 2 simultaneously active rows for fast column access, but if you look at the timing specs of these chips, they tend to have very high-latency for initial row accesses. I know that there are some premium chips that have significantly higher worst case timings ( namely used in graphics cards ), but we don't tend to find these in mainstream systems. Even DDR-SDRAM only finds ways to take active rows ( which I'm going to guess are more optimized and possible smaller to allow shorter response times ) and make them more rapidly accessible. The simplest ( and stupidest ) form of DDR-SDRAM would take the exact same amount of time to perform a colum fetch, but transfer the 256bit block twice as fast ( on both rising and falling clock edges, which seems to be all the rave nowadays ). Basically, I am doubting that there is any radically new technology here that addresses the core limitation of DRAM. More expensive systems ( almost always non-intel ) make use of interleaved memory, basically taking 2 or 4 parallel and independant memory pipes, each performing their own memory fetch.. Usually these are odd / even type interleaves, for example. In this way you can have twice the bandwidth and half the latency on average if you can maintain a non-empty queue of memory requests ( which isn't hard to do at all with modern n-way out-of-order CPUs ). This works especially well when you have multiple CPUs. In fact, the larger the memory queue, the better the opportunity to perform optimized memory access schedules by the memory controller, much like a SCSI controller can organize disk accesses in a elevator method ( rocking arm left and right ). If you were to be able to have 4, 8 or 16 independant memory devices, then you would be able to truely achieve up to 16 times the bandwidth. An intereting point is that DDR-SDRAM focuses mainly on sending large chunks of contiguous memory. Something that only really ever happens on cache fills, and they tend to be 256 bits wide. Rarely does the next memory access come immediately afterwards ( unless you are performing DMA operations ). In a 16-way interleaved memory structure, the bandwidth of each channel can be slower ( especially if the external IO is BW limited ) so long as you can initiate a new transaction while transferring the data of the old one. Essentially this is the art of pipelining. Pipelined L2 cache was the first memory to take this approach. SDRAM soon followed ( but not to the extent we are talking here ). The situation for Intel is as follows. Higher speed CPU's are going to be memory starved. Very rarely do we find tightly organized CPU instructions and data sets that fully take advantage of L2/ L3 caches. The standard today is to use generic, ready-made packages such as MFCs which are _heavily_ bloated. In fact, most C++ code is going to be non-spacially optimized. As DLL's grow in size, modularity generally increases, and context switching becomes more and more prevalent, caches will be less and less effective. Additionally, Intel/HP have worked hard ( in their IA64 ) to allow the queing of memory in a CPU ( and graphics chips ). Their ideal setup will be a quad processor configuration with one or more graphics processors, all contending for memory. Each device queuing up literally dozens of memory operations ( Not to mention the DMA access of streaming audio, video, network ). Single channel DDR-SDRAM, or even quad, octeplet, etc memory isn't going to sustain such load. Two independant sources will most likely be on seperate rows, and thus the memory controller will have to attempt to minize row thrashing by reordering requests. But there will still be a serious lag when these thrashes occur. There is no reason that I can think of that would prevent the use of interleaved DDR-SDRAM modules. Albeit you'd need a Chipset manufacturer ( other than Intel ) willing to risk making such an expensive device. Intels solution is RDRAM. Here you can have multiple channels, AND to my knowledge, you can queue multiple commands on the same channel to potentially multiple devices. Now, this is the theory. From the above, if you have a fixed bandwidth on the external IO, then you can divide the total inner bandwidth between each channel. You can do this by either lowering the frequency of internal channels, or by reducing the BUS width. Lowering the freq would slow simple commands being sent to each device ( thus reducing latency ), so it's best to reduce the bus-width. This also helps in reducing the number of wires on the motherboard. 8 channels at 64bits each takes up a lot of space. Now RAMBUS is similar in theory to PCI or SCSI: You have a master and a slave device, where commands and data are sent in packets. Theoretically, a channel could have multiple read/write(+data) packets sent, and the RDRAM modules would process them in a pipeline. Multiple RDRAM chips ( I believe they're called RIMMS ) on a channel would act like interleaving except cheaper. ( the controller only deals with 2 or 4 or 8 channels, but you could have #channels x #chips/channel interleaved memory segments. You wouldn't be able to expand #channels for a given motherboard(e.g. chipset ), but you could easily expand the number of chips on a channel, unlike [DDR-]SDRAM where you have one channel, and one active chip on that channel ). So, no matter how fast the external bus is, you can handle multi-CPU configurations, and even deep out-of-order memory operations, and especially IA64 super-deep memory operations in a snap. I seriously believe that these were the fanticized goals of Intel when they invested in Rambus. I do not know how far along RDRAM was when Intel got involved ( namely, did they know how poor the system would be at the outset? ) Intel most assuredly proto-typed their IA64 with various memory models (including a hypothetical high-latency, infinite concurrency memory model) and also against current SDRAM technologies. I'm sure that they learned their serious weakness with SDRAM. They must have been desperate to find a new solution. RDRAM was the closest that they could find, undoubtedly for the above reasons. Rambus must have foresaw some of their limitations and were thus desperate to get market-share. They must have known that they weren't going to survive unless they had high volume. New memory that completely lacks compatibilty is not going to survive unless it's adopted. Thus, their tactics are understandible. Intel's tactics seem fair when you look at IA64's needs. In order to ease the release, they had to get the market comfortable with the newer memory. If they could succeede in replacing SDRAM with RDRAM, then IA64 migration would be seamless. If not, the many _many_ limitations of IA64 would become painfully apparent, and they could potentially lose everything to AMD or other post-RISC CPUs. They are betting the farm on IA64, and must do everything in their power to maintain market share acceptance. IA64 is novel; it is bleeding edge technology. It is intelligent engineering since they didn't just make VLIW, or RISC, but instead "engineered" a solution from what seems to be most of the current technologies. But none of this will mean jack if it doesn't actually perform faster than existing technologies. The one saving grace is that it's designed with headroom, so it has much opportunity for improvement, where-as x86 and simple-RISC ( save Alpha ) really have to pull rabbits out their asses to increase performance without doubling silicon. Alpha, for example has compilation hints in their instructions. They've survived for quite a while without OOE. Only recently have they taken to this horse. Thus they still have some growth left in their current design. So, what of Rambus? The theory sounds great. It simply has to work for Intel's sake. But the reality is less dreamy. For power-consumption purposes you can't seem to be able to have too many ( if even more than one ) active chips on a channel, and thus you can look at this as row-thrashing taken to an extreme. I'm not even sure if you can request multiple addresses from completely independent chips on a channel. Thus at best you are getting the effects of interleaving 2 or 4 channels, but the inter-chip thrashing could more than make up for it. Additionally Tom has pointed out some serious bus latencies which could potentially seriously hurt performance. These latencies wouldn't be so bad at all if you could have multiple concurrent chips in operation ( again, I'm not sure if this is possible ), but single-chip operation seriously reduces the over-all benifit of 2 or 4 channel operation. Now, about benchmarks. Tom has basically condemned Rambus because of marginal improvements for extreme additional expense. He's also evaluated this whole stock-sharing policy from a short-sighted greed point of view. I think I've described the necessity of Intel's involvement and the desperation of Rambus to gain acceptance. Economies of scale regarding a radically new design are going to initially be expensive. Hell, Intel has almost always sold their state-of-the art at extreme prices, which [usually] eventually trickle down to the mainstream at reasonable prices. The only evil deed I see here is Intel's insistance on the acceptance dispite the desires of the general populace. We like the prices of PC's now. We're dealing with ever-more-expensive software ( ironically with lesser quality and usefulness ) in addition to fluxuations in RAM prices ( in addition to other components such as DVDs ). A manditory doubling in system price isn't going to sit well with us, and AMD will be all the happier to take up the slack.. If Intel ignores this, then they'll be sorry ( their marketing boys need to go back to economics school for some basic supply/demand and the effect of substitution goods ). Things may look bleak, but competition is doing very well ( Government even seems to be taking care of the bad Software boys.. well, sorta ). And lastly about the benchmarks.. Well, we're talking about software ( and hardware ) that barely takes advantage of the RDRAM. Remember, the theoretical point of this new system was to sustain high bandwidth WHEN you have a deep memory-request-queue. Many highly optimized programs are going to try and fit in cache and might even organize large-data accesses in such a way that do not split evently across RDRAM channels. Thus a single application ( namely quake ) will most likely not take too great of an advantage with RDRAM ( though I do see improvements ). BUT, when you multi-task, and more importantly, when you have multi-CPUs, or even when you migrate to IA64, THEN you will find incredible benifits. That's great an all, but what if I'm looking for a gaming platform. I want top-of-the-line, but my only choice seems to be RDRAM, and that's just not cost-effective. Well, right now you seem to be SOL unless your open to AMD. But, what I see is the new IA32 CPUs will have wider memory fetch queue's. They have slowly adopted multiple outstanding memory requests ( I believe in one of their PII lines ), and I believe that they still have some room for advancement in this technology in the IA32 line. From what I've seen, IA32 still has favor with Intel ( they don't exactly want to give IA32 to AMD on a silver plate, now do they? ) More importantly, RDRAM is, in my unsubstantiated opinion, slated for servers which farm out many concurrent services ( web-servers, for example ). I don't know if there are many good benchmarks out there for this. An Apache + DHTML test-bed would probably be the best test for an RDRAM system. My guess is that it will excell over SDRAM. File servers, too should fit nicely. My perspective is that RDRAM is a bad buy right now unless you absolutely need every ounce of performance that you can get. It is NOT currently for single app configurations. This would probably rule out the windows 98 market, and much of the NT market ( minus the *cough* *cough* NT-web-server, back-oriface market ). Certain Linux servers should work well also. RDRAM is here, and I think it has staying power. It _will_ get cheaper, it will be shoved down our throats. But more importantly, it will adapt much better to future CPU architectures than existing designs. DDR-SDRAM has a chance with interleaved memory as I said, but I'm doubting the feasibility. ( 5 years down the road, the shere number of pins of dual DDR-SDRAM might bring the costs beyond that of 4chan-RDRAM )
In conclusion. Tom needs to release some of that agression by actually playing Quake instead of benchmarking it. He needs to be a little more open minded ( and actually attempt to argue FOR the other side every once in a millenium. Or at least take on their pespective ). This goes for many of you techno-journalists. You do great work, but your minds can be like a long narrow tunnels. On the outside, capitalists seem cold, greedy and generally evil. And in many instances, they are ( blindly following economic models and acting out darwinistic barbarism on their competition, fed by the stock-driven need for unrelenting market growth ). But sometimes evil aliances ( such as WinTel, RamTel, MSac, etc ) are driven out of necessity for survival, and you have to be open minded to see their benifits over personal disgust.
It becomes very obviously, very early on that this movie is brain-candy, and you will not enjoy it if you nitpick about the impossibilities. ( Physics is, of course, the first thing to go.. dropping dozens of stories only to stop at the last second inches above ground ( Tom barely stopped above the glass floor in the first movie ), spinning of cars, motorcycles in a graceful waltz, etc ).
The character development was completely non-existant. You'll have to have seen the previous movie to be able to appretiate the hacker dude. I felt ZERO emotion in regards to the "essential" romance part of the plot. It seems to me that they didn't want to bother working out romance in an action movie, so that by making it part of the main plot it was more justifiable. Still, I have to give them credit for giving this otherwise useless female character a vital role. ( personally I didn't think she was so hot, but she wasn't bad ). Furthering the notion of character, there were no tragedies ( with the exception of the Tom Cruse getting shot scene, which was rather transparent ( though it still caught some moans from our audiance ) ). It didn't hold a candle to emotion in MI-1 in this regard.
MI-1, I think did a good job of linking to the original series. Same basic characters, repeated use of the exploding message, strong plot around the CIA, pseudo-complicated in a spy-movie sort of way. This had minimal ties, all of which could very well have been after thoughts ( oh yea, we need to add something MI-ish ). It became it's own generic action movie ( Bond, Schwartzineger, whatever ). I liked the quote "Matrix meets Outbreak".
Now, my biggest gripe. Many action fans like a pretty face or two ( Bond style ), no plot necessary ( or at least simple good-guy/ bad-guy.. Or even the modern, renegade good-guy/ imaculate, well respected bad-guy ), lots of action, and martial arts ( I'm still recovering from the bland Chuck Noris films ). So it definately has the elements for that genre. There's one slight problem.. IT'S BORING!! There were so many parts that I physically looked away from the screen in bordom. All the artsy fartsy slow-mo shots of the surrounding environment ( which supposedly sets the mood ), the various conversations, and side actions just all put me off. And it is by this token that I say it's a bad movie. If you exclusively focus on a genre, with the exclusion of at least good directing / writing, then you had damn well better fit the genre well. Action movies need non-stop action ( See Terminator II for reference ( minus some tiny plot scenes ) ).
Still, the movie had some redeeming values. Some cool quotes "when yellow dot reaches the red dot", "she's a woman. She has all the necessary qualifications", "this is not mission too difficult", etc. And in the true James bond spirit, the intro scene was better/cooler than most of the rest of the movie.
Conclusion: Go see it at a matinee JUST for the intro. You won't be disappointed. If you want, you can sneak into the ending half hour; It has the action that you might be interested in. Just ignore what the girl is doing. She's supposed to be committing suicide, even though the point of releasing her was to infect Sidney.. ( what, is she supposed to swim out there? )
if the biotech scientiest could "look at" the DNA sequence of the virus to confirm that it was actually it, then why the hell would they need the virus anyway? If you know the DNA, you have the virus....DUH!
Actually, it's the same as how doctors offices have been able to determine that you are or are not the father of a baby for decades now, even though it's only recently that we've "mostly" mapped the human DNA. You're not looking at individual nucleic acid-chains, but the size and location of the genes ( and maybe the average composition ).. I'm not in the medical field, but it's just common sence. It's like using the time stamps in Make to determine which files have changed and require recompiling. Doesn't actually look at the code to make the determination.
Resession is acomming. The severity is yet to be determined. Thankfully there are a couple guards against a full blown American style depression.
First of all, the money supply is being controlled more effectively than back in the day. There may still be more bugs in the Fed's monitoring system, but they at least wont sit idlely by as M1 declines like they did in the 30s.
Next, banks have all sorts of regulations which limits how much they can "bet" on the stock market. Unfortunately ( and at no worse possible time ), many of these restrictions are being lifted so that the poor banks can compete in this very same "Irrationally Exuberant" market. Thankfully only the soundest of the banks are being allowed, though I'm sure their hurt interests will have outreaching effects.
We may see bank failures / mergers, but this was already in the wind throughout the 90s ( lots of regulations have been put into place that all but encourages this ). So long as banks do not contribute to the contraction of the money supply.
What I can see happening, however, is that people pulling out of the market ( those that are lucky at any rate ) will hold their money in the form of cash. This is just as bad as making runs on banks, at least in terms of the money supply.
There would, of course be the serious drying up investment funds, but even though this will reduce the total amount of money ( mainly M3+ ), it will not immediately mean the loss of revenue ( unlike a bank failure ); merely the loss of earing assets and expansionary policy. Growth will probably become negative for a while, but I don't necessarily see massive amounts of firm failures. Just the growth dependant ones ( such as new firms still in debt, still waiting for a profitable quarter ).
Of course consumer confidence will be seriously shaken and consumption will decline. This will add to the cycle and further the recession. The good part is that we can deal with these sorts of recessions. Assuming that the Fed acts promptly and lowers rates sufficiently and people don't panic world-wide ( foreign makets pulling out, people defaulting on loans, etc ), then we'll be able to pull through. The stability of the market is going to be shredded cheese for a while though ( unless you stay away from tech, et. al )
In web applications, such complex calculations tend to be the abnormal case.
I'm sorry that I couldn't think of a better example off the top of my head. It was meant to reflect a generalized complex calculation ( non-mathematical even ). My company is regularly required to produce complex ( many modules worth ) of nested-if-statements and complex data manipulations between the form-front-end and the database-back-end. These produce an appretiable amount of CPU load. These could have been fined tuned, but we needed extensibility, readibility ( I know, foreign to the perl world ), and intuition. There is usually a trade-off. All Apache-mod_perl does is remove the over-head. Well, there is very little overhead to perl to begin with. Absolutely false.
Sorry, poorly chosen phrasing. I was really thinking about the comparison to java for this statement. And yes, I did leave out the API features mod_perl gives you. Though this is non-portable, so it also has it's catch ( yes I know, why would go choose another platform. But not all service providers allow the use of mod_perl, so if are a independant developers making use of ISPs, then you might be conserned with that sort of portibility ).
My company has 70,000 lines of Perl code. Compilation time is significant.
True 70k does take up a lot of time. Back in our CGI days ( when we ran netscape-es ), the total code was 100k or so, but broken up into 30 - 50 CGI's with only a few overlapping modules. At the time we didnt' even have a back-end DB ( it was a shell around a revision tool called clear-case ). It was very fast except for some of the slower clearcase calls. But again, my poorly announced point was the comparison to java in a non-persistent realm. A large java app will have to load and JIT ( which is as bad as compilation ) each modules as it comes up. Not to mention that it takes many many more lines to do the same thing in java that it does in perl. ( at least in my experience )
First off, nothing will compensate for poor code. If you are using mod_perl, you can cache database connections. Forking a process to grep a file, or find a file -- that's ludicrous! It can be done trivially in Perl.
Yes, it is a good point, but I assumed that this goes without saying. But how do you tell a manager to blanketly "enforce better programming". Since the choice of a language is at the managerial level, this topic really seems to be addressing them ( not to say that the coders don't have a big say ). My points were examples of some of the many potential needs to fork from perl (without resorting to making a slower version in raw perl ). Find and revision control features are relatively new features of perl-mod land. And my specific rev-ctl tool still does not have a mod implementation. I have no choice but to fork/exec. As for Find ( now you're going to make me boot up my linux box ) and several other tried and true UNIX tools, this is a balance of quick-and-dirty and analysis of the implementation. Find is a slow operation that consumes memory, disk-IO and CPU cycles. Is the time saved by not forking a find and tar just consumed again with a potentially flawed, or even pure-perl ( and thus slower ). And just so I don't sound like an idiot, I actually did a benchmark, and File::Find is indeed slower than qx(find... ). Unix tool Mods are really only benificial in my opinion when they're front ends to a C code.
There are regex engines for Java that provide much of the performance and flexibility of Perl.
Yes, but I said string operations. Perl: $a.= $b; Java: a += b; Is no contest. You have to perform string-buffer concatenation in java which isn't as convienient. But even this runs slower than perl ( in my simple benchmarks ). Beyond that, unless the java reg-ex engine is ultimately in C, it's going to be significantly slower than perl. I can not back this up with numbers; I've only gotten as far as to download the java-reg-ex engine.
There's *always* a more efficient way of doing something
Yep. And I guess my statement was straddling the fence too much. But the key is, how does your language more naturally present the solution. Developer time is important too. Perl gives you reg-exs up front. In java, you'd have to write out the solution either way. The best solution would probably be to find some module that already does much of it for you. The rest of your article has nice examples. Obviously people do use perl for larger scale operations. Slashdot, and my own company are other examples. I still am doubting the complexity of the business core that was a key component of my article. It would be hard for me to gague the complexity of your site. I definately feel that slashdot is simplistic in that all it is doing is interpreting databases and forms. Ahead of my company is the difficult decision of java v.s. perl. We have grown beyond simple DB customizing company and are now reverse engineering a complex application that uses FileMakerPro ( because we've convinced them [ without a detailed analysis of our own ] that the web and Oracle are a better platform ). However, we're slowly learning that filemaker is a huge fscking program. The company has already decided to choose java for a great many reasons. The DB and the UI are the most trivial elements. We're supposed to hook into an enormous number of concurrent services. It is, truely an enterprise class operation ( and it is in the medical industry where people's lives will be dependant on the results ) You can chant all you want that there is no substitute for good programming practice, but because of the worker shortage in America right now, we are forced to hire summer students to develop the more simpler elements. You can not rely on everyone being an expert. Perl has a lower minimum bar of bug-free code than a C-style langauge like java. At the very least, perl allows a significant number of run-time errors that java would catch in the compilation stage. The classic, it compiles, let's ship it out the door doesn't exist with perl. There could be buggy modules that _core_ the process that aren't caught for months. "use strict" is not even a required feature ( I checked, -w is not sufficient ). But this is a language question, and our discussion has been about mod_perl's effectiveness. It was a great run, sorry that the game is over so soon. I enjoy analysis discussions such as this. -Michael
Try reading the whole article. My statements should are all correct when you look at their context. The difference between.001 and.01s is not that significant in and of itself, which is where they were being compared. I am not suggesting java is faster than perl, that CGI is faster than mod_perl ( or even Apache::Registry ).
The main point dealt with scalability of complex Business logic. Where even the best written perl code is going to be a dog. I never said that java was faster, just that it is more _easily_ clusterable. Take a thousand 386 machines running java servlets, and I'm pretty sure that it'll be faster than a 1GHZ alpha running highly tuned perl ( or even C for that matter ) when properly loaded.
Re:Why is MySQL more popular than PostgreSQL?
on
Why Not MySQL?
·
· Score: 1
Sorry, but it isn't our corporate policy to sell services to customers that is based on beta software. And I think most would agree. I too have downloaded it ( though have been too lazy to get the compilation to work ), but wouldn't use it any more than for evaluation.
Sorry, but this isn't my experience. Perl is interpreted with very few optimizations. There are a good number of important calculations and operations that just do not work quickly in perl no matter what you do. FFT calculation, and graphic generation, for example are not going to go fast no matter what. Obviously, these types of modules should be found in C-compiled perl-module forms since they are so high profile ( though freeking gif image support has resently been discontinued ). But you should also be able to find these C front-ends in most any scripted / CGI-friendly language.
All Apache-mod_perl does is remove the over-head. Well, there is very little overhead to perl to begin with. I've run all sorts of comparisons between java and perl, and for small - medium sized scripts, compilation is barely noticable. The slowest parts tend to be in database reconnections, forking off seperate processes to do simple operations like file grepping, finding, etc.
You get past all of that with PHP and java-servlets though, so everyone is really on a level playing field. PHP even makes use of perl reg-exs ( though I'm not sure if they use the same optimized engine, even though they have compatible syntax ). It really comes down to the advantage your language has to your type of solution. For example, I have created a very powerful web templating system in perl which takes HTML and imbeds them into other HTML files all the while emulating both static-HTML and perl-CGI ( really just a glorified extension to Apache::Registry and Fast::CGI ), but I found that the same algorithm would run incredibly slowly in a java-servlet world because of the un-optimized string parsing in Java. But if I redesign the java-system so that it uses a truely optimized 'parser' then I can get better performance than even in perl.
I don't have numbers to back me up. But assuming a multi-CPU configuration, ( perl-threads still being considered beta ) a well designed java-solution will outperform a mod_perl solution ( especially since java-servlets can transparently span multiple computers, either by resource pooling, or through RMI segmentation / pipelining of the logic ). You can achieve this sort of distribution in perl ( I've successfully tried ), but it is non-trivial and not a logical attribute of the language. Thankfully though, mod_perl gives you the advantage of running multiple independant, concurrent perl-proceses in each Apache-worker. Thus you can make use of multiple CPUs at the process level. The only problem is that you have heavy context switching, as opposed to the light-weight context switching of a threaded model ( such as java-servlets ). You really notice the difference in a thread-optimized OS such as Solaris and associated [uSPARC] hardware ( where the CPU can thread-swap between instructions ). At this point, one file goes out to the DB while one reads from CGI parameters while two or three fight for raw computing horsepower. Another issue with process segmented workers is the redundant usage of memory and thus the propensity to Virtual memory thrashing. You, of course, always want to put more than enough memory in a server, but you also would like to cache as much of the web site as possible. If you were to scale to 50 workers, your memory contension would be well beyond that of a CPU-cachable range. Apache will soon be multi-threaded, and perl is making serious strides to make it's threading both safe and portable. 5.6 has a nice multiple interpreter model which works nicely for global variable consistency ( it's main purpose is to emulate forks on win32 machines ). This combination could bring perl almost back up to par, in terms of scalability, as java-servlets. But it is yet to be seen. For small-scale operations ( Apache-Front-end, HTML-rendering, Business-logic, database-back-end ), where the business-logic is minimal, you can use mod_perl with apache and have the DB on another computer and you have plenty of scalability. To my understanding this is exactly slashdot. It is when business-logic becomes comparible in resource requirements to the other elements that perl really falls short. It's hard to farm out CPU cycles to other machines or CPU's. And if your logic serializes access to data ( via DB row/table locks ) then the ability to finish business logic computation really starts to stand out like a soar thumb. As we move back into the world of server-based computation ( java-applets and client side web-apps never really took off ), this sort of massive business-logic will become increasingly important. Serious apps are still done in C ( or C++ if you're into extending your code ), but more and more are done in java in order to give you platform flexibility. Perl just doesnt show up in the enterprise model, or even the real service model beyond the simple form entry services like slashdot. I'm not saying you can't do magical things with perl ( I've already proven to my company that you can. TCP, forks, and threads are your friends ), but the technology does not easily afford you to do this. Java was designed with all of this in mind, they just don't always achieve their goals completely. I hope enough of you read this and find value in my experiences. I am not an authority, just a power user. -Michael
Ok, I love perl. But I am a disciplined programmer. And I can definately site problems with the perl OO model.
First, I think everyone can agree that OO was an afterthought in perl. It is not truely part of the perl system. In fact, it is merely a variation on the general function-calling scheme. {package}->{function-name}( {parameters} ) will walk through the package @{package}::ISA variable, looking for &{package}::{function-name}, or &{package}::autoload. It's logically just a complex if statement tacked onto the function calling routine. Because of the scripting nature, this is allowable, and also very dynamic and arguably useful. But we're not finished.
Then look at their pseudo-hashes. Take array-ref, treat them like a hash ref ( previously a compiler error ) and we'll take the special function of using the first field as a member-variable-name index into the array. Take it a little further. If you have a %{package}::FIELDS global, and you have a data-type of type {package}, then we don't need to waste the memory in array index 1. Does this seem elegant, intuitive, straight forward or even optimial to you?
The use of global variables to solve a problem is a design flaw in my opinion. In OO design, you should never have a global ( except maybe that of the application instance or constants ( but that's not a _variable_ is it? ) ). Sure, quick and dirty apps can use globals or my's all they like, but OO is usually for lasting/ extensible solutions. Using ISA for inheritance, and FIELDS for member variables is very cludgy in my opinion. I deal with it because I use perl more for it's power than it's OO. But you can not claim ignorance to it's dirtyness.
Another gripe about Perl-OO that I've long had is the 'this' variable. C++: void FooClass::bar( int x ) { m_x = x; }
Perl: sub FooClass::bar($$) : method locked { my FooClass $this = shift; my $x = shift; $this->{x} = $x; }
Writing OO in perl is physically painful. Look at all that extra typing. Forget it if you have Base::SubBase::class as your package/class name. From a readibility standpoint, all those $this->{xxx} statements really get in the way. Forget the idealogical point of view of not using globals which are at least are hidden by the use of: use fields qw( xxx yyy zzz ); and use base qw( BaseClass );
Now you have to deal with massively excessive text which makes writing long lines difficult to visually check.
Python is just as scripted as Perl, and they've managed to work OO in just as well as Cxx / Java. The following is paraphrased because I don't have the syntax memorized, but you would have:
class Foo : list-of-inherited-classes list-of-data-types list-of-methods
Then you at least get the implicit this->{m_varXX}
I love perl, and get work done a lot faster in it than any other languge that I've used ( because I'm allowed to balance how dirty my code is ). But I'm underimpressed by their OO implementation. I look at it more like the x86 world of backward compatibility. Yes, I love the fact that the AMD Athalon is the fastest x86 CPU out there ( and when they fix their stupid cache limitations, they'll be able to maintain that logo ). But I really admire Alpha, PowerPC and uSparc for their bueatiful RISC designs.
If Python could advance to the level of support and optimization that perl has, I would probably shift my development over. It is pleasant to the eye, easy on the fingers, and officially supports compilation to boot. ( Perl still cores when I compile any complex code ) I have serious doubts that perl is a foreward language. In 10 years it will be as muttered as x86 is seen to be now. We will be looking to replace it as we look to replace COBOL ( ironically for completely opposite reasons. COBOL was about readibility, and is being replaced for greater functionality, whereas perl is about functionality and will be replaced for readibility ). They are currently limited by their legacy syntax. The only way I can see them getting out of this rut is to add a compatibility mode. Eg, completely seperate parsers for a version 6. You'd say, for example require perl 6; which would have the scope of the current file ( thereby maintaining compatibility with older modules ) Either that or by wrapping "use Perl5Module {module_name}"
Finally, returning to the phrase "better than C++", I can't imagine what you mean. The only additional funcationality I find is the dynamic name-space. You can arbitrarily add variables and functions to an object. But I could just as easily argue why this is a bad thing ( see self modifying code under enterprise solutions and debugging woes ). I long for the C / java days when mispelling a variable name was a compilation error. We fixed the FOP model with "use strict", and we're fixing it in the OOP model with "my Class $var" and "our Class $var". But function calling still frustrates me. "@_" is great for quick and dirty, but horrible when validating variables. I wind up using the following model: sub foo { my %hash = @_; die "foo not found" unless exists $hash{foo}; die "bar not found" unless exists $hash{bar}: unless ( $hash{bar} > 5 && $hash{bar} 5 && $y 10 ); $i = $x; $j = $y; $k = $z; for my $item ( @w ) {... } } # end foo
Python even allows you to call functions in more than one way. location based passing ( C, Java method ), or named fields ( like my above hash-based parameters ).
This isn't a complete argument, and I'm sure I have holes. But I hope I've made my point through specific examples that perl is not a clean OO system.
I seriously disagree. At the very minimum, Objects allow you to capture the state of a system. In a function oriented approach, you would have to pass a state handler in order to isolate instances ( such as a parser, a data-base connection, etc ). OO at the very least does this for you in a semi-transparent fashion. It also does this in a logically consistent fashion.
The other material, such as polymorphism, inheritance etc are of finite usefulness. I find maybe one real use per project, and I can find other ways of solving the problem. In a scripting language there is a bit more overhead for such things ( since you can't optimize them away ).
Re:Why is MySQL more popular than PostgreSQL?
on
Why Not MySQL?
·
· Score: 1
Well, I'm not completely sure about that open-source part. The win32 side of things seem to be pretty clamped down. They do, however, say that the clients are all open ( because of GNU readline stuff ). But I'm not really disputing you here.
My beef is with the freeware concept. It's free to use, but you can't make any money off of redistribution. And that hurts a lot of people ( myself included ). At least their older versions are comming out a GPL'd but that still doesn't help my situation and many like me.
I can't sell my ASP model custom solution to customers with it uses MySQL. I have to pay for a license for each customer. I have to go out of my way to dis-associate the DB from my code and not physically give them MySQL. Sure you can say I'm trying to free ride, but I'm not crazy about giving a cut of my minimal profit over to the DB. Or at least if I do, then I'm going to demand some serious support and reliability. I can get that for not much more than MySQL with other vendors.
I'm not completely with up to speed with the GPL model, but I know that it limits my redistributability options, unlike perl.
Re:Why is MySQL more popular than PostgreSQL?
on
Why Not MySQL?
·
· Score: 2
If you are going free, you don't have too many choices ( at least that I'm aware of in my own personal search ). The two main choices that I see are PostgreSQL and Mysql.
Mysql has always demonstrated itself to be faster than postgres. Tables are smaller, and thus take up less memory. Nested selects can usually be broken into table joins ( except when there's data-dependancies ). Data-types are very space and performance minded ( time-stamps, bit fields ( and associated operators ), enumeriated types ). By making most things integer-based, comparisons are much quicker ( though potentially more limiting ). If you have a read-only table, you have the option, though it's not free, to compress it in an performance-minded way.
I've written the same table structures with similar data-types in both platforms, and without exception ( at least in my limited useage ), mysql was faster.
This is why mysql seems to be more popular than postgresql; We're all performance freaks in one way or another.
Unfortunately, because mysql is not truely free we were unable to use it over postgres ( if we were going to pay for a DBMS ( note the missing R ), we were going find the best overall product ). Postgres, additionally gave us a greater piece of mind. roll-back, and triggers for example.
With that said, we've repeated been frustrated with postgres because, even though it looks and smells like an RDBMS, it still lacks important features, such as foreign keys ( that whole section about making sure that you don't delete a user who has several articles ). Writing triggers for this would be a pain in the ass, since you'd have to figure out every possible usage. Version 7 thankfully will implement this.
If you need that much processing power for a DSL modem to be hardly noticible (which is what I suppose they mean, maybe less than 20-30% processor usage), then can you imagine playing Quake 3
You're missing the point. The reason they say you need this minimum is because this is what you'll need to effectively use the rest of your computer normally. Now, it's debatable what they consider normal, but if, for-example, they considered a normal configuration to be a 350MHZ machine ( min you can find these days ), then they'd add their CPU worst-case load onto it.. Asumming these numbers, then their max load would require a 200MHZ CPU.
This is unlike a Software DVD player, which can assume that you won't be doing anything else while watching the DVD.
Course, at the very least, you're going to increase your latency. Normally, you could pipeline the CPU operation, the xDSL encoding, and the transmission. Now the CPU can only pipeline against the transmission and must multiplex the CPU and encoding. This has the obvious effect of slowing down your applications ( Such as 3D shooters ), but has the added [inbound] ping time due to slower responsiveness from the context switching, etc.
-Michael
laser fusion revisited? ( nuclear cars )
on
Cooling With Lasers
·
· Score: 1
How likely do you think this would be applied to the process of fusion? Here is background and reasoning. Lasers have been used to produce non-continuous hot-fusion by wrapping hydrogen in a glass ball, balancing it in a magnetic confinement field, then zapping it in all diretions with a massive lassor burst ( generated from huge capasitors ). At best, you'd be able to take 10 - 20 of these chambers and run them like a motor engine, so it's not the greatest idea in the world. Cold fusion.. Basic idea: apply an electric field through heavy water with the use of metalic rods. As the water goes through electrolysis, the positive ions move towards one rod, and the negative the other. The positive side would be the hydrogen ions. They would gather around the rod, slowly crowding each other ( even within the rod itself ).. This crowding supposedly causes extreme density and ultimately mild forms of fusion which heat the water. Best part is that the reaction goes on for a long-long time, though I've heard that the heat produced isn't very much. Also I hear things like how finiky the materials are.. Something to do with left v.s. right sided molecules. And at the very least, the lack of reliable reproducability. So, here's the real question: If cold fusion ( fusion of two heavy ionized hydrogen atoms ( e.g. P1,N1+,E0 ) can work by merely haveing close proximity, can we duplicate this effect by merely super-cooling hydrogen. Idea 1: produce a super-solid sphere of hydrogen through lasor and magnetic cooling ( could even be only a couple hundred atoms if that's all that's practical ). If this isn't enough then ( assuming there is some validity to the cold-fusion theory ), apply this to the bare cold-fusion apparatus. Idea 2: Now that you have an extremely dense hydrogen base, blast it with a hot lasor. This returns to the idea of hot-lasor fusion, except that you're applying a hell of a lot of energy to an extremely solid piece of material. What I'm invisioning is that highly excited hydrogen atoms would be far more likely to collide with intense energy as a solid->gas than as just gas -> gas.
Idea 1 would be cool if it worked, but then again, so would cold fusion. Idea 2 should definately work ( since it works with hot hydrogen gas ( STP at least ) ). But I believe that you can use a hell of a lot less energy in this reaction than in current systems. I believe that if the cooling effect works well enough to minimize the heat blast energy, then we could even see car sized reactors ( assuming that we don't need magnetic fields ). Basically, you spend some time cooling a hydrogen cloud to a pellet, then apply a capasitive lasor burst to it. It should be on a small enough scale that a small engine block should contain the blast. Hell, we might even be able to mimic a sort of piston gas engine. Eg, 6 cylinders where 4 are charging, 1 is actively fusioning, and a 5'th is discharging.
This is, of course, pure speculation. But it is the job of the dreamers to find uses for technology. Assuming that there is any validity to the idea that super-cooling hydrogen can aid fusion, then it can only help the field. It's even possible that by super-cooling, the inter-nucleus distances are so small that gravity might actually play the same role that it is assumed to play in our sun. Course, radiation would play a role, and as far as nuclear engine blocks go, I don't know that we would be able to adequately shield the drivers. At least the polution shouldn't be too bad.:) Maybe we could see a return to big blimps ( just nuclear powered ones:)
Personally I think broadcasts should be on their own dedicated line. Either via the air-waves or via dedicated bandwidth from our cable company.
I'd really hate to have interrupts while watching a comedy just becase my son is downloading some patch to his game. But this is exactly what would happen with multi-casted HDTV over a shared network connection.
I don't mind cable companies selling Internet access with the same fiber ( ideally this 100Gbps ) because they're going to dedicate bandwidth to their hundred some channels, and only sell net access for the remainder.
Plus, it's a hell of a lot cheaper to have a company BUY cable explicitly then wire it to every room in the office building / school than to multicast up to 100G/s from the internet. Sure then you've got 2 fibers comming into your building instead of one, but the cable company fiber is almost free ( minus the monthy charge, and assuming they've got fiber in your neighborhood ) Just think about how much a T1 line costs now. And we're talking about buying general purpose internet access ( which just so happens that 100G/s is going to the same multi-casted locations regularly ). This is no cheap purchase today.. And the rewiring of the entire internet backbone ( plus the streets from the trunk to your building ) are not cheap by any means.
I still do not like the idea of using general purpose hi-tech network connections for simple broadcasting. It's the idea of doing graphics processing in the general purpose CPU verses a dedicated, optimized seperate processor. Broadcasting belongs on their own seperate channel.
Telephone lines, on the other-hand, I think should migrate their way onto the internet.. They're not dedicated lines, in fact, they're pretty damn close to TCP connections. They just need a little more reliability than the current internet phones. ( Internet II perhaps? ) The biggest advantage that I find from this is that we can consume the unused bandwidth from normal phone lines that we share on our OC-X connections. I'm sure telephone companies already do forms of digital compression and silent block removals before hitting the trunk, but still..
As a disclaimer, I'm no expert in these fields.. These are simply opinions based on what I've read. -Michael
Now now now, don't forget yourself. If you realy wanted to increase bandwidth, on a board, you'd either need fiber chanels or massively wide busses. Both of which are rather expensive, not just for the motherboard, but for the periferal manufacturers. The whole driving force in the PC industry has been supply and demand. IBM pushed MCA back in the 386 days ( absolutely better than ISA ( and probably even better than EISA ) ), but obviously the world didn't stampeed to this technology ( just like they don't stampeed to Alpha's apparent superiority, even though they can technically still run the same programs ). Granted IBM was proprietary. But the point is that the PC industry _can't_ just supe up their systems, because that costs money, and S & D requires an equilibrium for profit maximization ( and in the PC world, that just about breaks you even ).
There's also the case of compatibility. Even if you could produce as superior device in both performance _and_ price, you run the risk of lack of compatibility and thus you can only play a nitch and thus S&D kills you again.
The reason the PC industry has been technologically advancing so quickly is because there has been competition for maximally compatible components that simply run faster. ( Plus a segmented market with some willing to pay premium, and a large majority demanding the cheapest ). If we didn't have that diverse market, we'd still be running a 486 class machine today. ( And Alpha's wouldn't be windows 3.5 compatible )
I hate it when people talk about discovering more bandwidth that we can use ( or process ). When has this _ever_ been a problem in our history. My immediate reaction to this is that if the MPAA were to read that article, they'd be needlessly ultra paranoid about DeCSS. I say this because you and I will NOT be able to practically download entire DVD's any time soon. In order for us to have 100G / s bandwidth right now with that technology, it would have to be an isolated point to point network. Which means that you will probably be very familiar with the other end of the connection. The fear of DVD copying usually involves complete access to the entire web and a random end point for transmittion. The statistical likelihood of a desired DVD being on your other end are rather slim.
Another use for this 100G network would be in an office situation but again, unless you've got a point to point star network, you're multiplexing someone's data which will reduce your bandwidth ( to well within a computer's processing capability ). Still, it's a hell of a lot more than what we have now.. But again, live video feeds are from static, known points ( mainly within your building, or between a finite number of known buildings ).
So then, let's apply this technology to general publicly available internet connections. What do we have.. Raw bandwidth that will be soaking up by Linux distribution downloads, pr0n and general web-site traffic. Meaning if you put more bandwidth up, then the population will increase the volume of it's downloads to fill it. It's a basic trend that I'd be hard pressed to not call fact. And lets put this into perspective.. These 100G connections out on the internet are hardly going to be noticed over the existing high bandwidth lines where the routers are the slow point. Yes you can put high perf routers, and yes you'll eventually be able to maximally traffic this data, but your 56K modem or 1Mps cable network is not going to take advantage of it. And I'm doubting that we'll see home connections any time soon. Buisnesses that can afford such a connection are probably going to be saturating it. This is because it's probably not going to be cheap, and a business doesn't usually indulge in a technology for economic efficiency reasons.
Will this help? Of course. Will it be great? Hell yeah. Will you realize any benifit? No. Because it's like a savings account interest rate when there's inflation. You may be getting 10% interest in your savings account, but if inflation is 15%, that doesn't get you anything more tomorrow than you have today ( you'll just be hurting less than if you only got 2% interest ).
The biggest threat I see to the internet is video feeds ( hence my focus in this article ). If the public sees high bandwidth, they typically chant video, which, in my mind, if it ever comes to fruition then imagine the effect of thousands of homes leaving their internet TV connection on all night ( like we do our internet radio here at work ). This is just a rant, but it reflects my current paranoia about public bandwidth.
Try 600-800MHZ. This was the i820 and RDRAM. They even said that the comparing systems were overclocked to 133, meaning that when run in their rated mode, they would go even slower, making the performance benifit even more pronounced.
The whole point of RDRAM was to allow deeply pipelined, concurrent memory accesses from PCI periferals, 4x AGP and 2 to 4 800+MHZ CPU's.
Each RDRAM module can independantly handle a memory access, and each RDRAM channel can independantly transfer data ( on a simple 16 bit bus ). You have tons of bandwidth, just tons of associated latency.
In a multi-CPU configuration, you're going to get memory contention and thus latency, no matter what you do, so the added latency of RDRAM is hidden in such configurations.
The problem comes about in single CPU and 2x AGP( or any minimally utilized periferal configuration ). Here the added latency seriously shines, and you potentially can get slower memory access than standard SDRAM.
In short, the memory was doing what it was designed to do. -Michael
Ok, I've seen some good posts here, but I've worked at a company that does real time work, and I've picked up a few things.
To summarize, I think there is no best solution. Determination of response time verses throughput requirements, Floating point verses logic computation, hardware acceleratable verses pure SW execution, which OSes are allowed, custom verses off the shelf are all huge factors and completely change the rules.
First of all, no VM.. None.. period. I believe you can accomplish this buy setting swap size to zero, but that's not generally enough.
You're probably not going to want a multi-app optimized OS like windows ( don't flame please ) or UNIX.
You're going to want one of the embedded OS's or just hard-wired drivers. You could even get away with DOS. Where I work, we use QNIX, which is a bit aged, but labels itself as a real-time OS, so I assume it's their primary focus. The best part is that you get all your UNIX functionality, plus several really cool features and network-centric operations ( even more-so than UNIX ).
If you seriously need response time ( and we're talking micro-second response ), then you're probably going to want an embedded processor. I remember back in the days of the 486, there were embedded varients ( I can't even remember the names anymore ). You don't want interrupts to be a part of your basic operation, since you're stealing cycles in an unpredicatble way. IO and polling all the way baby; Can't get much more deterministic than that.
If you're doing much of a custom job, then you might do well with a co-processor type CPU, that gives you the added flexibility of your design. MIPS still takes this approach I believe. Plus there are plenty of high-perf off the shelf Co-Processor designs. DSP and geometry processors are readily available as seperate chips ( Glint comes to mind ).
The author seems to speak about name-brands, so I assume they're not dealing with anything so intricate.. Most likely, they're thinking of MS and real-time apps like video etc. If this is the case, then I'd have to say, the CPU with the quickest response time or the CPU with the greatest ability to handle your type of data.. Obviously floating point is going to point towards Intel ( unless you're dealing with Athalon ). But if you don't use FP, then AMD's K6 line had the shortest pipeline for the bang. A K6-3 is probably your best bet. It has nearly the caching capability of a P-II, comparible integer performance, but lower latency ( especially with branch misses ).
If these calculations are graphics based, again, seperate specialized components are going to be your best bet ( high-end video cards are now parallelized ) If this doesn't suite your needs, and general computation is your requirement. The more cache the better. It doesnt' suite real-time in that it's not deterministic, but, you will achieve more noticable throughput. When Athalon gets it's 2 and 4 Meg caches out the door, I'd vote for that.. But a maxed out Xeon is probably your best bet ( no numbers to back me up.. sorry ). On the topic of SMP. Deterministic time can not be garunteed. But if we're talking about throughput ( such as live video ) and not response time ( such as an missile tracking system ), AND your application is algorithmically threadible, then 2 or more CPU's will be worth your while. For example, I get nearly dbl my MP3 encoding performance with a dual celerons ( but only when encoding multiple wave files ). If, for example, you were dealing with some non-hardware accelerated video and audio stream, then dual CPU's could probably work to your benifit. ( there's simply no excuse for not having hardware support though ). Assuming multi-CPU configurations, Athalon has a better setup than the Xeon. And if Athalon could ever get their L2 memory size up to 4 or 8 meg, then you'd have a high-throughput device. Now, when we introduce price, I'd probably have to say that Athalon is going to win out here. The Xeon just falls out of the picture, value wise. The coppermine's optimal cache configuration applied to the Athalon would seriously make it the best all around ( minus the deep pipelining/latency ). The alpha seems to be a good contender everywhere except price. Small simple ordered pipeline. Decent cache size, good bus and SMP features. Problem, of course is price and application availability.
First thanks for the info. Second, I wasn't wrong in saying that magnets are produced from spinning electrons. You were assuming I exclusively meant extra-atomic circulations. Your saying that these are orbital-scale loops still requires that the electrons are "looping". And it is that circular motion that causes [ through the cross product ] the magnetic field. I wasn't completely sure that the electrons were confined to orbitals, but I remembered a diagram showing naturally occuring loops within the material itself. I presume that the molten metal is slowly solidifying, and the material is orienting itself in the direction of earths magnetic field.
I'm sorry if I presented the notion that there was some natural affiliation towards the right hand. But the fact of the matter is that the cross product produces an effect that can be described by this right hand notation/rule. You would not get the exact same results if you just used your left hand.. Everything would be reversed. What happens is that you choose your polarity such that you can use your right hand to describe it.
Benjaman Franklin arbitrarily chose positive and negative when dealing with electric flow ( specifically dealing with cathodes and anodes ). All the initial theory on electric current was established before we determined that the primary charge carrier was actually negative ( and thus all our descriptions were backwards ). It didn't obviously matter, except that when we draw an arrow pointing in one direction ( implying current flow ), what we really know we mean is that electrons are flowing in the opposite direction.
I haven't found the actual paper on this topic ( just the referenced news article ), but this seems to be related to a very well understood property of physics.. Maybe I'm missing something here,but this seems to be centripetal force, and the right hand rule.
In eletro-magnetism, motion of an electric charge produces a magnetic field in the perpendicular direction according the the right hand rule ( make the index finger of your right hand follow the direction of the positive charge and your thumb points into the direction of positive magnetic force ). If you have circular electric motion, then you'll have a circular magnetic field ( and that's how you get permanent magnets ).
Likewise with angular momentum.. Moving an object in a circle produces a perpendicular force ( again following the right hand rule ). They demonstrate it in physics class when they take a bike wheel and balance it on a string after spinning it. The bicycle effect is where the angular momentum produces a sort of virtual mass that fights changes in momentum. It's inertial frame cxauses it to tend to be stationary in space. That is why the bike doesn't fall down at high speeds; leaning to either side would require fighting the inertial frame. This is how gyroscopes work as well. Additionally, they demonstrate the right-hand-rule when they show which direction the balanced tire rotates about the balancing string.
Back in the early 90's I saw a guy build a gyroscopic contraption that spun very rapidly. He balanced it on a string with a counter weight and scale. He weighted the contraption while it was stationary, and then again while it was rotating. The rotation caused it to seem lighter. What is happening is that the perpendicular force was oriented in such a way that it was against gravity. What I believe is not that the device was levitating, but that it was resisting motion against it's angular momentum; e.g. In order to weight the object, it would had to sink. In this particular experiment only a tiny distinction in weight was measured. Potentially, higher rotational velocities would measure greater distinctions. Now we're looking at hovering superconductors.. Little or no resistence in the rotation, perfectly balanced. There is little reason to believe that the measurable "weight" of the object would not also seem to be less when rotating. I suspect that if they follow the simple diagrams that we learned in physics that show various shapes and their associated angular momentum, then they'll find ways of making the object weigh even less. For example, an infinitely thin cylinder with a large diameter will have the greatest possible angular momentum ( since all of it's mass will be rotating maximally ). Thus if they took a dense hollow cylinder and managed to make it spin on it's axis ( by virtue of super-conducting properties ), they'll find a great reduction in measurable 'weight'.
Note: I use weight instead of mass even though they are really the same thing just to further my point that they aren't messing with mass, but a measurable net force.
In the general theory of relativity, Einstein says that there is no real gravity, but merely a referential frame of acceleration. He goes on about the curvature of space being the real driving force, but the important concept is that all that we can perceive is the relative net force between two systems. There is no difference between saying that a space ship is defying gravity than if the space ship is imposing a larger, opposing force, than gravity. Observably, the net force is upward. Likewise centripetal force may oppose or simply resist gravitational force and thereby reduce it's effects.. It is not violating any known laws.
Since I believe we are dealing with a resistence to gravitation, and not a pure force that can oppose gravitation, we could never achieve a negative gravitational affect ( just like breaks on a car can never directly cause you to go backwards ). Thus if you want to make your air-plane or space ship lighter for better fuel efficiency, then you're going to have to have the cargo bay spin around very quickly, which might not be a generally desirable thing. An additional problem would occur if you went crazy and spun the device around at a speed approaching c. At this point, you'll have temporal deviations, and additionally, the object will gain mass ( as the energy of the system increases ( kinetic in this case ), so does it's relative mass ). In Practical terms, you'll wind up expending more energy accelerating the object angularly, than you will lifting it.
Now I didn't pay too much attention in class when we initially talked about angular momentum, so I might be wrong.. There may very well be an actual force, and we might be able to harness it like those UFO's we see depicted with spinning discs. But since the crew and cargo are very unlikely to want to endure 50Gs of angular force, your ship's spnning disk is going to have to produce a whole hell of a lot of force to lift not only it's own mass, but that of the entire ship.
In short, I have seen nothing here that suggests anti-gravity. Merely some experimentations that play with weaker forces that are less intuative to our everyday life style.
-Michael
summary of changes ( that I think are cool )
on
Perl 5.6.0 Out
·
· Score: 2
*New versioning representation for modules ( v1.2.3.4 ).
More portible ( though still experimental ) multi-threading model. Contains seperate interpreters per thread. ( old model is still available through compilation flags )
Incrementally better warning messages
-W option to replace -w ( provides even more debugging info )
*Enhancement of POD modules and joining with getopt to allow a help argument to dump the POD directly.
*New "our" keyword, which is like my but for global variables ( replaces "use vars qw(foo bar)" with "our ( $foo, $bar )" ). The advantage is when specifying data-types for global variables.
UTF-8 support ( blah )
More direct use of subroutine attributes was: sub foo { use attrs qw( method locked ); ... }
Now: sub foo : method locked { }
Optimization of qw( foo bar zap ). Now performs split at compile time instead of run-time.
*Auto file-handles
open my $handle, "file.txt"; Generates a file handle automagically.
*open() now accepts a 3'rd argument ( file-mod )
*Binary symantic: 0b01010101010
Better 64 bit support
Optimized sort { block } @data.
Allows sort to act like a function call for the following: sub foo($$) { $_[0] $_[1] }
And sort $coderef @array; allowed
File globs are more consistent.
New "CHECK" block, which acts like the "END" block, except is called at the end of compilation.
pack enhancements included template comments ( like reg-exes )
*Weak references. Thus you can cache objects without fear of memory leaks ( or have c-style trees or doublly linked lists )
exists and delete now function on array elements.
Better typed class support with fields::new().
Reg Ex: POSIX [[::]] character classes supported.
More convinient Benchmark module.
Several CPAN modules are now part of the basic distribution.
they went from Perl 5.005 to Perl 5.6 because they didn't want to release this as 5.006
Though I'm not on the team, I think the main reason for their change in notation is because they now can version correctly. Previously the notation was "%d.%0.3d_%0.3d". This becomes a floating point ( underscores are ignored in numeric values ). It was a hack to allow sub-minor versioning. There is now a new versioning symantic as follows: "v5.6.7"
The "v" prefix tells it that it's a multi-dot number. Basically it just converts to the equiv asci values ( thus I think you're limited to 255 per dot ).
But we can now say require v5.6.2.1 if we were so inclined. Thus, the left padded zeros are of no further value.
Slashdot Mirror
Now I think Rambus is getting a lot of unnecessary bad press. I think Tom's reviews are a little narrow minded, not to mention Tom has always been a little hot headed ( I can recall an incident or two when he was in a pissing contest with some other news boards. And I recall him having to appologize for some non-professional letters ). All in all, I like his site, but I take this sort of criticizm ( also remembering a complete emotional rejection of 3Dfx ) with a grain of salt. .1 micron sizes.
Point one. Intel has had a very long term strategy ever since the Pentium Pro. A simple fact is that the longer a CPU pipeline is, the more efficiently you can crunch numbers. The only other alternative is to make redundant CPU components and a seriously more complex internal bus ( you'd have to have more parallel ports to the register set, plus more complex scheduling ). Where-as, if you had to perfect 50 independant calculations, and you had 50 fully pipelined stages, you could chuck out an instruction/ clock. And at 1,500MHZ, that's pretty fscking sweet. This is completely the path of the Alpha chip. You get a hell of a lot more bang for your buck, since it takes a tiny bit more silicon to add an additional stage ( buffer plus redundant operations ), while a parallel stage requires 100% redundancy of functional unit plus additional bus interconnections a deeper, more complex and less efficient scheduler and a heavier load on the register set ( all of which degrade overall performance unless you can achieve a decent instruction level parallelism ).
Unfortuntaly, pipelining has it's own can of worms. First of all data-dependancy can really kill you if the pipe is too deep. Secondly, you need higher speeds to achieve the same throughput as a wider CPU. ( 750MHZ single but deep pipeline CPU should be similar to a 500MHZ short double pipe ). Higher speeds means greater memory latency dependancy. Thus a 500MHZ CPU will feel less memory latency effects than that of a 1,000MHZ CPU. So if you had a 4-way 500MHZ machine, it would probably overtake the single way 1,000MHZ machine simply because of memory latency.
Even though Intel has designed n-way machines, they have been focusing on widening the pipeline ( in both CPU and graphics chips.. even though they've reduced/dropped support for that market ). Wide pipes in graphics are especially useful because you are working on seriously complex operations.
In order to alleviate this problem, Intel has made many ventures into the memory market. They started with their Pentium Pro by using some seriously fast L2-cache. Sadly this was rediculously expensive ( over $2,000 for a 1Meg chip ). Just before this, we were seeing motherboards with 2, 4 or even 8 Meg of L2 cache. I personally was having hopes that we would eventually see 64 or 128Meg of L2 cache and could finally replace DRAM with SRAM and eliminate most of the decades old limitations. We would have a much simpler system, and the power, heat and silicon costs would eventually be worked away, simply because of economies of scale. Unfortunately the PPro's cache was too hot, power-hungry, expensive, and low yield / volume. It was killed in favor of the P-II's significantly simpler ( and seperately purchased ) L2 cache. This direction virtually killed the mother-board based cache, and thus my hopes of a replacement of DRAM any time soon. Soon celerons started seeing on-die implimentations, and now we're seeing coppermines taking this aproach. This approach ( which we saw years ago with the Alpha's 92 or so K of L2 cache on-die ), basically eliminates the viability of 64+ Meg of memory on CPU's at least until they reach
In any case, caches can only temporarily hide the latencies of extremely slow memory. Believe it or not, DRAM has been consistently around 16MHZ for the past 10 years with barely any fundamental advancements. Sure, there are some neat tricks like making the pipe really wide ( 256 bits read out in 4 sequential bursts ), having intelligently refreshed rows, and allowing nearly 2 simultaneously active rows for fast column access, but if you look at the timing specs of these chips, they tend to have very high-latency for initial row accesses. I know that there are some premium chips that have significantly higher worst case timings ( namely used in graphics cards ), but we don't tend to find these in mainstream systems.
Even DDR-SDRAM only finds ways to take active rows ( which I'm going to guess are more optimized and possible smaller to allow shorter response times ) and make them more rapidly accessible. The simplest ( and stupidest ) form of DDR-SDRAM would take the exact same amount of time to perform a colum fetch, but transfer the 256bit block twice as fast ( on both rising and falling clock edges, which seems to be all the rave nowadays ). Basically, I am doubting that there is any radically new technology here that addresses the core limitation of DRAM.
More expensive systems ( almost always non-intel ) make use of interleaved memory, basically taking 2 or 4 parallel and independant memory pipes, each performing their own memory fetch.. Usually these are odd / even type interleaves, for example. In this way you can have twice the bandwidth and half the latency on average if you can maintain a non-empty queue of memory requests ( which isn't hard to do at all with modern n-way out-of-order CPUs ). This works especially well when you have multiple CPUs.
In fact, the larger the memory queue, the better the opportunity to perform optimized memory access schedules by the memory controller, much like a SCSI controller can organize disk accesses in a elevator method ( rocking arm left and right ). If you were to be able to have 4, 8 or 16 independant memory devices, then you would be able to truely achieve up to 16 times the bandwidth. An intereting point is that DDR-SDRAM focuses mainly on sending large chunks of contiguous memory. Something that only really ever happens on cache fills, and they tend to be 256 bits wide. Rarely does the next memory access come immediately afterwards ( unless you are performing DMA operations ). In a 16-way interleaved memory structure, the bandwidth of each channel can be slower ( especially if the external IO is BW limited ) so long as you can initiate a new transaction while transferring the data of the old one. Essentially this is the art of pipelining. Pipelined L2 cache was the first memory to take this approach. SDRAM soon followed ( but not to the extent we are talking here ).
The situation for Intel is as follows. Higher speed CPU's are going to be memory starved. Very rarely do we find tightly organized CPU instructions and data sets that fully take advantage of L2/ L3 caches. The standard today is to use generic, ready-made packages such as MFCs which are _heavily_ bloated. In fact, most C++ code is going to be non-spacially optimized. As DLL's grow in size, modularity generally increases, and context switching becomes more and more prevalent, caches will be less and less effective. Additionally, Intel/HP have worked hard ( in their IA64 ) to allow the queing of memory in a CPU ( and graphics chips ). Their ideal setup will be a quad processor configuration with one or more graphics processors, all contending for memory. Each device queuing up literally dozens of memory operations ( Not to mention the DMA access of streaming audio, video, network ). Single channel DDR-SDRAM, or even quad, octeplet, etc memory isn't going to sustain such load. Two independant sources will most likely be on seperate rows, and thus the memory controller will have to attempt to minize row thrashing by reordering requests. But there will still be a serious lag when these thrashes occur.
There is no reason that I can think of that would prevent the use of interleaved DDR-SDRAM modules. Albeit you'd need a Chipset manufacturer ( other than Intel ) willing to risk making such an expensive device.
Intels solution is RDRAM. Here you can have multiple channels, AND to my knowledge, you can queue multiple commands on the same channel to potentially multiple devices. Now, this is the theory. From the above, if you have a fixed bandwidth on the external IO, then you can divide the total inner bandwidth between each channel. You can do this by either lowering the frequency of internal channels, or by reducing the BUS width. Lowering the freq would slow simple commands being sent to each device ( thus reducing latency ), so it's best to reduce the bus-width. This also helps in reducing the number of wires on the motherboard. 8 channels at 64bits each takes up a lot of space. Now RAMBUS is similar in theory to PCI or SCSI: You have a master and a slave device, where commands and data are sent in packets. Theoretically, a channel could have multiple read/write(+data) packets sent, and the RDRAM modules would process them in a pipeline. Multiple RDRAM chips ( I believe they're called RIMMS ) on a channel would act like interleaving except cheaper. ( the controller only deals with 2 or 4 or 8 channels, but you could have #channels x #chips/channel interleaved memory segments. You wouldn't be able to expand #channels for a given motherboard(e.g. chipset ), but you could easily expand the number of chips on a channel, unlike [DDR-]SDRAM where you have one channel, and one active chip on that channel ). So, no matter how fast the external bus is, you can handle multi-CPU configurations, and even deep out-of-order memory operations, and especially IA64 super-deep memory operations in a snap.
I seriously believe that these were the fanticized goals of Intel when they invested in Rambus. I do not know how far along RDRAM was when Intel got involved ( namely, did they know how poor the system would be at the outset? ) Intel most assuredly proto-typed their IA64 with various memory models (including a hypothetical high-latency, infinite concurrency memory model) and also against current SDRAM technologies. I'm sure that they learned their serious weakness with SDRAM. They must have been desperate to find a new solution. RDRAM was the closest that they could find, undoubtedly for the above reasons. Rambus must have foresaw some of their limitations and were thus desperate to get market-share. They must have known that they weren't going to survive unless they had high volume. New memory that completely lacks compatibilty is not going to survive unless it's adopted. Thus, their tactics are understandible. Intel's tactics seem fair when you look at IA64's needs. In order to ease the release, they had to get the market comfortable with the newer memory. If they could succeede in replacing SDRAM with RDRAM, then IA64 migration would be seamless. If not, the many _many_ limitations of IA64 would become painfully apparent, and they could potentially lose everything to AMD or other post-RISC CPUs. They are betting the farm on IA64, and must do everything in their power to maintain market share acceptance.
IA64 is novel; it is bleeding edge technology. It is intelligent engineering since they didn't just make VLIW, or RISC, but instead "engineered" a solution from what seems to be most of the current technologies. But none of this will mean jack if it doesn't actually perform faster than existing technologies. The one saving grace is that it's designed with headroom, so it has much opportunity for improvement, where-as x86 and simple-RISC ( save Alpha ) really have to pull rabbits out their asses to increase performance without doubling silicon. Alpha, for example has compilation hints in their instructions. They've survived for quite a while without OOE. Only recently have they taken to this horse. Thus they still have some growth left in their current design.
So, what of Rambus? The theory sounds great. It simply has to work for Intel's sake. But the reality is less dreamy. For power-consumption purposes you can't seem to be able to have too many ( if even more than one ) active chips on a channel, and thus you can look at this as row-thrashing taken to an extreme. I'm not even sure if you can request multiple addresses from completely independent chips on a channel. Thus at best you are getting the effects of interleaving 2 or 4 channels, but the inter-chip thrashing could more than make up for it. Additionally Tom has pointed out some serious bus latencies which could potentially seriously hurt performance. These latencies wouldn't be so bad at all if you could have multiple concurrent chips in operation ( again, I'm not sure if this is possible ), but single-chip operation seriously reduces the over-all benifit of 2 or 4 channel operation.
Now, about benchmarks. Tom has basically condemned Rambus because of marginal improvements for extreme additional expense. He's also evaluated this whole stock-sharing policy from a short-sighted greed point of view. I think I've described the necessity of Intel's involvement and the desperation of Rambus to gain acceptance. Economies of scale regarding a radically new design are going to initially be expensive. Hell, Intel has almost always sold their state-of-the art at extreme prices, which [usually] eventually trickle down to the mainstream at reasonable prices. The only evil deed I see here is Intel's insistance on the acceptance dispite the desires of the general populace. We like the prices of PC's now. We're dealing with ever-more-expensive software ( ironically with lesser quality and usefulness ) in addition to fluxuations in RAM prices ( in addition to other components such as DVDs ). A manditory doubling in system price isn't going to sit well with us, and AMD will be all the happier to take up the slack.. If Intel ignores this, then they'll be sorry ( their marketing boys need to go back to economics school for some basic supply/demand and the effect of substitution goods ). Things may look bleak, but competition is doing very well ( Government even seems to be taking care of the bad Software boys.. well, sorta ).
And lastly about the benchmarks.. Well, we're talking about software ( and hardware ) that barely takes advantage of the RDRAM. Remember, the theoretical point of this new system was to sustain high bandwidth WHEN you have a deep memory-request-queue. Many highly optimized programs are going to try and fit in cache and might even organize large-data accesses in such a way that do not split evently across RDRAM channels. Thus a single application ( namely quake ) will most likely not take too great of an advantage with RDRAM ( though I do see improvements ). BUT, when you multi-task, and more importantly, when you have multi-CPUs, or even when you migrate to IA64, THEN you will find incredible benifits. That's great an all, but what if I'm looking for a gaming platform. I want top-of-the-line, but my only choice seems to be RDRAM, and that's just not cost-effective. Well, right now you seem to be SOL unless your open to AMD. But, what I see is the new IA32 CPUs will have wider memory fetch queue's. They have slowly adopted multiple outstanding memory requests ( I believe in one of their PII lines ), and I believe that they still have some room for advancement in this technology in the IA32 line. From what I've seen, IA32 still has favor with Intel ( they don't exactly want to give IA32 to AMD on a silver plate, now do they? )
More importantly, RDRAM is, in my unsubstantiated opinion, slated for servers which farm out many concurrent services ( web-servers, for example ). I don't know if there are many good benchmarks out there for this. An Apache + DHTML test-bed would probably be the best test for an RDRAM system. My guess is that it will excell over SDRAM. File servers, too should fit nicely.
My perspective is that RDRAM is a bad buy right now unless you absolutely need every ounce of performance that you can get. It is NOT currently for single app configurations. This would probably rule out the windows 98 market, and much of the NT market ( minus the *cough* *cough* NT-web-server, back-oriface market ). Certain Linux servers should work well also.
RDRAM is here, and I think it has staying power. It _will_ get cheaper, it will be shoved down our throats. But more importantly, it will adapt much better to future CPU architectures than existing designs. DDR-SDRAM has a chance with interleaved memory as I said, but I'm doubting the feasibility. ( 5 years down the road, the shere number of pins of dual DDR-SDRAM might bring the costs beyond that of 4chan-RDRAM )
In conclusion. Tom needs to release some of that agression by actually playing Quake instead of benchmarking it. He needs to be a little more open minded ( and actually attempt to argue FOR the other side every once in a millenium. Or at least take on their pespective ). This goes for many of you techno-journalists. You do great work, but your minds can be like a long narrow tunnels. On the outside, capitalists seem cold, greedy and generally evil. And in many instances, they are ( blindly following economic models and acting out darwinistic barbarism on their competition, fed by the stock-driven need for unrelenting market growth ). But sometimes evil aliances ( such as WinTel, RamTel, MSac, etc ) are driven out of necessity for survival, and you have to be open minded to see their benifits over personal disgust.
-Michael
It becomes very obviously, very early on that this movie is brain-candy, and you will not enjoy it if you nitpick about the impossibilities. ( Physics is, of course, the first thing to go.. dropping dozens of stories only to stop at the last second inches above ground ( Tom barely stopped above the glass floor in the first movie ), spinning of cars, motorcycles in a graceful waltz, etc ).
The character development was completely non-existant. You'll have to have seen the previous movie to be able to appretiate the hacker dude. I felt ZERO emotion in regards to the "essential" romance part of the plot. It seems to me that they didn't want to bother working out romance in an action movie, so that by making it part of the main plot it was more justifiable. Still, I have to give them credit for giving this otherwise useless female character a vital role. ( personally I didn't think she was so hot, but she wasn't bad ). Furthering the notion of character, there were no tragedies ( with the exception of the Tom Cruse getting shot scene, which was rather transparent ( though it still caught some moans from our audiance ) ). It didn't hold a candle to emotion in MI-1 in this regard.
MI-1, I think did a good job of linking to the original series. Same basic characters, repeated use of the exploding message, strong plot around the CIA, pseudo-complicated in a spy-movie sort of way. This had minimal ties, all of which could very well have been after thoughts ( oh yea, we need to add something MI-ish ). It became it's own generic action movie ( Bond, Schwartzineger, whatever ). I liked the quote "Matrix meets Outbreak".
Now, my biggest gripe. Many action fans like a pretty face or two ( Bond style ), no plot necessary ( or at least simple good-guy/ bad-guy.. Or even the modern, renegade good-guy/ imaculate, well respected bad-guy ), lots of action, and martial arts ( I'm still recovering from the bland Chuck Noris films ). So it definately has the elements for that genre. There's one slight problem.. IT'S BORING!! There were so many parts that I physically looked away from the screen in bordom. All the artsy fartsy slow-mo shots of the surrounding environment ( which supposedly sets the mood ), the various conversations, and side actions just all put me off. And it is by this token that I say it's a bad movie. If you exclusively focus on a genre, with the exclusion of at least good directing / writing, then you had damn well better fit the genre well. Action movies need non-stop action ( See Terminator II for reference ( minus some tiny plot scenes ) ).
Still, the movie had some redeeming values. Some cool quotes "when yellow dot reaches the red dot", "she's a woman. She has all the necessary qualifications", "this is not mission too difficult", etc. And in the true James bond spirit, the intro scene was better/cooler than most of the rest of the movie.
Conclusion: Go see it at a matinee JUST for the intro. You won't be disappointed. If you want, you can sneak into the ending half hour; It has the action that you might be interested in. Just ignore what the girl is doing. She's supposed to be committing suicide, even though the point of releasing her was to infect Sidney.. ( what, is she supposed to swim out there? )
-Michael
I assume you're excluding Jurassic Park
Actually, it's the same as how doctors offices have been able to determine that you are or are not the father of a baby for decades now, even though it's only recently that we've "mostly" mapped the human DNA. You're not looking at individual nucleic acid-chains, but the size and location of the genes ( and maybe the average composition ).. I'm not in the medical field, but it's just common sence. It's like using the time stamps in Make to determine which files have changed and require recompiling. Doesn't actually look at the code to make the determination.
Resession is acomming. The severity is yet to be determined. Thankfully there are a couple guards against a full blown American style depression.
First of all, the money supply is being controlled more effectively than back in the day. There may still be more bugs in the Fed's monitoring system, but they at least wont sit idlely by as M1 declines like they did in the 30s.
Next, banks have all sorts of regulations which limits how much they can "bet" on the stock market. Unfortunately ( and at no worse possible time ), many of these restrictions are being lifted so that the poor banks can compete in this very same "Irrationally Exuberant" market. Thankfully only the soundest of the banks are being allowed, though I'm sure their hurt interests will have outreaching effects.
We may see bank failures / mergers, but this was already in the wind throughout the 90s ( lots of regulations have been put into place that all but encourages this ). So long as banks do not contribute to the contraction of the money supply.
What I can see happening, however, is that people pulling out of the market ( those that are lucky at any rate ) will hold their money in the form of cash. This is just as bad as making runs on banks, at least in terms of the money supply.
There would, of course be the serious drying up investment funds, but even though this will reduce the total amount of money ( mainly M3+ ), it will not immediately mean the loss of revenue ( unlike a bank failure ); merely the loss of earing assets and expansionary policy. Growth will probably become negative for a while, but I don't necessarily see massive amounts of firm failures. Just the growth dependant ones ( such as new firms still in debt, still waiting for a profitable quarter ).
Of course consumer confidence will be seriously shaken and consumption will decline. This will add to the cycle and further the recession. The good part is that we can deal with these sorts of recessions. Assuming that the Fed acts promptly and lowers rates sufficiently and people don't panic world-wide ( foreign makets pulling out, people defaulting on loans, etc ), then we'll be able to pull through. The stability of the market is going to be shredded cheese for a while though ( unless you stay away from tech, et. al )
Try reading the whole article. My statements should are all correct when you look at their context. The difference between .001 and .01s is not that significant in and of itself, which is where they were being compared. I am not suggesting java is faster than perl, that CGI is faster than mod_perl ( or even Apache::Registry ).
The main point dealt with scalability of complex Business logic. Where even the best written perl code is going to be a dog.
I never said that java was faster, just that it is more _easily_ clusterable. Take a thousand 386 machines running java servlets, and I'm pretty sure that it'll be faster than a 1GHZ alpha running highly tuned perl ( or even C for that matter ) when properly loaded.
Sorry, but it isn't our corporate policy to sell services to customers that is based on beta software. And I think most would agree. I too have downloaded it ( though have been too lazy to get the compilation to work ), but wouldn't use it any more than for evaluation.
Sorry, but this isn't my experience. Perl is interpreted with very few optimizations. There are a good number of important calculations and operations that just do not work quickly in perl no matter what you do. FFT calculation, and graphic generation, for example are not going to go fast no matter what. Obviously, these types of modules should be found in C-compiled perl-module forms since they are so high profile ( though freeking gif image support has resently been discontinued ). But you should also be able to find these C front-ends in most any scripted / CGI-friendly language.
All Apache-mod_perl does is remove the over-head. Well, there is very little overhead to perl to begin with. I've run all sorts of comparisons between java and perl, and for small - medium sized scripts, compilation is barely noticable. The slowest parts tend to be in database reconnections, forking off seperate processes to do simple operations like file grepping, finding, etc.
You get past all of that with PHP and java-servlets though, so everyone is really on a level playing field. PHP even makes use of perl reg-exs ( though I'm not sure if they use the same optimized engine, even though they have compatible syntax ). It really comes down to the advantage your language has to your type of solution. For example, I have created a very powerful web templating system in perl which takes HTML and imbeds them into other HTML files all the while emulating both static-HTML and perl-CGI ( really just a glorified extension to Apache::Registry and Fast::CGI ), but I found that the same algorithm would run incredibly slowly in a java-servlet world because of the un-optimized string parsing in Java. But if I redesign the java-system so that it uses a truely optimized 'parser' then I can get better performance than even in perl.
I don't have numbers to back me up. But assuming a multi-CPU configuration, ( perl-threads still being considered beta ) a well designed java-solution will outperform a mod_perl solution ( especially since java-servlets can transparently span multiple computers, either by resource pooling, or through RMI segmentation / pipelining of the logic ). You can achieve this sort of distribution in perl ( I've successfully tried ), but it is non-trivial and not a logical attribute of the language.
Thankfully though, mod_perl gives you the advantage of running multiple independant, concurrent perl-proceses in each Apache-worker. Thus you can make use of multiple CPUs at the process level. The only problem is that you have heavy context switching, as opposed to the light-weight context switching of a threaded model ( such as java-servlets ). You really notice the difference in a thread-optimized OS such as Solaris and associated [uSPARC] hardware ( where the CPU can thread-swap between instructions ). At this point, one file goes out to the DB while one reads from CGI parameters while two or three fight for raw computing horsepower.
Another issue with process segmented workers is the redundant usage of memory and thus the propensity to Virtual memory thrashing. You, of course, always want to put more than enough memory in a server, but you also would like to cache as much of the web site as possible. If you were to scale to 50 workers, your memory contension would be well beyond that of a CPU-cachable range.
Apache will soon be multi-threaded, and perl is making serious strides to make it's threading both safe and portable. 5.6 has a nice multiple interpreter model which works nicely for global variable consistency ( it's main purpose is to emulate forks on win32 machines ). This combination could bring perl almost back up to par, in terms of scalability, as java-servlets. But it is yet to be seen.
For small-scale operations ( Apache-Front-end, HTML-rendering, Business-logic, database-back-end ), where the business-logic is minimal, you can use mod_perl with apache and have the DB on another computer and you have plenty of scalability. To my understanding this is exactly slashdot. It is when business-logic becomes comparible in resource requirements to the other elements that perl really falls short. It's hard to farm out CPU cycles to other machines or CPU's. And if your logic serializes access to data ( via DB row/table locks ) then the ability to finish business logic computation really starts to stand out like a soar thumb.
As we move back into the world of server-based computation ( java-applets and client side web-apps never really took off ), this sort of massive business-logic will become increasingly important. Serious apps are still done in C ( or C++ if you're into extending your code ), but more and more are done in java in order to give you platform flexibility. Perl just doesnt show up in the enterprise model, or even the real service model beyond the simple form entry services like slashdot.
I'm not saying you can't do magical things with perl ( I've already proven to my company that you can. TCP, forks, and threads are your friends ), but the technology does not easily afford you to do this. Java was designed with all of this in mind, they just don't always achieve their goals completely.
I hope enough of you read this and find value in my experiences. I am not an authority, just a power user.
-Michael
Ok, I love perl. But I am a disciplined programmer. And I can definately site problems with the perl OO model.
... }
First, I think everyone can agree that OO was an afterthought in perl. It is not truely part of the perl system. In fact, it is merely a variation on the general function-calling scheme. {package}->{function-name}( {parameters} ) will walk through the package @{package}::ISA variable, looking for &{package}::{function-name}, or &{package}::autoload. It's logically just a complex if statement tacked onto the function calling routine. Because of the scripting nature, this is allowable, and also very dynamic and arguably useful. But we're not finished.
Then look at their pseudo-hashes. Take array-ref, treat them like a hash ref ( previously a compiler error ) and we'll take the special function of using the first field as a member-variable-name index into the array. Take it a little further. If you have a %{package}::FIELDS global, and you have a data-type of type {package}, then we don't need to waste the memory in array index 1. Does this seem elegant, intuitive, straight forward or even optimial to you?
The use of global variables to solve a problem is a design flaw in my opinion. In OO design, you should never have a global ( except maybe that of the application instance or constants ( but that's not a _variable_ is it? ) ). Sure, quick and dirty apps can use globals or my's all they like, but OO is usually for lasting/ extensible solutions. Using ISA for inheritance, and FIELDS for member variables is very cludgy in my opinion. I deal with it because I use perl more for it's power than it's OO. But you can not claim ignorance to it's dirtyness.
Another gripe about Perl-OO that I've long had is the 'this' variable.
C++: void FooClass::bar( int x ) { m_x = x; }
Perl: sub FooClass::bar($$) : method locked {
my FooClass $this = shift;
my $x = shift;
$this->{x} = $x;
}
Writing OO in perl is physically painful. Look at all that extra typing. Forget it if you have Base::SubBase::class as your package/class name. From a readibility standpoint, all those $this->{xxx} statements really get in the way. Forget the idealogical point of view of not using globals which are at least are hidden by the use of:
use fields qw( xxx yyy zzz );
and
use base qw( BaseClass );
Now you have to deal with massively excessive text which makes writing long lines difficult to visually check.
Python is just as scripted as Perl, and they've managed to work OO in just as well as Cxx / Java.
The following is paraphrased because I don't have the syntax memorized, but you would have:
class Foo : list-of-inherited-classes
list-of-data-types
list-of-methods
Then you at least get the implicit this->{m_varXX}
I love perl, and get work done a lot faster in it than any other languge that I've used ( because I'm allowed to balance how dirty my code is ). But I'm underimpressed by their OO implementation. I look at it more like the x86 world of backward compatibility. Yes, I love the fact that the AMD Athalon is the fastest x86 CPU out there ( and when they fix their stupid cache limitations, they'll be able to maintain that logo ). But I really admire Alpha, PowerPC and uSparc for their bueatiful RISC designs.
If Python could advance to the level of support and optimization that perl has, I would probably shift my development over. It is pleasant to the eye, easy on the fingers, and officially supports compilation to boot. ( Perl still cores when I compile any complex code ) I have serious doubts that perl is a foreward language. In 10 years it will be as muttered as x86 is seen to be now. We will be looking to replace it as we look to replace COBOL ( ironically for completely opposite reasons. COBOL was about readibility, and is being replaced for greater functionality, whereas perl is about functionality and will be replaced for readibility ). They are currently limited by their legacy syntax. The only way I can see them getting out of this rut is to add a compatibility mode. Eg, completely seperate parsers for a version 6.
You'd say, for example
require perl 6; which would have the scope of the current file ( thereby maintaining compatibility with older modules ) Either that or by wrapping "use Perl5Module {module_name}"
Finally, returning to the phrase "better than C++", I can't imagine what you mean. The only additional funcationality I find is the dynamic name-space. You can arbitrarily add variables and functions to an object. But I could just as easily argue why this is a bad thing ( see self modifying code under enterprise solutions and debugging woes ). I long for the C / java days when mispelling a variable name was a compilation error. We fixed the FOP model with "use strict", and we're fixing it in the OOP model with "my Class $var" and "our Class $var". But function calling still frustrates me. "@_" is great for quick and dirty, but horrible when validating variables. I wind up using the following model:
sub foo {
my %hash = @_;
die "foo not found" unless exists $hash{foo};
die "bar not found" unless exists $hash{bar}:
unless ( $hash{bar} > 5 && $hash{bar} 5 && $y 10 );
$i = $x;
$j = $y;
$k = $z;
for my $item ( @w ) {
} # end foo
Python even allows you to call functions in more than one way. location based passing ( C, Java method ), or named fields ( like my above hash-based parameters ).
This isn't a complete argument, and I'm sure I have holes. But I hope I've made my point through specific examples that perl is not a clean OO system.
I seriously disagree. At the very minimum, Objects allow you to capture the state of a system. In a function oriented approach, you would have to pass a state handler in order to isolate instances ( such as a parser, a data-base connection, etc ). OO at the very least does this for you in a semi-transparent fashion. It also does this in a logically consistent fashion.
The other material, such as polymorphism, inheritance etc are of finite usefulness. I find maybe one real use per project, and I can find other ways of solving the problem. In a scripting language there is a bit more overhead for such things ( since you can't optimize them away ).
Well, I'm not completely sure about that open-source part. The win32 side of things seem to be pretty clamped down. They do, however, say that the clients are all open ( because of GNU readline stuff ). But I'm not really disputing you here.
My beef is with the freeware concept. It's free to use, but you can't make any money off of redistribution. And that hurts a lot of people ( myself included ). At least their older versions are comming out a GPL'd but that still doesn't help my situation and many like me.
I can't sell my ASP model custom solution to customers with it uses MySQL. I have to pay for a license for each customer. I have to go out of my way to dis-associate the DB from my code and not physically give them MySQL. Sure you can say I'm trying to free ride, but I'm not crazy about giving a cut of my minimal profit over to the DB. Or at least if I do, then I'm going to demand some serious support and reliability. I can get that for not much more than MySQL with other vendors.
I'm not completely with up to speed with the GPL model, but I know that it limits my redistributability options, unlike perl.
If you are going free, you don't have too many choices ( at least that I'm aware of in my own personal search ). The two main choices that I see are PostgreSQL and Mysql.
Mysql has always demonstrated itself to be faster than postgres. Tables are smaller, and thus take up less memory. Nested selects can usually be broken into table joins ( except when there's data-dependancies ). Data-types are very space and performance minded ( time-stamps, bit fields ( and associated operators ), enumeriated types ). By making most things integer-based, comparisons are much quicker ( though potentially more limiting ). If you have a read-only table, you have the option, though it's not free, to compress it in an performance-minded way.
I've written the same table structures with similar data-types in both platforms, and without exception ( at least in my limited useage ), mysql was faster.
This is why mysql seems to be more popular than postgresql; We're all performance freaks in one way or another.
Unfortunately, because mysql is not truely free we were unable to use it over postgres ( if we were going to pay for a DBMS ( note the missing R ), we were going find the best overall product ). Postgres, additionally gave us a greater piece of mind. roll-back, and triggers for example.
With that said, we've repeated been frustrated with postgres because, even though it looks and smells like an RDBMS, it still lacks important features, such as foreign keys ( that whole section about making sure that you don't delete a user who has several articles ). Writing triggers for this would be a pain in the ass, since you'd have to figure out every possible usage. Version 7 thankfully will implement this.
If you need that much processing power for a DSL modem to be hardly noticible (which is what I suppose they mean, maybe less than 20-30% processor usage), then can you imagine playing Quake 3
You're missing the point. The reason they say you need this minimum is because this is what you'll need to effectively use the rest of your computer normally. Now, it's debatable what they consider normal, but if, for-example, they considered a normal configuration to be a 350MHZ machine ( min you can find these days ), then they'd add their CPU worst-case load onto it.. Asumming these numbers, then their max load would require a 200MHZ CPU.
This is unlike a Software DVD player, which can assume that you won't be doing anything else while watching the DVD.
Course, at the very least, you're going to increase your latency. Normally, you could pipeline the CPU operation, the xDSL encoding, and the transmission. Now the CPU can only pipeline against the transmission and must multiplex the CPU and encoding. This has the obvious effect of slowing down your applications ( Such as 3D shooters ), but has the added [inbound] ping time due to slower responsiveness from the context switching, etc.
-Michael
How likely do you think this would be applied to the process of fusion? Here is background and reasoning.
:) Maybe we could see a return to big blimps ( just nuclear powered ones :)
Lasers have been used to produce non-continuous hot-fusion by wrapping hydrogen in a glass ball, balancing it in a magnetic confinement field, then zapping it in all diretions with a massive lassor burst ( generated from huge capasitors ). At best, you'd be able to take 10 - 20 of these chambers and run them like a motor engine, so it's not the greatest idea in the world.
Cold fusion.. Basic idea: apply an electric field through heavy water with the use of metalic rods. As the water goes through electrolysis, the positive ions move towards one rod, and the negative the other. The positive side would be the hydrogen ions. They would gather around the rod, slowly crowding each other ( even within the rod itself ).. This crowding supposedly causes extreme density and ultimately mild forms of fusion which heat the water. Best part is that the reaction goes on for a long-long time, though I've heard that the heat produced isn't very much. Also I hear things like how finiky the materials are.. Something to do with left v.s. right sided molecules. And at the very least, the lack of reliable reproducability.
So, here's the real question: If cold fusion ( fusion of two heavy ionized hydrogen atoms ( e.g. P1,N1+,E0 ) can work by merely haveing close proximity, can we duplicate this effect by merely super-cooling hydrogen.
Idea 1: produce a super-solid sphere of hydrogen through lasor and magnetic cooling ( could even be only a couple hundred atoms if that's all that's practical ). If this isn't enough then ( assuming there is some validity to the cold-fusion theory ), apply this to the bare cold-fusion apparatus.
Idea 2: Now that you have an extremely dense hydrogen base, blast it with a hot lasor. This returns to the idea of hot-lasor fusion, except that you're applying a hell of a lot of energy to an extremely solid piece of material. What I'm invisioning is that highly excited hydrogen atoms would be far more likely to collide with intense energy as a solid->gas than as just gas -> gas.
Idea 1 would be cool if it worked, but then again, so would cold fusion.
Idea 2 should definately work ( since it works with hot hydrogen gas ( STP at least ) ). But I believe that you can use a hell of a lot less energy in this reaction than in current systems. I believe that if the cooling effect works well enough to minimize the heat blast energy, then we could even see car sized reactors ( assuming that we don't need magnetic fields ). Basically, you spend some time cooling a hydrogen cloud to a pellet, then apply a capasitive lasor burst to it. It should be on a small enough scale that a small engine block should contain the blast. Hell, we might even be able to mimic a sort of piston gas engine. Eg, 6 cylinders where 4 are charging, 1 is actively fusioning, and a 5'th is discharging.
This is, of course, pure speculation. But it is the job of the dreamers to find uses for technology. Assuming that there is any validity to the idea that super-cooling hydrogen can aid fusion, then it can only help the field.
It's even possible that by super-cooling, the inter-nucleus distances are so small that gravity might actually play the same role that it is assumed to play in our sun.
Course, radiation would play a role, and as far as nuclear engine blocks go, I don't know that we would be able to adequately shield the drivers. At least the polution shouldn't be too bad.
Personally I think broadcasts should be on their own dedicated line. Either via the air-waves or via dedicated bandwidth from our cable company.
I'd really hate to have interrupts while watching a comedy just becase my son is downloading some patch to his game. But this is exactly what would happen with multi-casted HDTV over a shared network connection.
I don't mind cable companies selling Internet access with the same fiber ( ideally this 100Gbps ) because they're going to dedicate bandwidth to their hundred some channels, and only sell net access for the remainder.
Plus, it's a hell of a lot cheaper to have a company BUY cable explicitly then wire it to every room in the office building / school than to multicast up to 100G/s from the internet. Sure then you've got 2 fibers comming into your building instead of one, but the cable company fiber is almost free ( minus the monthy charge, and assuming they've got fiber in your neighborhood ) Just think about how much a T1 line costs now. And we're talking about buying general purpose internet access ( which just so happens that 100G/s is going to the same multi-casted locations regularly ). This is no cheap purchase today.. And the rewiring of the entire internet backbone ( plus the streets from the trunk to your building ) are not cheap by any means.
I still do not like the idea of using general purpose hi-tech network connections for simple broadcasting. It's the idea of doing graphics processing in the general purpose CPU verses a dedicated, optimized seperate processor. Broadcasting belongs on their own seperate channel.
Telephone lines, on the other-hand, I think should migrate their way onto the internet.. They're not dedicated lines, in fact, they're pretty damn close to TCP connections. They just need a little more reliability than the current internet phones. ( Internet II perhaps? ) The biggest advantage that I find from this is that we can consume the unused bandwidth from normal phone lines that we share on our OC-X connections. I'm sure telephone companies already do forms of digital compression and silent block removals before hitting the trunk, but still..
As a disclaimer, I'm no expert in these fields.. These are simply opinions based on what I've read.
-Michael
Now now now, don't forget yourself. If you realy wanted to increase bandwidth, on a board, you'd either need fiber chanels or massively wide busses. Both of which are rather expensive, not just for the motherboard, but for the periferal manufacturers. The whole driving force in the PC industry has been supply and demand. IBM pushed MCA back in the 386 days ( absolutely better than ISA ( and probably even better than EISA ) ), but obviously the world didn't stampeed to this technology ( just like they don't stampeed to Alpha's apparent superiority, even though they can technically still run the same programs ). Granted IBM was proprietary. But the point is that the PC industry _can't_ just supe up their systems, because that costs money, and S & D requires an equilibrium for profit maximization ( and in the PC world, that just about breaks you even ).
There's also the case of compatibility. Even if you could produce as superior device in both performance _and_ price, you run the risk of lack of compatibility and thus you can only play a nitch and thus S&D kills you again.
The reason the PC industry has been technologically advancing so quickly is because there has been competition for maximally compatible components that simply run faster. ( Plus a segmented market with some willing to pay premium, and a large majority demanding the cheapest ). If we didn't have that diverse market, we'd still be running a 486 class machine today. ( And Alpha's wouldn't be windows 3.5 compatible )
-Michael
I hate it when people talk about discovering more bandwidth that we can use ( or process ). When has this _ever_ been a problem in our history. My immediate reaction to this is that if the MPAA were to read that article, they'd be needlessly ultra paranoid about DeCSS. I say this because you and I will NOT be able to practically download entire DVD's any time soon. In order for us to have 100G / s bandwidth right now with that technology, it would have to be an isolated point to point network. Which means that you will probably be very familiar with the other end of the connection. The fear of DVD copying usually involves complete access to the entire web and a random end point for transmittion. The statistical likelihood of a desired DVD being on your other end are rather slim.
Another use for this 100G network would be in an office situation but again, unless you've got a point to point star network, you're multiplexing someone's data which will reduce your bandwidth ( to well within a computer's processing capability ). Still, it's a hell of a lot more than what we have now.. But again, live video feeds are from static, known points ( mainly within your building, or between a finite number of known buildings ).
So then, let's apply this technology to general publicly available internet connections. What do we have.. Raw bandwidth that will be soaking up by Linux distribution downloads, pr0n and general web-site traffic. Meaning if you put more bandwidth up, then the population will increase the volume of it's downloads to fill it. It's a basic trend that I'd be hard pressed to not call fact. And lets put this into perspective.. These 100G connections out on the internet are hardly going to be noticed over the existing high bandwidth lines where the routers are the slow point. Yes you can put high perf routers, and yes you'll eventually be able to maximally traffic this data, but your 56K modem or 1Mps cable network is not going to take advantage of it. And I'm doubting that we'll see home connections any time soon. Buisnesses that can afford such a connection are probably going to be saturating it. This is because it's probably not going to be cheap, and a business doesn't usually indulge in a technology for economic efficiency reasons.
Will this help? Of course. Will it be great? Hell yeah. Will you realize any benifit? No. Because it's like a savings account interest rate when there's inflation. You may be getting 10% interest in your savings account, but if inflation is 15%, that doesn't get you anything more tomorrow than you have today ( you'll just be hurting less than if you only got 2% interest ).
The biggest threat I see to the internet is video feeds ( hence my focus in this article ). If the public sees high bandwidth, they typically chant video, which, in my mind, if it ever comes to fruition then imagine the effect of thousands of homes leaving their internet TV connection on all night ( like we do our internet radio here at work ). This is just a rant, but it reflects my current paranoia about public bandwidth.
-Michael
Try 600-800MHZ. This was the i820 and RDRAM. They even said that the comparing systems were overclocked to 133, meaning that when run in their rated mode, they would go even slower, making the performance benifit even more pronounced.
The whole point of RDRAM was to allow deeply pipelined, concurrent memory accesses from PCI periferals, 4x AGP and 2 to 4 800+MHZ CPU's.
Each RDRAM module can independantly handle a memory access, and each RDRAM channel can independantly transfer data ( on a simple 16 bit bus ). You have tons of bandwidth, just tons of associated latency.
In a multi-CPU configuration, you're going to get memory contention and thus latency, no matter what you do, so the added latency of RDRAM is hidden in such configurations.
The problem comes about in single CPU and 2x AGP( or any minimally utilized periferal configuration ). Here the added latency seriously shines, and you potentially can get slower memory access than standard SDRAM.
In short, the memory was doing what it was designed to do.
-Michael
Ok, I've seen some good posts here, but I've worked at a company that does real time work, and I've picked up a few things.
To summarize, I think there is no best solution. Determination of response time verses throughput requirements, Floating point verses logic computation, hardware acceleratable verses pure SW execution, which OSes are allowed, custom verses off the shelf are all huge factors and completely change the rules.
First of all, no VM.. None.. period. I believe you can accomplish this buy setting swap size to zero, but that's not generally enough.
You're probably not going to want a multi-app optimized OS like windows ( don't flame please ) or UNIX.
You're going to want one of the embedded OS's or just hard-wired drivers. You could even get away with DOS. Where I work, we use QNIX, which is a bit aged, but labels itself as a real-time OS, so I assume it's their primary focus. The best part is that you get all your UNIX functionality, plus several really cool features and network-centric operations ( even more-so than UNIX ).
If you seriously need response time ( and we're talking micro-second response ), then you're probably going to want an embedded processor. I remember back in the days of the 486, there were embedded varients ( I can't even remember the names anymore ). You don't want interrupts to be a part of your basic operation, since you're stealing cycles in an unpredicatble way. IO and polling all the way baby; Can't get much more deterministic than that.
If you're doing much of a custom job, then you might do well with a co-processor type CPU, that gives you the added flexibility of your design. MIPS still takes this approach I believe. Plus there are plenty of high-perf off the shelf Co-Processor designs. DSP and geometry processors are readily available as seperate chips ( Glint comes to mind ).
The author seems to speak about name-brands, so I assume they're not dealing with anything so intricate.. Most likely, they're thinking of MS and real-time apps like video etc. If this is the case, then I'd have to say, the CPU with the quickest response time or the CPU with the greatest ability to handle your type of data.. Obviously floating point is going to point towards Intel ( unless you're dealing with Athalon ). But if you don't use FP, then AMD's K6 line had the shortest pipeline for the bang. A K6-3 is probably your best bet. It has nearly the caching capability of a P-II, comparible integer performance, but lower latency ( especially with branch misses ).
If these calculations are graphics based, again, seperate specialized components are going to be your best bet ( high-end video cards are now parallelized )
If this doesn't suite your needs, and general computation is your requirement. The more cache the better. It doesnt' suite real-time in that it's not deterministic, but, you will achieve more noticable throughput. When Athalon gets it's 2 and 4 Meg caches out the door, I'd vote for that.. But a maxed out Xeon is probably your best bet ( no numbers to back me up.. sorry ).
On the topic of SMP. Deterministic time can not be garunteed. But if we're talking about throughput ( such as live video ) and not response time ( such as an missile tracking system ), AND your application is algorithmically threadible, then 2 or more CPU's will be worth your while. For example, I get nearly dbl my MP3 encoding performance with a dual celerons ( but only when encoding multiple wave files ). If, for example, you were dealing with some non-hardware accelerated video and audio stream, then dual CPU's could probably work to your benifit. ( there's simply no excuse for not having hardware support though ).
Assuming multi-CPU configurations, Athalon has a better setup than the Xeon. And if Athalon could ever get their L2 memory size up to 4 or 8 meg, then you'd have a high-throughput device.
Now, when we introduce price, I'd probably have to say that Athalon is going to win out here. The Xeon just falls out of the picture, value wise.
The coppermine's optimal cache configuration applied to the Athalon would seriously make it the best all around ( minus the deep pipelining/latency ).
The alpha seems to be a good contender everywhere except price. Small simple ordered pipeline. Decent cache size, good bus and SMP features. Problem, of course is price and application availability.
First thanks for the info.
Second, I wasn't wrong in saying that magnets are produced from spinning electrons. You were assuming I exclusively meant extra-atomic circulations. Your saying that these are orbital-scale loops still requires that the electrons are "looping". And it is that circular motion that causes [ through the cross product ] the magnetic field. I wasn't completely sure that the electrons were confined to orbitals, but I remembered a diagram showing naturally occuring loops within the material itself. I presume that the molten metal is slowly solidifying, and the material is orienting itself in the direction of earths magnetic field.
Cool stuff
-Michael
I'm sorry if I presented the notion that there was some natural affiliation towards the right hand. But the fact of the matter is that the cross product produces an effect that can be described by this right hand notation/rule. You would not get the exact same results if you just used your left hand.. Everything would be reversed. What happens is that you choose your polarity such that you can use your right hand to describe it.
Benjaman Franklin arbitrarily chose positive and negative when dealing with electric flow ( specifically dealing with cathodes and anodes ). All the initial theory on electric current was established before we determined that the primary charge carrier was actually negative ( and thus all our descriptions were backwards ). It didn't obviously matter, except that when we draw an arrow pointing in one direction ( implying current flow ), what we really know we mean is that electrons are flowing in the opposite direction.
-Michael
I haven't found the actual paper on this topic ( just the referenced news article ), but this seems to be related to a very well understood property of physics.. Maybe I'm missing something here,but this seems to be centripetal force, and the right hand rule.
In eletro-magnetism, motion of an electric charge produces a magnetic field in the perpendicular direction according the the right hand rule ( make the index finger of your right hand follow the direction of the positive charge and your thumb points into the direction of positive magnetic force ). If you have circular electric motion, then you'll have a circular magnetic field ( and that's how you get permanent magnets ).
Likewise with angular momentum.. Moving an object in a circle produces a perpendicular force ( again following the right hand rule ). They demonstrate it in physics class when they take a bike wheel and balance it on a string after spinning it. The bicycle effect is where the angular momentum produces a sort of virtual mass that fights changes in momentum. It's inertial frame cxauses it to tend to be stationary in space. That is why the bike doesn't fall down at high speeds; leaning to either side would require fighting the inertial frame. This is how gyroscopes work as well. Additionally, they demonstrate the right-hand-rule when they show which direction the balanced tire rotates about the balancing string.
Back in the early 90's I saw a guy build a gyroscopic contraption that spun very rapidly. He balanced it on a string with a counter weight and scale. He weighted the contraption while it was stationary, and then again while it was rotating. The rotation caused it to seem lighter. What is happening is that the perpendicular force was oriented in such a way that it was against gravity. What I believe is not that the device was levitating, but that it was resisting motion against it's angular momentum; e.g. In order to weight the object, it would had to sink.
In this particular experiment only a tiny distinction in weight was measured. Potentially, higher rotational velocities would measure greater distinctions.
Now we're looking at hovering superconductors.. Little or no resistence in the rotation, perfectly balanced. There is little reason to believe that the measurable "weight" of the object would not also seem to be less when rotating. I suspect that if they follow the simple diagrams that we learned in physics that show various shapes and their associated angular momentum, then they'll find ways of making the object weigh even less. For example, an infinitely thin cylinder with a large diameter will have the greatest possible angular momentum ( since all of it's mass will be rotating maximally ). Thus if they took a dense hollow cylinder and managed to make it spin on it's axis ( by virtue of super-conducting properties ), they'll find a great reduction in measurable 'weight'.
Note: I use weight instead of mass even though they are really the same thing just to further my point that they aren't messing with mass, but a measurable net force.
In the general theory of relativity, Einstein says that there is no real gravity, but merely a referential frame of acceleration. He goes on about the curvature of space being the real driving force, but the important concept is that all that we can perceive is the relative net force between two systems. There is no difference between saying that a space ship is defying gravity than if the space ship is imposing a larger, opposing force, than gravity. Observably, the net force is upward. Likewise centripetal force may oppose or simply resist gravitational force and thereby reduce it's effects.. It is not violating any known laws.
Since I believe we are dealing with a resistence to gravitation, and not a pure force that can oppose gravitation, we could never achieve a negative gravitational affect ( just like breaks on a car can never directly cause you to go backwards ). Thus if you want to make your air-plane or space ship lighter for better fuel efficiency, then you're going to have to have the cargo bay spin around very quickly, which might not be a generally desirable thing. An additional problem would occur if you went crazy and spun the device around at a speed approaching c. At this point, you'll have temporal deviations, and additionally, the object will gain mass ( as the energy of the system increases ( kinetic in this case ), so does it's relative mass ). In Practical terms, you'll wind up expending more energy accelerating the object angularly, than you will lifting it.
Now I didn't pay too much attention in class when we initially talked about angular momentum, so I might be wrong.. There may very well be an actual force, and we might be able to harness it like those UFO's we see depicted with spinning discs. But since the crew and cargo are very unlikely to want to endure 50Gs of angular force, your ship's spnning disk is going to have to produce a whole hell of a lot of force to lift not only it's own mass, but that of the entire ship.
In short, I have seen nothing here that suggests anti-gravity. Merely some experimentations that play with weaker forces that are less intuative to our everyday life style.
-Michael
*New versioning representation for modules ( v1.2.3.4 ).
...
:]] character classes supported.
More portible ( though still experimental ) multi-threading model. Contains seperate interpreters per thread. ( old model is still available through compilation flags )
Incrementally better warning messages
-W option to replace -w ( provides even more debugging info )
*Enhancement of POD modules and joining with getopt to allow a help argument to dump the POD directly.
*New "our" keyword, which is like my but for global variables ( replaces "use vars qw(foo bar)" with "our ( $foo, $bar )" ). The advantage is when specifying data-types for global variables.
UTF-8 support ( blah )
More direct use of subroutine attributes
was:
sub foo {
use attrs qw( method locked );
}
Now:
sub foo : method locked {
}
Optimization of qw( foo bar zap ). Now performs split at compile time instead of run-time.
*Auto file-handles
open my $handle, "file.txt";
Generates a file handle automagically.
*open() now accepts a 3'rd argument ( file-mod )
*Binary symantic: 0b01010101010
Better 64 bit support
Optimized sort { block } @data.
Allows sort to act like a function call for the following:
sub foo($$) { $_[0] $_[1] }
And
sort $coderef @array;
allowed
File globs are more consistent.
New "CHECK" block, which acts like the "END" block, except is called at the end of compilation.
pack enhancements included template comments ( like reg-exes )
*Weak references. Thus you can cache objects without fear of memory leaks ( or have c-style trees or doublly linked lists )
exists and delete now function on array elements.
Better typed class support with fields::new().
Reg Ex:
POSIX [[:
More convinient Benchmark module.
Several CPAN modules are now part of the basic distribution.
-Michael
Though I'm not on the team, I think the main reason for their change in notation is because they now can version correctly.
Previously the notation was "%d.%0.3d_%0.3d". This becomes a floating point ( underscores are ignored in numeric values ). It was a hack to allow sub-minor versioning. There is now a new versioning symantic as follows:
"v5.6.7"
The "v" prefix tells it that it's a multi-dot number. Basically it just converts to the equiv asci values ( thus I think you're limited to 255 per dot ).
But we can now say
require v5.6.2.1 if we were so inclined. Thus, the left padded zeros are of no further value.
-Michael