Itanium is basically a new design and it doesn't run much better does it.
Actually, the Itanium is a bueatiful CPU design (from a compiler standpoint). It is very radical, though I wouldn't say ideal or even best-in-class. My only beef, really is that it wastes time, effort, and embarrasment by trying to be x86 compatible. There are actually assembly codes in the official documentation to bother with this obviously failed task.
I don't feel like double checking, but the Itanium was able to achieve remarkable SPEC scores even at lower MHZ. It's Instrs / sec are phenomenal, even for proprietary VLIW (which tends to be better than typical RISC/CISC). It definately has a lot of head-room to grow; they left plenty of room for at least two generational modifications (in the assembly language at least).
While people complain that it leaves too much work for the compiler, there is no reason why a future version couldn't apply the same sort of concurrent instruction profiling that modern x86 CPUs utilize. Thus a compiler could still be stupid (except for the requirement of data-dependency analysis), and produce code that could be made to work better in future CPU releases. Sure in 20 years, the Itanium (if it doesn't die in the mean-time) could be plagued with compatibility issues, but that's nothing that a detail-egnostic architecture wouldn't have to worry about as well.
Motorola and IBM are ahead of Intel when it comes to RISC and 64-bit.
In marketing yes.. IBM, like AMD is pushing their 64bit CPU onto the general masses.. Something Intel isn't publicly considering. The reason the Itanium is expensive is that it's floating-point-centric.. I don't recall the actual percentage but it's like half of the damn core-CPU. The register files are freaking enormous for both inter and FP. To say nothing of the cache-size.
Like IBMs Power4 -> PowerPC, Intel could strip an Itanium down and market to the common man.. BUT, they are not in the most amical environment to do so.. They have to compete against AMD64 now.. Their strategy is either to make an Itanium/Pentium hybrid (cheapest migration strategy is likely to be a literal glue of the two CPUs together with a CPU mode to switch between them), or come up with something completely new, but lose market-share-time-to-market to AMD.
Before Apple decided to adopt 64bit, Intel seemed to push the devalue-64bit-on-the-desktop strategy. AMD was merely looking for a nich, so they were safe. Itanium has been making headway in research institutions (not too sure about production environments, however), so it was theoretically only a matter of time before Itanium could out-seat SUN/Alpha/IBM.
Now people are going to start finding "killer apps" for 64bit environments (high performance integer-based graphics / calculations that previously required slower FP).. I see multi-media and other memory intensive tasks being able to benifit certain nich desktop users today. (And of course just about every server environment). (Imagine doing photoshop filtering of a 500meg image; more than 4 gig of memory could very well be used; especially if multiple images are open simultaneously). And you can bet Apple is going to exploit any advantage of 64bit they can to win market share from the PC line.
So a market will exist for 64bit on the desktop relatively soon.. AMD will have a solution up and ready for the desktop-consumer..
So, once again, and in summary, I feel it is marketing, not technology that is to blame.
A) There is an impedence mismatch between the compiler and the CPU when using x86 assembly.
A.1) The compiler can have a tremendous understanding of how the code can most efficiently be run under most archetectural circumstances, yet has to assume the most common-dumbest implementation (e.g. should it trust hyper-threading, should it trust AMD's or Intels number of virtual/renaming registers). Yess you can recompile dll's/.so's for each projected archetecture but this is rare.
A.2) Compilers must masquerade assembly to trick the CPU into operating more efficiently; this requries very CPU-version-specific coding.
A.3) Newer generations of a CPU will react differently to the masqueraded code, and thus the number of CPU-specific DLL's becomes undesirable.
B) Extra effort on the compiler/developer side is justifiable (Q3 DLL's for each modern CPU, for example). But there is also effort on the CPU side. This effort exists as extra propagation delays (or worse, clock ticks) that are spent guessing how best to translate antiquated x86 code into a form that facilitates modern processing techniques. Stack-based floating point operations for example, explicitly documents backwardly compatible tricks which tell it how to act more like a register file.. There are issues with data-dependency calculations in the CPU such that more than 4/8 general register can be used.
C) There are enormous losses involved in memory alignment of the instructions. One of the most important aspects of RISC is that all instructions are the same size, so no clocks are wasted figuring out what the next instruction is (to say nothing of the next 3 parallel instructions). Having a "RISC-like core" is somewhat meaningless if you still have to have the instruction-align.
D) Like the I-align, there are wasted propagations/clocks decoding old x86 multi-step instructions.. AMD/Intel both refer to the vectored-instructions; those that are so complex that they are special cased and who's performance is sacrificed at the benifit of simpler instructions.. No modern Compiler should ever produce these instructions (since they're rather well known), BUT the CPU must still check for them.
E) Even though the compiler can masquerade code such that the CPU can allocate dozens of registers, there are certain compilation techniques that can only work when you have a large number of addressible registers. Loop-unrolling for example... This is where you have say a nested loop and your inner-most-loop is pretty tight.. If you have dozens of explicitly addressible registers, and the code doesn't have data-dependency issues, then you can have the inner loop only require a single clock tick per iteration; performing all calculations in parallel and into differing registers.
Modern x86 cpu's can automatically register unroll only the most trivial loops (memory copies and some slightly harder things who's data-dependencies don't span too many instructions). Often a nested loop is written one way for clearity, but a compiler can determine that the nesting can and should be reversed for performance.. But if there just aren't enough registers, it is not worth doing so.. The CPU can not make such a dramatic translation behind-the-scenes.
F) calling conventions: easily the biggest hit in performance since this consistutes an ever bigger percentage of modern programming (think VM's where every op-code requires multiple function-calls). Larger explicit register sets allows for more optimal setup/tear-down. Some techniques like SUN or Itanium's rolling windows can also be incredible for diverse-but-not-deep coding styles (again VMs). Even simple Alpha/SGI MIPS constant reg-sets with dedicated in/out registers are enormously helpful in avoiding memory access.
The x86 with it's orignal 4 regs (with 1 dedicated out) requires stack manipulation.. Yes L0/L1 cache concepts help this, but we still have push/pop stack management overhead. Pe
But without giving much thought to it, I would wager that most large-scale software systems are many, many times more complex than cars.
Ok, so how do you explain the Saturn project which got the US to the moon? Worked on the first try. Would you argue that that system was less complex than say a simple internet web server called IIS?
In fact, electronics and mechanics and chemistry is an order of magnitude more "complex" than software development. It is because each and every step requires understanding at least the interactive-qualities of each and every other step. Try taking a look at the design of the pre-digital automatic-transmission system. It uses fluid dynamics that make even my head spin.
The solution to any engineering problem is to build apon prior experience, and reuse proven/reliable components.
Notice that this sounds a lot like modular programming with published APIs. The technology already exists in the computer science world.. But guess what.. We often ignore the basic tenents of module programming.. Make sure your modules work, and don't keep changing them arbitrarily.
Windows is built off an every changing base. It is inherently unstable because of this. It trusts 3'rd party drivers in it's core set of activities. I honestly don't understand why they don't just force all the drivers to run in a user-mode. There is but one and only one issue to this model: performance.. But guess what, MS has been trying to sneak performance hogging features into windows since it's inception.. Reason: requres you to upgrade to newer hardware and thus purchase newer OS.
So long as Windows is in the "we have to wow them every 2 years with something different and exciting", and so long as their application developers are the same as their OS developers, there is practically zero likelyhood that the windows code-base will be robust.
And it's not becauase it's more complex.. It's because it's taken less seriously. Ever see a monopoly of bridge builders?
Sorry to be a repeat post. But a quick summary: 1 MS wants to be a monopoly on software
2 MS needs to squash all other forms of hardware (including hand helds) to accomplish 1.
3 Cross platform stands in the way of 2. Thus must be squashed.
4 In accordance with 1, MS buys/recreates most/all forms of software especially compilers.
5 In accordance with 4, there is a MS java compiler/environment. To facilitate 3, the MS environment squelches cross platform capability through market share of ms-specific tweaks for applets / java applications.
6 SUN doesn't allow MS to enhance the java language (instigated by 4), thereby thwarting MS's efforts to obliterate cross platforming.
7 MS realizes some benifits to a common API (a la MFC / java.*), and sees a benifit to customers if they only have to learn a single API, but can share code between different developer types (simple ASP / VB, corporate C++). Moreoever, COM is too complex on the C++ side. MS's particular solution to a common environment was to literally have a shared execution space between differing programming widgets. This makes a simpler replacement for COM.
8 MS already has a working and somewhat industry proven java-engine, so only a few minor tweaks are needed to make it CRL/.NET. It is likely that the decision to make CRL was in the middle or possibly even the beginning of the MS java initiative.
9 With the release of.NET, they now have a new product with which they can innovate to the same degree as COM/DCOM, or any other nifty MS technology that I've happily ignored for over a decade.
10.NET will run slower and consume more memory than well written c/c++ code, and with.NET (a la java.*), it's likely that people will write highly inefficient C# / VB code which will formulate the bulk of our future application bases on the windows platform. Thus hardware requirements will go through the roof, thereby instigating hardware upgrades. All of which require new licences of MS Windows and all other MS software, thereby continuing More's law.
So there you have it.. A completely logical motivation chain. As you can see, cross-platform is in violation of some of the steps, so you are very likely to see frustrations in the independent porting process. Moreoever, with somethink is centralized as.NET, it's even more likely to have back-doors known only to the MS camp which provides unfair competition. If you make a good IDE (to compete against Visual Studio), or a word process, but use C# (I'm assuming we're not crazy enough to consider VB.NET), then MS can easily add to the next version of.NET some purposeful slowdowns for the competing software... Unlike some previous issues (DR DOS having issues with win 3.x thanks to explicit breaks in their code),.NET can simply forget to activate certain optimizations for competing software at intermittant times with hardly a notice to the developers.
I'm sure you'd agree that ops/sec is also not a very useful metric either, since two CPU's will have vastly different efficiencies of work accomplished for an average instruction.
A CISC "alu [dstMem], [srcMem], [srcMem]" instruction that (when efficiently using a cache) can complete in fewer cycles then the explicitly defined RISC instrs: "ld [src1]", "ld [src2]", "alu", "st [dst]"
due to a reduced load on the register set is an example.
More critically, there are the vector operations, cache-sensative prefetching instructions, etc.
Ultimately, all that you can do is have comparable top-tier compilers render the same application on different platforms and compare the aggregate outputs. Individual enhancements don't generally make or break a CPU; it's the whole shibang; platform, compiler, OS, language-choice, etc.
Actually, you're both correct, and you're both missing something.
Originally, the pipelining was segmented based on the I-Fetch, D-Fetch (register/etc), Exec, Reg-Write-Back, with expensive floating point doing with different timing considerations (externalized or delay-locking multi-stage execution). Then they started sub-dividing each of those stages (especially in CISC archetectures). Now its common to see 15 integer execution pipeline stages - either with shared resources, such that you can only have one divide occuring at any given time (early P-I, P-II, P-III), or with fully independent/concurrent resources (AMD's Athlon).
The addition of the pipelinable-stages between I-Fetch, D-Fetch, exec, and WB was somewhat trivial, because prior to pipelining, there were still seperate events on seperate clock-ticks with inter-stage latching. However, in CPU's with exec-stages that are pipelined, you are introducing additional latches that cause additional undesirable propagation delays.
So a 15 stage integer multiply unit (excluding fetch/WB) has 15 x [guestimating] 4 propagations of additional latency over a single-stage I-unit. If there are resource-based stage-interlocks, or worse data-dependencies, then the pipelining is useless and you're totally hit by the excess propagation delays.
Still, marketing being what it is these days, adding more stages means less propagations per stage, thus less worst-case propagation time, and thus higher clockability (all else being equal; temperature, etc).
The P4, however, compensated by double-clocking the core integer stages, so the number of advertised stages is somewhat misleading.
On a side note, due to the latching in pipelining, you're definately doing more total work for a given instruction. And more importantly, the designers have to think of totally different logic-algorithms to efficiently pipeline than to single-stage. My guess is that the pipelined versions will always be less efficient (especially considering that not all stages will fully utilize their allotted clock-time), and thus there's an additional loss.
Ok, so this supports your post, but here's the part about power/heat.
There are two types of transistors used in modern CPUs (everything past the Pentium). BiPolar and Field-Effect. The CMOS-FET refers to Complementary Metal-Oxide-Semiconductor Field-Effect-Transistor. This acts similarly to a capacitor in that there is a charge and discharge time with little waste current, and power dessipation is typical V=IR, Pwr = I^2 * R. The gate capacitor charge-time is the killer, and what limits switching speed (and thereby clock-speed). Shrinking the area of the capacitor (related to the micron-size stated,.18u,.15u,.13u, etc) means there's less time necessary to charge the capacitors, and thus speeds are increased. (This is only one aspect, and I'm no expert here).
There's another way of reducing switching speed.. Increasing the amount of current running through the wires that ultimately charge/discharge the gate-capacitors. FETs are poor amplifiers, but BiPolar (while more complex and harder to make small) are phenominal. In addition to their complexity, Bipolar also are power hogs. While a FET only consumes power while turning on or off, BiPolars are always on, consuming power (there is current bleeding from the switch). So what often happens is that designers sprinkle BJT's here and there to amplify the current (at the expense of cost/complexity and power-dessipation), and continue using FETs everywhere else.
The bigger and greater number of BJTs that are used, the faster some heavily loaded FET gates will charge and the quicker their switching time will be.
If you up the voltage on a CPU, you're enhancing the amplifier's ability to charge the capacitors and thus gives you more safety-room to up the external clock-speed.
Again, this deviates somewhat from my knowledge domain, but you can often merely co
Well, you get a better video card (though its only artifact of being a newer machine). You get a faster CPU. You get a PC which seems as good as a desktop (which in my opinion is really hard to do). Granted, it takes less for a powerbook to be as good as it's desktop equivalent; more power efficient, more compact due to standardized equipment, bla bla. But a majority still desire/require a PC's application-base. So that alone is a value-boost.
Java is slow if you write a slow program that doesn't respect the platform and language's unique features and quirks, just like any other language (consider the uneven implementations of STL in C++).
See the issue is not really with the JVM, but with the tradeoffs of the language. While it's possible to write somewhat snappy engines like jrocket, or integrate OS features like the windows version, there are certain fundamental issues which can not be handled transparently.
Firstly, hands-off memory management. It's difficult to heuristically discover deterministic memory patterns which would allow inner-loop optimizations. (I'm not even aware of anyone even trying this). The lack of explicit deletions/frees (even if only advisory) is bad in my opinion. It has fostered enormously wasteful memory utilization in enterprise level applications. And when your building blocks aren't efficient, how can you hope to build efficient apps. I use the java-based idea editor, and scrolling or doing a screen refresh requires one or more garbage collections, and I've already given the VM most of the memory on my system.
To a lesser role, the default virtualization of methods is a slow-down. To some degree a JIT can heuristically generate deterministic call-trees to remove the virtualization (e.x. if no subclasses are used/found), but this can be really nasty in the general case. This is much worsened when interfaces are used (method/variable lookups are non-constant in time, to say nothing of the overhead). And lastly, there is a growing trend in using reflection for general processing. This just about throws all optimizations out the window.
While I definately see the value in multiple inheritance (or at least java's interface version), and a language definately needs to dynamically map itself somehow, Sun's particular decisions do not lend themselves to high performance inner-loops; even if hardware accelerated.
Thus the only way to write performant / memory-safe programs is to make all your inner-loops use static/final, and to re-invent the standard libraries where-needed. And this is to say nothing of the libraries that can not be reverse-engineered (GUI, OS-interacting, etc). Though theoretically you could write material using jni, what's the point?
If you need jni to make something usable (in the common case), then the language isn't practical.. jni is for porting or special cases.
See, I agree with you basic point which is that java is a language, and this has little to do with the mapping to the machine-code. Ideally, java can be treated just like c, and written directly to assembly (gjc). However, due to the points above, even gjc has to use wrapper functions for these java-specific idioms, and thus the inner loops are no faster than in a nicely optimized jit.
And as I said above, none of this matters, if the APIs of the language encourage practices which do not scale. SUN learned this about their GUI in 1.0, and I'm seeing more and more performance friendly topics arising. However, much core can't be changed.
I am not completely familiar with.NET's VM, but suspect that they excluded many of the going-forward limitations of java.
I think java is a wonderful language to program in, but all too often, modern software requires a scale that java just can't seem to comfortably live in. And thus I have my doubts about it's future.
but the key is, will they net more money in the long run. Writing software is almost trivial.. Maintaining it is where the costs come in.
Sticking with 3rd party software means that you can plan towards upgrades as you need them. I admit that the disadvantage is, just as this company has experienced, you are at the mercy of what they want to support.
That being said, there's typically a good reason to not support a platform.. If it's too expensive for them to maintain and too few customers, etc. Or having issues keeping working environments going (read the many distributions needing support).
It's a shame, but I don't really blame either this company or the 3'rd party company.
The only caveat is that the higher end RDRAM 800 with the approrpiate chipsets seems to outpace at least their 333mhz DDR counterparts in video games. My guess is that the video games cache just about everything onto the even higher-speed on-board memory (with a fatter pipe to boot). Thus in this case, the only use of main memory for the more taxing portions of gameplay is in migrating chunks of massively sized textures to and from the vid-card. In such a situation (of video-dependent operations), all requests are batched together, and thus bandwidth plays a larger role.
the Incas saw everything unfamiliar as supernatural, having been isolated from other cultures.
It's an interesting perspective, because most European cultures believed similarly; except that more specificly than supernatural, the unfamiliar was considered demonic in nature (Surely God has revealed all that is good and pure to us in our sacred texts).
ok, so have multiple serial channels on the same cable seperated by grounding plates. I agree that having multiple parallel signals produces capacitance issues, but this is the same with all neighboring wires on the motherboard. The only difference is that many adjacent parallel wires will be in sync; but if they are seperate serial channels, then there would be no difference between this an independent connectors.
Having multiple serial channels seems like the most expensive way of going about things, but the side channels could be optional for an end device (or possibly even the chipset). The key point is that parallel is inherently more efficient. And unless the serial is at least n times faster than an n-wide parallel bus, there's little excuse for the transition (though IDE has the side excuse that the wires are cumbersome) Motherboard manufacturers for Buses don't have the same excuse (CPU wiring maybe, but not trivially wired busses).
since when has Christianity not been civilized in your life time?
Our parent's generation still lynched people in the name of "Christianity" and God.
There was a gross perversion of the message of Christianity which empowered some caucasians into believing that only they were important in this world.
Given that this sort of ethnicism and nationalism is inherently anti-social. I can't imagine that the argument uncivilized is too hard to establish.
As far as I can tell, Christianity and Islam and Judaism were never uncivilized by even today's standards. In fact, these religions were the epitomy of civility by effectively defining (over time) what the social norms should be. Judaism/Islam even went so far as to define the hygine/diet of the people.
The issue (and Irony) is that Islam/orthodox Judaism's definitions became the central focus of their lives, and the concept of progress was often at odds with traditional values. Thus hasidic jews still live in a nether-culture, and we tend to view Islamic nations as stagnant and backwards.
But you need not look far to find examples in Christianity. Some sects, (methodists, etc) managed to duplicate the strict social definitions of life as did the Jews and Muslims. Moreover, some puritans of the new world (later the Menonites and Amish) followed in this exact stagnant culture. Even today, advances in genetics, and reproductive health are suppressed by various Christian groups.
The problem I have with all these cultures, is that they seem to accept the social / technological aspect of the day of their foundation, and define it as good enough, then never advance further. Thus Amish have a different technology / culture than Muslims have different '' than Hasidic Jews. In my opinion it's arbitrary and thus exemplarary of it's own futility (what if the Amish waited another 200 years before founding, would they be allowed to eat at McDonalds?)
Granted these groups have the trend that they wish to be self sufficient.. But this sufficiency often involves the help of their community (building bars, etc).. If you so broadly define self-sufficiency, then technically our self-indulgent highly industrialized modern world is self sufficient. (Though the caveat is that each person should have the skills necessary to partake in every action of the community).
Religion == consolidation of human thought / producing like-minded people => greater abundance of people acting in a compatible way => greater aggregate power ==> corruptable power ==> corruptable force ==> tyrranical rulership.
Thus Christianity is an idea (though many over-emphasize its subtleties (namely Catholics (of which I am)), and happens to not expouse war or cruelty, and thus is compatible with civilized society. Judaism / Islam recognize capital punishment (if you consider your peers symbolic of the state), and advocate waring for various causes. But in general are peaceful, and were some original examples of civilized society (as above).
But people will eventually maximize the utility of a device, and consequently all three of these religions have becomes instruments of war, torture, oppression, etc.
My personal opinion is that organized religion is inherently uncivilized given enough time to beuracracize. Sure it's great at it's beginnings, with martyrs, and great stories and pride to pass onto children. New discoveries of ways of life and philosophies. But whenever mysticism is the basis of a culture, it becomes hard to close up loopholes that ambitious people find.
Individual religion is fine, even active egnosticism (uncertain questing for the truth) or atheism, but organizations are inherently abusive, and need to change regularly (Thomas Jefferson philosophy here).
Thankfully Hindi, Budhism, Christianity, Judaism and even Islam have all segmented, giving competition amongst themselve, and providing some semblance of accountability (make outrageous interpretations of ancient scripture, and you'll necessitate a split in your culture).
But isn't error correction supposed to be a function of the link-layer? TCP/IP has error detection with checksums (forget if it's in IP or TCP), but these aren't always used. Even if they did, on most networks, errors are due to collisions, and thus the entire packet is lost, not just a few bytes mid-stream.
In wireless, I'd advocate something like this, but again, only at the link-layer which means it's going to be highly medium specific.
It may be that not everything is predetermined, but if that's not due to free will, then it's simply random.
Why random? Is a finite automata's output random given it's input sequence? If so, then how could we trust the unix tool grep? Does grep choose to report a line even though it wasn't pre-determined? Could there be a malignant deamon inside my computer (possibly a virus) which causes it to fabricate results.. Simply print out a line with the sought word, wherein the line never existed in the input stream? Yes, but the deamon would also have been finit, so if the user knew of it's existance, this too would have been deterministic.. No choices have been made, and the output was not random.
Likewise, in our existance, if we were not free to make choices, we would merely be acting out Newtons concept that given the set of initial conditions of the universe, the entire future would be transparent. Of course, his mechanical view of physics was incomplete and choas does rule at the micro-scopic level, thus initial conditions may not even be enough. But neither of these two views disproves pre-determinism - they merely impeed our ability to predict the future reliably (most notably in weather patterns).
As for: Our nature is important. If you don't have free will, well, why bother? Whatever you think or choose is not your thought or choice
The concept of the choice may not be yours, but the actions will be. The process of choosing is an action, and therefore the process of choosing is yours to own. If the concept of choosing doesn't exist (e.g. if we have no free will), then the non-existant choices are not ours, but we still own the action-process.
We define responsibility to the effect that we accepting punishment / retribution / reperations for our destructive actions, and thus pre-empt them by avoiding the destructiveness in the first place.
If your person [chooses to] takes actions that are destructive (in essence, not bothering to obey annoying laws), then you will eventually be dealt with. Just like you would not just sit and let somebody beat you up indefinately.. Eventually you will run or fight back. Thus our intellect (which is fundamentally no different than that of an animal) will act so as to avoid these understood negative outcomes. A dog will avoid a harful person, a cat will remember a generous household, a bee will remember a pollenous flower.
Note that the above actions merely require intellect, not free will. The intellect is little more than a memory system which can store and process inputs and trigger responses; some creature have greater analytical power than others. Dogs, for example can sense and analyze smell, and cats can sense and analyze light better than we.
If you were to build a world simulation, would you make its inhabitants religious?
This is interesting for two reasons. One, the point of your asking.. Do we pre-judge our simulants as disobediant or dispairing, or in other words, is it possible to produce naturally happy-go-lucky simulants. And two, is philosophy/theology a natural process of intelligent beings. Since theology is a slowly conjured externalization of philosophy, and philosophy is an intellectual attempt at understanding our environment. Is it possible to produce a world of thinkers (still possibly pre-determined) that can avoid concluding an extra-world or extra-existance.
Define free will? Is it the ability to do as you wish? This can't be true because the physical world impedes your activities. You can't travel as quickly as you wish, nor break as many laws as you wish indefinitely.
I would refine this to mean, given a set of instantaneous (time dependent) options, you may choose which-ever one you wish.. BUT, these options are not infinite nor continuous. Thus the physical world around you is limiting your choice. You are molded by your environment necessarily. Moreover, your character will likely be limited in it's sophistication so that it can't see many of the more desirable options. Thus there is a definite degree of pre-determination. Not only do we have few choices in life (which are given to us by the fate of historcal progression), but we are pre-determined (through biology and our own past) as to which choices we are capable of making.
While this still leaves us with an enormous responsibility (in terms of a multitude of diametricly opposed options), I'm not convinced that we are capable of making any decision other than what we were meant to; meaning what our mechanical biology is statistically configured to do. If our brain is nothing more than a mechanical/electronic switch-board which makes value judgements based purely on thresholds of triggering, and those tresholds are altered by periodic chemical states (moods), then we are deterministicly given our past (our prevoius moods and experiences) and our present environment will merely be inputs into this switchboard - the outcome would merely be mechanical. Granted this is only an assumption, but science slowly providing more and more evidence of this.
For example, a person biologically prone to aggression (which isn't normal for a person), when presented with an irratable peer, and absence of calmer people in the surrounding environment to disuade him, is pre-determined + environmentally encouraged to choose to fight. Without a possible alternative, this choice is not freely willed.
For these extreme cases, I do not believe we have much free will.. In softer cases (should I buy coke or pepsi, and thus macro-scopically determine the economic fate of our country), I'm willing to give to the argument of free-will. It is plausible that in the chaotic interaction at the atomic / quantum level, our thresholds (when presented with a nearly 50/50 point) may or may not trigger, thereby altering our decision. In this critical chaotic region, our personality (and the coriolis effect of the earth, solar system and universe) may all come into play. Any concept of a soul, or weighted simulation may make the bizarness of life happen.
But the possibility of this does not prove it's existance..
My point finally being, free will is by no means logically sound, though it is not disproven either.
As you look into parallel mirrors, you can never see the infinity because your head is in the way. In other words, there is no accurate simulation of reality.
Ahh, but you forget planks limiting constant and special relativity. There is no such thing as infinity for two reasons. You can only get as small as allowed by the plank scale - period. And you can not experience further than the speed of light inside your realm of existance (meaning a life-time times the speed of light during that time).
The reflective mirrors will eventually discretize into photons, afterwhich you will not achieve any greater resolution.. The reflected image will degrade in quality accordingly.
So it's entirely possible to define the computing power of the "user" domain as the particular value of plank and the speed of light in a vacume.
See my other article for an understanding of how you need not even require more than modern computing power to simulate a universe with even these constraints.
I will, however, concede that your use of the term "accurate" complexifies the situation. But I argue that general relativity applies. Accurate only needs to be true in the eyes of the beholder. Plus there is no concept of an absolute frame of reference, and therefore "accurate" can not properly be realized.
not having read the article yet, it seems trivial to simulate a universe. Recall from physics how we learn about our universe. We don't start off with atoms, we start off with macro-scopic relationship-equations. Ideal-gass law, simple voltage-current relationships, ideal charge field/force laws, action/reaction, momentum, etc.
These are all macroscopic approximations of what is really going on. They are inaccurate as you delve deeper into the inner-space. But the key is that depending on what you are trying to simulate, you have no need to waste computation time on distant objects; merely to generalize them (until and unless they ever become near objects). This drastically saves computation time.
If your focus is a single human being, then the rest of the universe can be generalized, including all other human beings (hurd mentality can apply). Thus it may very well be less computation time to create completely seperate universes for each and every focal point. All other humans/animals are statistically/generically modeled, and no two humans will experience quite the same universe. This doesn't hurt anything since two separate models will never truely interact, so synchronization is unnecessary.
Still, if interaction is necessary, we have all sorts of common phenomena which could explain the discrepency.. Memory-loss (memory uncertainty), mysticism, deja-vous (for use with resyncing timed events). So you could independently model two universes, then merge them together for some time period (possibly reseperating them later on).
To minimize the negative effects of merging models, the same formulas would generally have to be applied. Truely macro-scopic events (extra-planetary) would probably all share a common model (since there's no point in duplicating this aspect).
The main point is that it's likely to be possible even today to provide enough processing power to render an entire population - especially since from inside the simulation, you can have no way of telling how many focal points there are.. You can safely assume that you are truely the center of the universe (reminds me of when Zaphod Bebblebrox entered entered the chamber of dispair in the hitchhickers guide).
Theologically, Gods and deamons could serve as control venue's. As law and order persist, their need is deminished and localized. The concept of the afterlife, however, may be very real, insofar as your particular model is considered valuable.
While I agree that the laws of physics may indeed be different in the proposed "user" world (to use a tron phrase), the laws of scale should be no less applicable. Meaning that even in a logarithmicly scalable world (or possibly even an inversely factorial world), there are still limits. The only thing it effects is the size of the individual models. (And thereby it's depth)
One important aspect, however, is that since each model focuses around a small truely interactive environment (determined by available processing power), then it's entirely possible to have a beowolf cluster. Each node is mostly independent of other nodes (insofar as very little information is exchanged). Information exchanges are like the temporary merging of seperate models. While a given machine is only so powerful, you can arbitrarily limit it's complexity such that you can cheaply produce hundreds, thousands or millions of these machines.
And Michael Gilbert says, "As a monopoly, Microsoft's below-market-price distribution of software might very well be a form of illegal competition for a particular market." Presumably he's indulging in a bit of theoretical speculation, and doesn't really lack the sense to foresee such a legal claim promptly going down in a ball of flames.
I can't tell if you're being synical or just naive. Companies are successfully sued for underselling products all the time. Anti-trust is based on the idea that you can use your monopoly power to enter into new markets. Namely, if you have a monopoly in the business office-software, and you don't in non-profit or educational sectors, but there are pre-existing competition in those markets, then you undersell your product (using your excess profits from other markets) to stamp out competition. Thereafter raising prices back up; once the barrier-to-entry is high enough. This is anti-trust clear and simple.
Pre-speculating that they will raise prices again may or may not win in a court of law, but it hardly takes clearvoyance to see this pattern in previous MS activities.
Moreoever, MS is already in declared violation of anti-trust. It would not be very hard to legally apply pressure in this case.
It is illegal to selectively sell products at different prices. MS was found guilty of various unfair contracts on massive scales to PC vendors for licences. There are bizzar cases where the government turns a blind eye towards favoritism - namely senior discounts, educational / non-profit / foreign purposes. Basically the US government turns a blind eye when it suites themselves.
The issue, however, is that MS is internally being given cart blanche negotiating power to sell to whomever they can at whatever level they can. This is stright favoritism transactionalism. And while we see this in many markets (auto sales, etc), for some reason it's illegal in super-markets and department stores, and thus I speculate that MS is in violation. IANAL, so please somebody enlighten me if there is somehow a method to this madness.
thers will claim Java is a good example, but it's a bad one, because despite being statically typed it causes typing errors (from casts) and null-pointer exceptions (ick).
True, but we'll see if generics resolves this in java 1.5. I'm of the opinion that you should NEVER explicitly type-cast, and generics get us closer to that goal.
I always hate deciding who to reply to, knowing that most likely only the replyee will read the post.
In any case, what is being described in these two posts is a simple combinational logic machine.
I couldn't get a feel if either of your posters knew of their existance. I'll summarize by saying:
* For combinational logic machines (reprogrammable-FPGA or write-once-ASIC), the "instructions" are provided to the machine at design time, not at run-time. They embed themselves as bus interconnects such that data exists as signal lines (possibly initiated from a memory-latch), and propagates through logic-modules (of varying complexity contingent apon the feature-set). Thus the original poster was correct in his assessment of time-critical / bandwith-sensative design. A given program requires a specific timing sequence (unless latches are fully utilized), and a minimum bandwith (number of interconnects). Thus it may or may not run successfully on a given piece of hardware.
* As you pointed out, this sort of technology is not new. All CPU's are designed with a similar approach (though there is greater freedom in bandwidth / substrate-module-complexity etc).
* Graphics cards, specialized chess machines, etc. all use this sort of logic-level programming today with over-the-counter resources.
I don't have a problem with them being a for-profit company.. And I don't mind that they have to cut corners here and there, and are ultimately trying to over-bundle things such that the average consumer has to pay more than they really want to. I am somewhat disturbed by the fact that consumers "have" to make these purchases due to peer compatibility. But most importantly (and relevant to this article) is that we are somewhat forced to use their software (at whatever price we can afford), and then are subject to a lack of quality control.. Part of corner-cutting is to get a product out the door before it's bug-list is even resolved (to say nothing of the shere number of undiscovered bugs).
As for bloat-ware, I was focusing on the propensity of new code to be buggy. Thus the policy of adding every feature they can think of (so as to suit every type of customer) directly affects their ability to perform quality control - or more correctly, each new feature "should" increase the testing time by some amount.. Moreoever, the relationship between the amount of new features and the required time to test is non-linear (complexity grows somewhat exponentially).
Thus, the marginal utility of each additional feature decreases. But the marginal price for each new feature remains the same.. But from the above, the marginal quality necessarily must decrease (unless, of course, the marginal time to release goes up; which it won't).
win2k was called feature bloated; I've no doubt that win2k3 is the same. Each new sever-level feature is a new security risk, a new stability risk, and a potential unwanted cost.
Finally, about your statement that modern machines have plenty of excess HD and CPU resources, remember the policy of wintel. Intel Makes a faster CPU, then MS adds bloatware which necessarily slows the system down (greater graphical load for the desktop, slower MFC, etc). The slowdown means that people/businesses are encouraged to repurchase new machines. Intel sells more CPU's, and get this, MS sells more windows licenses. So while whenever an application becomes bloated, it encourages a whole new purchase arena.
Rest assured that 3GHZ is no safe harbor.. And while you as a consumer may not mind updating periodically to keep-up-with-the-joneses, businesses are less than thrilled to deprecate hardware/licenses.
I'm not shy about criticizing MS when appropriate, but to come from Windows for Workgroups to XP in 10 years is pretty impressive, especially for a company of its size.
I honestly can't tell if you're being sarchastic. 10 years to make an unstable piece of software less unstable and more bloated impresses you?
Stable Enterprise-level product lines have been created from scratch in less than 5 years, and MS's inability to get past a horrific security/stability record with the largest software developer resources on the planet (hell, the largest "resources" on the planet) does little to impress me.
That Bill Gates has finally announced that it's resources will be used to correct existing code is good (though probably just a show-boat). The issue is that they honestly value bloatware over quality.. Bloat means more to charge for. Unfortunately with high turnover rates, they don't have time to make stable software.... Other companies constantly build apon pre-existing bases, such that bugs can be found and corrected over time; new features are bug-prone, but the core becomes trust-worthy. This concept is decades old... Yet MS assumes that they can throw developers and "good software practices" at the problem and reinvent the wheel every 5 years or so.
Moreoever, the only justification to reinvent the wheel is to drop compatibility with their crappy old software base.
Look at Direct X, with it's 8,9,10 releases in less than 8 years. How can you trust that a video card driver (which now has operated at super-user levels for a while now) has had a chance to stableize? ATI has a horrible reputation for driver quality, but I don't blame them (much). They, like MS have bloat-ware concepts (put everything into their cards). But the number of features they provide hasn't grown too quickly.. But the platform for which they must constantly port, has.
Moreoever, I can't comprehend how simple HTML tags can be allowed to crash the browser. Parsing is a trivial operation. Are there syntaxes in c that core-dump a compiler? For a run-time environment (VB-SCRIPT / JavaScript), sure, crashes might be evident; though this is a sign of a poorly constructed scripting language (perl crashes if you "goto" a label in another subroutine (via the "last" keyword)). But a browser can be defended by saying the definition of the scripting language is inferior.
While this is a trivial bug, it just goes as proof of a design mentality that just isn't compatible with robust software.
Slashdot Mirror
Itanium is basically a new design and it doesn't run much better does it.
Actually, the Itanium is a bueatiful CPU design (from a compiler standpoint). It is very radical, though I wouldn't say ideal or even best-in-class. My only beef, really is that it wastes time, effort, and embarrasment by trying to be x86 compatible. There are actually assembly codes in the official documentation to bother with this obviously failed task.
I don't feel like double checking, but the Itanium was able to achieve remarkable SPEC scores even at lower MHZ. It's Instrs / sec are phenomenal, even for proprietary VLIW (which tends to be better than typical RISC/CISC). It definately has a lot of head-room to grow; they left plenty of room for at least two generational modifications (in the assembly language at least).
While people complain that it leaves too much work for the compiler, there is no reason why a future version couldn't apply the same sort of concurrent instruction profiling that modern x86 CPUs utilize. Thus a compiler could still be stupid (except for the requirement of data-dependency analysis), and produce code that could be made to work better in future CPU releases. Sure in 20 years, the Itanium (if it doesn't die in the mean-time) could be plagued with compatibility issues, but that's nothing that a detail-egnostic architecture wouldn't have to worry about as well.
Motorola and IBM are ahead of Intel when it comes to RISC and 64-bit.
In marketing yes.. IBM, like AMD is pushing their 64bit CPU onto the general masses.. Something Intel isn't publicly considering. The reason the Itanium is expensive is that it's floating-point-centric.. I don't recall the actual percentage but it's like half of the damn core-CPU. The register files are freaking enormous for both inter and FP. To say nothing of the cache-size.
Like IBMs Power4 -> PowerPC, Intel could strip an Itanium down and market to the common man.. BUT, they are not in the most amical environment to do so.. They have to compete against AMD64 now.. Their strategy is either to make an Itanium/Pentium hybrid (cheapest migration strategy is likely to be a literal glue of the two CPUs together with a CPU mode to switch between them), or come up with something completely new, but lose market-share-time-to-market to AMD.
Before Apple decided to adopt 64bit, Intel seemed to push the devalue-64bit-on-the-desktop strategy. AMD was merely looking for a nich, so they were safe. Itanium has been making headway in research institutions (not too sure about production environments, however), so it was theoretically only a matter of time before Itanium could out-seat SUN/Alpha/IBM.
Now people are going to start finding "killer apps" for 64bit environments (high performance integer-based graphics / calculations that previously required slower FP).. I see multi-media and other memory intensive tasks being able to benifit certain nich desktop users today. (And of course just about every server environment). (Imagine doing photoshop filtering of a 500meg image; more than 4 gig of memory could very well be used; especially if multiple images are open simultaneously). And you can bet Apple is going to exploit any advantage of 64bit they can to win market share from the PC line.
So a market will exist for 64bit on the desktop relatively soon.. AMD will have a solution up and ready for the desktop-consumer..
So, once again, and in summary, I feel it is marketing, not technology that is to blame.
Aren't the modern chips RISC underneath anyway?
A) There is an impedence mismatch between the compiler and the CPU when using x86 assembly.
A.1) The compiler can have a tremendous understanding of how the code can most efficiently be run under most archetectural circumstances, yet has to assume the most common-dumbest implementation (e.g. should it trust hyper-threading, should it trust AMD's or Intels number of virtual/renaming registers). Yess you can recompile dll's/.so's for each projected archetecture but this is rare.
A.2) Compilers must masquerade assembly to trick the CPU into operating more efficiently; this requries very CPU-version-specific coding.
A.3) Newer generations of a CPU will react differently to the masqueraded code, and thus the number of CPU-specific DLL's becomes undesirable.
B) Extra effort on the compiler/developer side is justifiable (Q3 DLL's for each modern CPU, for example). But there is also effort on the CPU side. This effort exists as extra propagation delays (or worse, clock ticks) that are spent guessing how best to translate antiquated x86 code into a form that facilitates modern processing techniques. Stack-based floating point operations for example, explicitly documents backwardly compatible tricks which tell it how to act more like a register file.. There are issues with data-dependency calculations in the CPU such that more than 4/8 general register can be used.
C) There are enormous losses involved in memory alignment of the instructions. One of the most important aspects of RISC is that all instructions are the same size, so no clocks are wasted figuring out what the next instruction is (to say nothing of the next 3 parallel instructions). Having a "RISC-like core" is somewhat meaningless if you still have to have the instruction-align.
D) Like the I-align, there are wasted propagations/clocks decoding old x86 multi-step instructions.. AMD/Intel both refer to the vectored-instructions; those that are so complex that they are special cased and who's performance is sacrificed at the benifit of simpler instructions.. No modern Compiler should ever produce these instructions (since they're rather well known), BUT the CPU must still check for them.
E) Even though the compiler can masquerade code such that the CPU can allocate dozens of registers, there are certain compilation techniques that can only work when you have a large number of addressible registers. Loop-unrolling for example... This is where you have say a nested loop and your inner-most-loop is pretty tight.. If you have dozens of explicitly addressible registers, and the code doesn't have data-dependency issues, then you can have the inner loop only require a single clock tick per iteration; performing all calculations in parallel and into differing registers.
Modern x86 cpu's can automatically register unroll only the most trivial loops (memory copies and some slightly harder things who's data-dependencies don't span too many instructions). Often a nested loop is written one way for clearity, but a compiler can determine that the nesting can and should be reversed for performance.. But if there just aren't enough registers, it is not worth doing so.. The CPU can not make such a dramatic translation behind-the-scenes.
F) calling conventions: easily the biggest hit in performance since this consistutes an ever bigger percentage of modern programming (think VM's where every op-code requires multiple function-calls). Larger explicit register sets allows for more optimal setup/tear-down. Some techniques like SUN or Itanium's rolling windows can also be incredible for diverse-but-not-deep coding styles (again VMs). Even simple Alpha/SGI MIPS constant reg-sets with dedicated in/out registers are enormously helpful in avoiding memory access.
The x86 with it's orignal 4 regs (with 1 dedicated out) requires stack manipulation.. Yes L0/L1 cache concepts help this, but we still have push/pop stack management overhead. Pe
But without giving much thought to it, I would wager that most large-scale software systems are many, many times more complex than cars.
Ok, so how do you explain the Saturn project which got the US to the moon? Worked on the first try. Would you argue that that system was less complex than say a simple internet web server called IIS?
In fact, electronics and mechanics and chemistry is an order of magnitude more "complex" than software development. It is because each and every step requires understanding at least the interactive-qualities of each and every other step. Try taking a look at the design of the pre-digital automatic-transmission system. It uses fluid dynamics that make even my head spin.
The solution to any engineering problem is to build apon prior experience, and reuse proven/reliable components.
Notice that this sounds a lot like modular programming with published APIs. The technology already exists in the computer science world.. But guess what.. We often ignore the basic tenents of module programming.. Make sure your modules work, and don't keep changing them arbitrarily.
Windows is built off an every changing base. It is inherently unstable because of this. It trusts 3'rd party drivers in it's core set of activities. I honestly don't understand why they don't just force all the drivers to run in a user-mode. There is but one and only one issue to this model: performance.. But guess what, MS has been trying to sneak performance hogging features into windows since it's inception.. Reason: requres you to upgrade to newer hardware and thus purchase newer OS.
So long as Windows is in the "we have to wow them every 2 years with something different and exciting", and so long as their application developers are the same as their OS developers, there is practically zero likelyhood that the windows code-base will be robust.
And it's not becauase it's more complex.. It's because it's taken less seriously. Ever see a monopoly of bridge builders?
Sorry to be a repeat post. But a quick summary:
.NET, they now have a new product with which they can innovate to the same degree as COM/DCOM, or any other nifty MS technology that I've happily ignored for over a decade.
.NET will run slower and consume more memory than well written c/c++ code, and with .NET (a la java.*), it's likely that people will write highly inefficient C# / VB code which will formulate the bulk of our future application bases on the windows platform. Thus hardware requirements will go through the roof, thereby instigating hardware upgrades. All of which require new licences of MS Windows and all other MS software, thereby continuing More's law.
.NET, it's even more likely to have back-doors known only to the MS camp which provides unfair competition. If you make a good IDE (to compete against Visual Studio), or a word process, but use C# (I'm assuming we're not crazy enough to consider VB.NET), then MS can easily add to the next version of .NET some purposeful slowdowns for the competing software... Unlike some previous issues (DR DOS having issues with win 3.x thanks to explicit breaks in their code), .NET can simply forget to activate certain optimizations for competing software at intermittant times with hardly a notice to the developers.
1 MS wants to be a monopoly on software
2 MS needs to squash all other forms of hardware (including hand helds) to accomplish 1.
3 Cross platform stands in the way of 2. Thus must be squashed.
4 In accordance with 1, MS buys/recreates most/all forms of software especially compilers.
5 In accordance with 4, there is a MS java compiler/environment. To facilitate 3, the MS environment squelches cross platform capability through market share of ms-specific tweaks for applets / java applications.
6 SUN doesn't allow MS to enhance the java language (instigated by 4), thereby thwarting MS's efforts to obliterate cross platforming.
7 MS realizes some benifits to a common API (a la MFC / java.*), and sees a benifit to customers if they only have to learn a single API, but can share code between different developer types (simple ASP / VB, corporate C++). Moreoever, COM is too complex on the C++ side. MS's particular solution to a common environment was to literally have a shared execution space between differing programming widgets. This makes a simpler replacement for COM.
8 MS already has a working and somewhat industry proven java-engine, so only a few minor tweaks are needed to make it CRL/.NET. It is likely that the decision to make CRL was in the middle or possibly even the beginning of the MS java initiative.
9 With the release of
10
So there you have it.. A completely logical motivation chain. As you can see, cross-platform is in violation of some of the steps, so you are very likely to see frustrations in the independent porting process. Moreoever, with somethink is centralized as
I'm sure you'd agree that ops/sec is also not a very useful metric either, since two CPU's will have vastly different efficiencies of work accomplished for an average instruction.
A CISC "alu [dstMem], [srcMem], [srcMem]" instruction that (when efficiently using a cache) can complete in fewer cycles then the explicitly defined RISC instrs:
"ld [src1]",
"ld [src2]",
"alu",
"st [dst]"
due to a reduced load on the register set is an example.
More critically, there are the vector operations, cache-sensative prefetching instructions, etc.
Ultimately, all that you can do is have comparable top-tier compilers render the same application on different platforms and compare the aggregate outputs. Individual enhancements don't generally make or break a CPU; it's the whole shibang; platform, compiler, OS, language-choice, etc.
Actually, you're both correct, and you're both missing something.
.18u, .15u, .13u, etc) means there's less time necessary to charge the capacitors, and thus speeds are increased. (This is only one aspect, and I'm no expert here).
Originally, the pipelining was segmented based on the I-Fetch, D-Fetch (register/etc), Exec, Reg-Write-Back, with expensive floating point doing with different timing considerations (externalized or delay-locking multi-stage execution). Then they started sub-dividing each of those stages (especially in CISC archetectures). Now its common to see 15 integer execution pipeline stages - either with shared resources, such that you can only have one divide occuring at any given time (early P-I, P-II, P-III), or with fully independent/concurrent resources (AMD's Athlon).
The addition of the pipelinable-stages between I-Fetch, D-Fetch, exec, and WB was somewhat trivial, because prior to pipelining, there were still seperate events on seperate clock-ticks with inter-stage latching. However, in CPU's with exec-stages that are pipelined, you are introducing additional latches that cause additional undesirable propagation delays.
So a 15 stage integer multiply unit (excluding fetch/WB) has 15 x [guestimating] 4 propagations of additional latency over a single-stage I-unit. If there are resource-based stage-interlocks, or worse data-dependencies, then the pipelining is useless and you're totally hit by the excess propagation delays.
Still, marketing being what it is these days, adding more stages means less propagations per stage, thus less worst-case propagation time, and thus higher clockability (all else being equal; temperature, etc).
The P4, however, compensated by double-clocking the core integer stages, so the number of advertised stages is somewhat misleading.
On a side note, due to the latching in pipelining, you're definately doing more total work for a given instruction. And more importantly, the designers have to think of totally different logic-algorithms to efficiently pipeline than to single-stage. My guess is that the pipelined versions will always be less efficient (especially considering that not all stages will fully utilize their allotted clock-time), and thus there's an additional loss.
Ok, so this supports your post, but here's the part about power/heat.
There are two types of transistors used in modern CPUs (everything past the Pentium). BiPolar and Field-Effect. The CMOS-FET refers to Complementary Metal-Oxide-Semiconductor Field-Effect-Transistor. This acts similarly to a capacitor in that there is a charge and discharge time with little waste current, and power dessipation is typical V=IR, Pwr = I^2 * R. The gate capacitor charge-time is the killer, and what limits switching speed (and thereby clock-speed). Shrinking the area of the capacitor (related to the micron-size stated,
There's another way of reducing switching speed.. Increasing the amount of current running through the wires that ultimately charge/discharge the gate-capacitors. FETs are poor amplifiers, but BiPolar (while more complex and harder to make small) are phenominal. In addition to their complexity, Bipolar also are power hogs. While a FET only consumes power while turning on or off, BiPolars are always on, consuming power (there is current bleeding from the switch). So what often happens is that designers sprinkle BJT's here and there to amplify the current (at the expense of cost/complexity and power-dessipation), and continue using FETs everywhere else.
The bigger and greater number of BJTs that are used, the faster some heavily loaded FET gates will charge and the quicker their switching time will be.
If you up the voltage on a CPU, you're enhancing the amplifier's ability to charge the capacitors and thus gives you more safety-room to up the external clock-speed.
Again, this deviates somewhat from my knowledge domain, but you can often merely co
Well, you get a better video card (though its only artifact of being a newer machine). You get a faster CPU. You get a PC which seems as good as a desktop (which in my opinion is really hard to do). Granted, it takes less for a powerbook to be as good as it's desktop equivalent; more power efficient, more compact due to standardized equipment, bla bla. But a majority still desire/require a PC's application-base. So that alone is a value-boost.
Java is slow if you write a slow program that doesn't respect the platform and language's unique features and quirks, just like any other language (consider the uneven implementations of STL in C++).
.NET's VM, but suspect that they excluded many of the going-forward limitations of java.
See the issue is not really with the JVM, but with the tradeoffs of the language. While it's possible to write somewhat snappy engines like jrocket, or integrate OS features like the windows version, there are certain fundamental issues which can not be handled transparently.
Firstly, hands-off memory management. It's difficult to heuristically discover deterministic memory patterns which would allow inner-loop optimizations. (I'm not even aware of anyone even trying this). The lack of explicit deletions/frees (even if only advisory) is bad in my opinion. It has fostered enormously wasteful memory utilization in enterprise level applications. And when your building blocks aren't efficient, how can you hope to build efficient apps. I use the java-based idea editor, and scrolling or doing a screen refresh requires one or more garbage collections, and I've already given the VM most of the memory on my system.
To a lesser role, the default virtualization of methods is a slow-down. To some degree a JIT can heuristically generate deterministic call-trees to remove the virtualization (e.x. if no subclasses are used/found), but this can be really nasty in the general case. This is much worsened when interfaces are used (method/variable lookups are non-constant in time, to say nothing of the overhead). And lastly, there is a growing trend in using reflection for general processing. This just about throws all optimizations out the window.
While I definately see the value in multiple inheritance (or at least java's interface version), and a language definately needs to dynamically map itself somehow, Sun's particular decisions do not lend themselves to high performance inner-loops; even if hardware accelerated.
Thus the only way to write performant / memory-safe programs is to make all your inner-loops use static/final, and to re-invent the standard libraries where-needed. And this is to say nothing of the libraries that can not be reverse-engineered (GUI, OS-interacting, etc). Though theoretically you could write material using jni, what's the point?
If you need jni to make something usable (in the common case), then the language isn't practical.. jni is for porting or special cases.
See, I agree with you basic point which is that java is a language, and this has little to do with the mapping to the machine-code. Ideally, java can be treated just like c, and written directly to assembly (gjc). However, due to the points above, even gjc has to use wrapper functions for these java-specific idioms, and thus the inner loops are no faster than in a nicely optimized jit.
And as I said above, none of this matters, if the APIs of the language encourage practices which do not scale. SUN learned this about their GUI in 1.0, and I'm seeing more and more performance friendly topics arising. However, much core can't be changed.
I am not completely familiar with
I think java is a wonderful language to program in, but all too often, modern software requires a scale that java just can't seem to comfortably live in. And thus I have my doubts about it's future.
but the key is, will they net more money in the long run. Writing software is almost trivial.. Maintaining it is where the costs come in.
Sticking with 3rd party software means that you can plan towards upgrades as you need them. I admit that the disadvantage is, just as this company has experienced, you are at the mercy of what they want to support.
That being said, there's typically a good reason to not support a platform.. If it's too expensive for them to maintain and too few customers, etc. Or having issues keeping working environments going (read the many distributions needing support).
It's a shame, but I don't really blame either this company or the 3'rd party company.
The only caveat is that the higher end RDRAM 800 with the approrpiate chipsets seems to outpace at least their 333mhz DDR counterparts in video games. My guess is that the video games cache just about everything onto the even higher-speed on-board memory (with a fatter pipe to boot). Thus in this case, the only use of main memory for the more taxing portions of gameplay is in migrating chunks of massively sized textures to and from the vid-card. In such a situation (of video-dependent operations), all requests are batched together, and thus bandwidth plays a larger role.
the Incas saw everything unfamiliar as supernatural, having been isolated from other cultures.
It's an interesting perspective, because most European cultures believed similarly; except that more specificly than supernatural, the unfamiliar was considered demonic in nature (Surely God has revealed all that is good and pure to us in our sacred texts).
ok, so have multiple serial channels on the same cable seperated by grounding plates. I agree that having multiple parallel signals produces capacitance issues, but this is the same with all neighboring wires on the motherboard. The only difference is that many adjacent parallel wires will be in sync; but if they are seperate serial channels, then there would be no difference between this an independent connectors.
Having multiple serial channels seems like the most expensive way of going about things, but the side channels could be optional for an end device (or possibly even the chipset). The key point is that parallel is inherently more efficient. And unless the serial is at least n times faster than an n-wide parallel bus, there's little excuse for the transition (though IDE has the side excuse that the wires are cumbersome) Motherboard manufacturers for Buses don't have the same excuse (CPU wiring maybe, but not trivially wired busses).
since when has Christianity not been civilized in your life time?
Our parent's generation still lynched people in the name of "Christianity" and God.
There was a gross perversion of the message of Christianity which empowered some caucasians into believing that only they were important in this world.
Given that this sort of ethnicism and nationalism is inherently anti-social. I can't imagine that the argument uncivilized is too hard to establish.
As far as I can tell, Christianity and Islam and Judaism were never uncivilized by even today's standards. In fact, these religions were the epitomy of civility by effectively defining (over time) what the social norms should be. Judaism/Islam even went so far as to define the hygine/diet of the people.
The issue (and Irony) is that Islam/orthodox Judaism's definitions became the central focus of their lives, and the concept of progress was often at odds with traditional values. Thus hasidic jews still live in a nether-culture, and we tend to view Islamic nations as stagnant and backwards.
But you need not look far to find examples in Christianity. Some sects, (methodists, etc) managed to duplicate the strict social definitions of life as did the Jews and Muslims. Moreover, some puritans of the new world (later the Menonites and Amish) followed in this exact stagnant culture. Even today, advances in genetics, and reproductive health are suppressed by various Christian groups.
The problem I have with all these cultures, is that they seem to accept the social / technological aspect of the day of their foundation, and define it as good enough, then never advance further. Thus Amish have a different technology / culture than Muslims have different '' than Hasidic Jews. In my opinion it's arbitrary and thus exemplarary of it's own futility (what if the Amish waited another 200 years before founding, would they be allowed to eat at McDonalds?)
Granted these groups have the trend that they wish to be self sufficient.. But this sufficiency often involves the help of their community (building bars, etc).. If you so broadly define self-sufficiency, then technically our self-indulgent highly industrialized modern world is self sufficient. (Though the caveat is that each person should have the skills necessary to partake in every action of the community).
Religion == consolidation of human thought / producing like-minded people => greater abundance of people acting in a compatible way => greater aggregate power ==> corruptable power ==> corruptable force ==> tyrranical rulership.
Thus Christianity is an idea (though many over-emphasize its subtleties (namely Catholics (of which I am)), and happens to not expouse war or cruelty, and thus is compatible with civilized society. Judaism / Islam recognize capital punishment (if you consider your peers symbolic of the state), and advocate waring for various causes. But in general are peaceful, and were some original examples of civilized society (as above).
But people will eventually maximize the utility of a device, and consequently all three of these religions have becomes instruments of war, torture, oppression, etc.
My personal opinion is that organized religion is inherently uncivilized given enough time to beuracracize. Sure it's great at it's beginnings, with martyrs, and great stories and pride to pass onto children. New discoveries of ways of life and philosophies. But whenever mysticism is the basis of a culture, it becomes hard to close up loopholes that ambitious people find.
Individual religion is fine, even active egnosticism (uncertain questing for the truth) or atheism, but organizations are inherently abusive, and need to change regularly (Thomas Jefferson philosophy here).
Thankfully Hindi, Budhism, Christianity, Judaism and even Islam have all segmented, giving competition amongst themselve, and providing some semblance of accountability (make outrageous interpretations of ancient scripture, and you'll necessitate a split in your culture).
But isn't error correction supposed to be a function of the link-layer? TCP/IP has error detection with checksums (forget if it's in IP or TCP), but these aren't always used. Even if they did, on most networks, errors are due to collisions, and thus the entire packet is lost, not just a few bytes mid-stream.
In wireless, I'd advocate something like this, but again, only at the link-layer which means it's going to be highly medium specific.
fun fun fun.
It may be that not everything is predetermined, but if that's not due to free will, then it's simply random.
Why random? Is a finite automata's output random given it's input sequence? If so, then how could we trust the unix tool grep? Does grep choose to report a line even though it wasn't pre-determined? Could there be a malignant deamon inside my computer (possibly a virus) which causes it to fabricate results.. Simply print out a line with the sought word, wherein the line never existed in the input stream? Yes, but the deamon would also have been finit, so if the user knew of it's existance, this too would have been deterministic.. No choices have been made, and the output was not random.
Likewise, in our existance, if we were not free to make choices, we would merely be acting out Newtons concept that given the set of initial conditions of the universe, the entire future would be transparent. Of course, his mechanical view of physics was incomplete and choas does rule at the micro-scopic level, thus initial conditions may not even be enough. But neither of these two views disproves pre-determinism - they merely impeed our ability to predict the future reliably (most notably in weather patterns).
As for:
Our nature is important. If you don't have free will, well, why bother? Whatever you think or choose is not your thought or choice
The concept of the choice may not be yours, but the actions will be. The process of choosing is an action, and therefore the process of choosing is yours to own. If the concept of choosing doesn't exist (e.g. if we have no free will), then the non-existant choices are not ours, but we still own the action-process.
We define responsibility to the effect that we accepting punishment / retribution / reperations for our destructive actions, and thus pre-empt them by avoiding the destructiveness in the first place.
If your person [chooses to] takes actions that are destructive (in essence, not bothering to obey annoying laws), then you will eventually be dealt with. Just like you would not just sit and let somebody beat you up indefinately.. Eventually you will run or fight back. Thus our intellect (which is fundamentally no different than that of an animal) will act so as to avoid these understood negative outcomes. A dog will avoid a harful person, a cat will remember a generous household, a bee will remember a pollenous flower.
Note that the above actions merely require intellect, not free will. The intellect is little more than a memory system which can store and process inputs and trigger responses; some creature have greater analytical power than others. Dogs, for example can sense and analyze smell, and cats can sense and analyze light better than we.
If you were to build a world simulation, would you make its inhabitants religious?
This is interesting for two reasons. One, the point of your asking.. Do we pre-judge our simulants as disobediant or dispairing, or in other words, is it possible to produce naturally happy-go-lucky simulants. And two, is philosophy/theology a natural process of intelligent beings. Since theology is a slowly conjured externalization of philosophy, and philosophy is an intellectual attempt at understanding our environment. Is it possible to produce a world of thinkers (still possibly pre-determined) that can avoid concluding an extra-world or extra-existance.
Define free will? Is it the ability to do as you wish? This can't be true because the physical world impedes your activities. You can't travel as quickly as you wish, nor break as many laws as you wish indefinitely.
I would refine this to mean, given a set of instantaneous (time dependent) options, you may choose which-ever one you wish.. BUT, these options are not infinite nor continuous. Thus the physical world around you is limiting your choice. You are molded by your environment necessarily. Moreover, your character will likely be limited in it's sophistication so that it can't see many of the more desirable options. Thus there is a definite degree of pre-determination. Not only do we have few choices in life (which are given to us by the fate of historcal progression), but we are pre-determined (through biology and our own past) as to which choices we are capable of making.
While this still leaves us with an enormous responsibility (in terms of a multitude of diametricly opposed options), I'm not convinced that we are capable of making any decision other than what we were meant to; meaning what our mechanical biology is statistically configured to do. If our brain is nothing more than a mechanical/electronic switch-board which makes value judgements based purely on thresholds of triggering, and those tresholds are altered by periodic chemical states (moods), then we are deterministicly given our past (our prevoius moods and experiences) and our present environment will merely be inputs into this switchboard - the outcome would merely be mechanical. Granted this is only an assumption, but science slowly providing more and more evidence of this.
For example, a person biologically prone to aggression (which isn't normal for a person), when presented with an irratable peer, and absence of calmer people in the surrounding environment to disuade him, is pre-determined + environmentally encouraged to choose to fight. Without a possible alternative, this choice is not freely willed.
For these extreme cases, I do not believe we have much free will.. In softer cases (should I buy coke or pepsi, and thus macro-scopically determine the economic fate of our country), I'm willing to give to the argument of free-will. It is plausible that in the chaotic interaction at the atomic / quantum level, our thresholds (when presented with a nearly 50/50 point) may or may not trigger, thereby altering our decision. In this critical chaotic region, our personality (and the coriolis effect of the earth, solar system and universe) may all come into play. Any concept of a soul, or weighted simulation may make the bizarness of life happen.
But the possibility of this does not prove it's existance..
My point finally being, free will is by no means logically sound, though it is not disproven either.
As you look into parallel mirrors, you can never see the infinity because your head is in the way. In other words, there is no accurate simulation of reality.
Ahh, but you forget planks limiting constant and special relativity. There is no such thing as infinity for two reasons. You can only get as small as allowed by the plank scale - period. And you can not experience further than the speed of light inside your realm of existance (meaning a life-time times the speed of light during that time).
The reflective mirrors will eventually discretize into photons, afterwhich you will not achieve any greater resolution.. The reflected image will degrade in quality accordingly.
So it's entirely possible to define the computing power of the "user" domain as the particular value of plank and the speed of light in a vacume.
See my other article for an understanding of how you need not even require more than modern computing power to simulate a universe with even these constraints.
I will, however, concede that your use of the term "accurate" complexifies the situation. But I argue that general relativity applies. Accurate only needs to be true in the eyes of the beholder. Plus there is no concept of an absolute frame of reference, and therefore "accurate" can not properly be realized.
not having read the article yet, it seems trivial to simulate a universe. Recall from physics how we learn about our universe. We don't start off with atoms, we start off with macro-scopic relationship-equations. Ideal-gass law, simple voltage-current relationships, ideal charge field/force laws, action/reaction, momentum, etc.
/animals are statistically/generically modeled, and no two humans will experience quite the same universe. This doesn't hurt anything since two separate models will never truely interact, so synchronization is unnecessary.
These are all macroscopic approximations of what is really going on. They are inaccurate as you delve deeper into the inner-space. But the key is that depending on what you are trying to simulate, you have no need to waste computation time on distant objects; merely to generalize them (until and unless they ever become near objects). This drastically saves computation time.
If your focus is a single human being, then the rest of the universe can be generalized, including all other human beings (hurd mentality can apply). Thus it may very well be less computation time to create completely seperate universes for each and every focal point. All other humans
Still, if interaction is necessary, we have all sorts of common phenomena which could explain the discrepency.. Memory-loss (memory uncertainty), mysticism, deja-vous (for use with resyncing timed events). So you could independently model two universes, then merge them together for some time period (possibly reseperating them later on).
To minimize the negative effects of merging models, the same formulas would generally have to be applied. Truely macro-scopic events (extra-planetary) would probably all share a common model (since there's no point in duplicating this aspect).
The main point is that it's likely to be possible even today to provide enough processing power to render an entire population - especially since from inside the simulation, you can have no way of telling how many focal points there are.. You can safely assume that you are truely the center of the universe (reminds me of when Zaphod Bebblebrox entered entered the chamber of dispair in the hitchhickers guide).
Theologically, Gods and deamons could serve as control venue's. As law and order persist, their need is deminished and localized. The concept of the afterlife, however, may be very real, insofar as your particular model is considered valuable.
While I agree that the laws of physics may indeed be different in the proposed "user" world (to use a tron phrase), the laws of scale should be no less applicable. Meaning that even in a logarithmicly scalable world (or possibly even an inversely factorial world), there are still limits. The only thing it effects is the size of the individual models. (And thereby it's depth)
One important aspect, however, is that since each model focuses around a small truely interactive environment (determined by available processing power), then it's entirely possible to have a beowolf cluster. Each node is mostly independent of other nodes (insofar as very little information is exchanged). Information exchanges are like the temporary merging of seperate models. While a given machine is only so powerful, you can arbitrarily limit it's complexity such that you can cheaply produce hundreds, thousands or millions of these machines.
Enjoy..
And Michael Gilbert says, "As a monopoly, Microsoft's below-market-price distribution of software might very well be a form of illegal competition for a particular market." Presumably he's indulging in a bit of theoretical speculation, and doesn't really lack the sense to foresee such a legal claim promptly going down in a ball of flames.
I can't tell if you're being synical or just naive. Companies are successfully sued for underselling products all the time. Anti-trust is based on the idea that you can use your monopoly power to enter into new markets. Namely, if you have a monopoly in the business office-software, and you don't in non-profit or educational sectors, but there are pre-existing competition in those markets, then you undersell your product (using your excess profits from other markets) to stamp out competition. Thereafter raising prices back up; once the barrier-to-entry is high enough. This is anti-trust clear and simple.
Pre-speculating that they will raise prices again may or may not win in a court of law, but it hardly takes clearvoyance to see this pattern in previous MS activities.
Moreoever, MS is already in declared violation of anti-trust. It would not be very hard to legally apply pressure in this case.
It is illegal to selectively sell products at different prices. MS was found guilty of various unfair contracts on massive scales to PC vendors for licences. There are bizzar cases where the government turns a blind eye towards favoritism - namely senior discounts, educational / non-profit / foreign purposes. Basically the US government turns a blind eye when it suites themselves.
The issue, however, is that MS is internally being given cart blanche negotiating power to sell to whomever they can at whatever level they can. This is stright favoritism transactionalism. And while we see this in many markets (auto sales, etc), for some reason it's illegal in super-markets and department stores, and thus I speculate that MS is in violation. IANAL, so please somebody enlighten me if there is somehow a method to this madness.
class is private by default, thus this define wouldn't catch all cases. :)
You'd want a reg-ex pre-processor with:
s/(class[^{]+{)/$1 public:/g;
thers will claim Java is a good example, but it's a bad one, because despite being statically typed it causes typing errors (from casts) and null-pointer exceptions (ick).
True, but we'll see if generics resolves this in java 1.5. I'm of the opinion that you should NEVER explicitly type-cast, and generics get us closer to that goal.
I always hate deciding who to reply to, knowing that most likely only the replyee will read the post.
In any case, what is being described in these two posts is a simple combinational logic machine.
I couldn't get a feel if either of your posters knew of their existance. I'll summarize by saying:
* For combinational logic machines (reprogrammable-FPGA or write-once-ASIC), the "instructions" are provided to the machine at design time, not at run-time. They embed themselves as bus interconnects such that data exists as signal lines (possibly initiated from a memory-latch), and propagates through logic-modules (of varying complexity contingent apon the feature-set). Thus the original poster was correct in his assessment of time-critical / bandwith-sensative design. A given program requires a specific timing sequence (unless latches are fully utilized), and a minimum bandwith (number of interconnects). Thus it may or may not run successfully on a given piece of hardware.
* As you pointed out, this sort of technology is not new. All CPU's are designed with a similar approach (though there is greater freedom in bandwidth / substrate-module-complexity etc).
* Graphics cards, specialized chess machines, etc. all use this sort of logic-level programming today with over-the-counter resources.
I don't have a problem with them being a for-profit company.. And I don't mind that they have to cut corners here and there, and are ultimately trying to over-bundle things such that the average consumer has to pay more than they really want to. I am somewhat disturbed by the fact that consumers "have" to make these purchases due to peer compatibility. But most importantly (and relevant to this article) is that we are somewhat forced to use their software (at whatever price we can afford), and then are subject to a lack of quality control.. Part of corner-cutting is to get a product out the door before it's bug-list is even resolved (to say nothing of the shere number of undiscovered bugs).
As for bloat-ware, I was focusing on the propensity of new code to be buggy. Thus the policy of adding every feature they can think of (so as to suit every type of customer) directly affects their ability to perform quality control - or more correctly, each new feature "should" increase the testing time by some amount.. Moreoever, the relationship between the amount of new features and the required time to test is non-linear (complexity grows somewhat exponentially).
Thus, the marginal utility of each additional feature decreases. But the marginal price for each new feature remains the same.. But from the above, the marginal quality necessarily must decrease (unless, of course, the marginal time to release goes up; which it won't).
win2k was called feature bloated; I've no doubt that win2k3 is the same. Each new sever-level feature is a new security risk, a new stability risk, and a potential unwanted cost.
Finally, about your statement that modern machines have plenty of excess HD and CPU resources, remember the policy of wintel. Intel Makes a faster CPU, then MS adds bloatware which necessarily slows the system down (greater graphical load for the desktop, slower MFC, etc). The slowdown means that people/businesses are encouraged to repurchase new machines. Intel sells more CPU's, and get this, MS sells more windows licenses. So while whenever an application becomes bloated, it encourages a whole new purchase arena.
Rest assured that 3GHZ is no safe harbor.. And while you as a consumer may not mind updating periodically to keep-up-with-the-joneses, businesses are less than thrilled to deprecate hardware/licenses.
I'm not shy about criticizing MS when appropriate, but to come from Windows for Workgroups to XP in 10 years is pretty impressive, especially for a company of its size.
I honestly can't tell if you're being sarchastic. 10 years to make an unstable piece of software less unstable and more bloated impresses you?
Stable Enterprise-level product lines have been created from scratch in less than 5 years, and MS's inability to get past a horrific security/stability record with the largest software developer resources on the planet (hell, the largest "resources" on the planet) does little to impress me.
That Bill Gates has finally announced that it's resources will be used to correct existing code is good (though probably just a show-boat). The issue is that they honestly value bloatware over quality.. Bloat means more to charge for. Unfortunately with high turnover rates, they don't have time to make stable software.... Other companies constantly build apon pre-existing bases, such that bugs can be found and corrected over time; new features are bug-prone, but the core becomes trust-worthy. This concept is decades old... Yet MS assumes that they can throw developers and "good software practices" at the problem and reinvent the wheel every 5 years or so.
Moreoever, the only justification to reinvent the wheel is to drop compatibility with their crappy old software base.
Look at Direct X, with it's 8,9,10 releases in less than 8 years. How can you trust that a video card driver (which now has operated at super-user levels for a while now) has had a chance to stableize? ATI has a horrible reputation for driver quality, but I don't blame them (much). They, like MS have bloat-ware concepts (put everything into their cards). But the number of features they provide hasn't grown too quickly.. But the platform for which they must constantly port, has.
Moreoever, I can't comprehend how simple HTML tags can be allowed to crash the browser. Parsing is a trivial operation. Are there syntaxes in c that core-dump a compiler? For a run-time environment (VB-SCRIPT / JavaScript), sure, crashes might be evident; though this is a sign of a poorly constructed scripting language (perl crashes if you "goto" a label in another subroutine (via the "last" keyword)). But a browser can be defended by saying the definition of the scripting language is inferior.
While this is a trivial bug, it just goes as proof of a design mentality that just isn't compatible with robust software.
On slashdotter commented that it was missing callable statements, which I believe are necessary for certain types of stored procedures.