Shouldn't be a problem.. Have you seen the latency on modern Cache implementations? We're already at a BEST case of 2 clock delays with minimal concurrency. We're seeing 8 and even 16 clock cycle delays for L2 / L3 caches. Cache has always been hierarchical.. The lowest latency is always very small.. What this technology provides is effectively extraction of L2 cache with the complete transparenc y of adding L3 cache.. Think 128Meg L3 cache 8Meg L2 cache; something completely impractical for regular general CPU design.. Since you can "upgrade" your cache by replacing a peer-chip, now you can pay-as-you-go.. Spend a thousand dollars a year, upgrading one cache chip at a time.. And we've seen what's happened with the SDRAM market once commodetized. Pretty soon SDRAM may dissapear completely, being replaced by (albeit high power) gigabyte SRAM L4 modules.
If cost effective, and if they can get past the alignment issues, this is spectacular.
Actually, I see a lot of code that has ifdefs in java. I have no idea why you are suggesting that this horrible method of coding is not available.
Firstly, many java apps these days are built with "ant", which contains a java tokenizer for God's sake.. This performs search-replace on the java code for special tokens; often based around version of th e JVM currently compiling the code or sometimes even based on the platform.
There are apache commons tools which can ask questions like isWindows, isUnix, bla bla bla, and so you KNOW there is platform specific code running around the open-source community.
I use a java editor which is very specifically tied to a particular version of java; it will physically not run on any other version. Subsequent releases of the editor use newer version.. It's very frustrating, but thankfully it's very easy to install multiple versions of JVM's on the same machine.
Moroever, if what you want is that totally different code is rendered for different platforms, consider this. Java HATES switch statements; only integers can be applied and most everything in java is an object; (whereas in c/c++ most things are integers; easily fitting into a switch statement). Thus if you want a switch statement, the better design paradigm is to have a base class and subclass it for each switchable item. Then you choose the appropriate derived class (I personally perfer hash-table lookups).. The advantage is that ANY redundant code in the would-be switch statement can be refactored out and reused in the base class. It's more elegant design, often easier to read; provides smaller, more concise code, bla bla bla.
So obviously if you can ask the platform which environment it is, then you can choose subclasses which implement the platform specific material.. This is much more elegant than littered #ifdefs in the middle of a conditional of an if-statement.
The argument of #ifdef performance is moot in java, since you have run-time optimization.. If you have an if statement that can not possibly be true, the compiler removes it. Thus an ant pre-compiler, resolves the equivalent of ifdefs. However, the JVM itself is likely to determine constancy (generally due to a finally clause) and thereby compile-in or out even run-time configuration exclusions. The bane and bueaty of java is that you've outsourced performance to a JVM vendor.. jRock is fast but unstable (in my experience), while sun and IBM are pretty good all around.
As far as platform issues exist. Java is slightly better than perl at being cross platform neutral (though perl is catching up). These two I would consider to be the best all-around cross-platform languages.. Sure you have kiddy languages such as BASIC or pascal (or elegant ones such as lisp).. But these languages don't work well with their host OS.. They don't translate paths correctly for one. Nor do they even allow multi-threading as java perl does.
Java is not without it's flaws, to be sure.. And even the repairing of flaws have left an unsightly appendage of sorts. But once you get past memory / CPU requirements, Java is one of my favorite platforms
OJB, torque, and hybernate are excelent well supported 3'rd party OODB tools which provide optimistic/pessimistic locking, Object caching (to speed up object-graph navigation) and near minimalistic support (especially when used with xdoclet).. You literally write the class as you would use it (not even fully mapping all the columns to fields if you don't need them), and create collections wherever you would have a 1:n or m:n association. Then in the javadoc prior to each data-structure, put a one liner in xdoclet form which allows the reflection-based (or intermediate compiler, depending on the technology) interpreter to determine how to associate your OO data with the relational data.
If you use aspect oriented programming (aspectj or dynaop) you literally never even have to worry about how and when the data gets persisted or retrieved, since that's handled as a separate configuration (typically as a prefix or suffix to all create or remove methods within the model).
The caching system makes for faster operation than pure SQL when you have more than one query per operation. Yes you can obviously create a single custom query which does everything all at once, and this will be optimal, but for enterprise applications there are often too many unrelated activities going on. Having an intermediate layer cache the most-recently accessed rows (in their post-transformed state) means you don't have to worry about such performance issues... When profiling, you find the hot-spots and do some custom SQL to "pre-fetch" the necessary data so that subsequent sections of the activity are once again fast.
Probably not a one-size-fits all solution. But after several years of attempting various custom OO layers atom RDBMS's (specifically, postgres, MS SQL server), these open source 3'rd party tools have put me to shame.:)
You could use inheretance. postgres, for example implements inheretance in tables by internally performing the same search across all tables that are derived by the base table.
So if, for example, you had a base tabe
create sequence unique_seq;
create table base (id bigint default nextid('unique_seq'), varchar(255) comment);
I have one good example of why the 2D data-strutures are not ending their lives just yet. spread-sheets. The world today is not run by databases, but by middle-management that use MS Excel to quickly throw-together vast collections of data and ask questions of that data.
While MS does provide a rudimentary database system in office, the defacto-standard these days is Excel. Yes it's a HORIBLE data depot (unreliable, corruptable, mangleable), but computers are fast enough and with enough memory that few in management can fully tax it's ability, so they rarely find a need to delegate out an Access or centralized database-system.
Modern Excel allows you to perform full blown SQL queries on a disconnected set of excel spread-sheets. And the fact that an excel editor is far superior than most front-ends to a database-backend is the real killer.
Since spread-sheets are fundamentally two dimentional objects, and they are so prolific in even the non programming world, I strongly challenge claims that suggest such facilities are pasee'.
I'm not sure if your argument is merely about SQL or whether you're referring to 2D flat structures. But even if it is only about SQL, I'd suggest that SQL can be far more expressive than a complex setup of pivot-tables in excel (which essentially performs the same operation as joins on a table). The fact that most GUI's are merely SQL-generators to a common ODBC backend is a testement to this.
Of course, I'm ignoring that using Excel to ask questions is often done in poor practice (slash had an article about how statistical applications should be used instead). But most OODB / RDBMS system designers don't bother with the statistics either.
Sorry, but you aren't reading the article correctly.
Bit-errors are "hardware" problems, not software problems. By definition, a software problem is due to incorrect coding - it assumes hardware that perfectly conforms to spec, and with zero error. It would be impossible to write software (on modern hardware at least) that compensates for all bit-errors. Yes we have ecc memory and caches, but they are only one component. Now reliable hardware errors can be corrected for in software (the division error in old pentiums, for example). Also high-probability error-points (such as inter-machine communication) is designed with explicit redundancy/error-correction/detection. BUT this is data, not the base instruction. I am not aware of software solutions to correct for software instructions. (Ok, perfectly redundent CPU's which an I/O comparator, but this doesn't solve the problem of the DRAM bit-errors).
As for SRAM, in the CPU, that's even more volitle than DRAM. It has much higher current requirements, and thus has a higher probability of heat-related errors. They change values more often than main-memory, and have MUCH higher performance requirements. Most SRAM has ecc these days.
The static part of SRAM just means it's continually held at a certain logic-level. But in modern CPU's that's contingent apon a steady input voltage. With millions of taps on the voltage (and especially with over-clocked CPUs with faster than spec switching times, and often over-pumped voltages) the probability of a temporary voltage drain on on of millions of taps is very high.
With DRAM, there is a very controlled simultaneous refresh of a row (or column, don't remember which). Depending on the technology (I believe SDRAM falls into this category, but I'm not completely sure; yes I know S means Synchronous, not static), micro-caches (read as static ram) exist for the purpose of fast column accesses. When switching rows, the cache is written back in parallel to the row. When a particular row has aged too long, general memory access is halted so that a quick DRAM -> SRAM -> DRAM can occur (e.g. a refresh). This all happens transparently within the DRAM (though depending on the technology, the memory-controller may have to send the appropriate signals).
My point there is that in these types of memory architectures, refreshes are no more dangerous than regular memory reads.. The only possible danger here is if a particular memory cell will expire (discharge) sooner than spec, but isn't caught during testing because it happens to be refreshed in the wrong order; it's thus a time-bomb waiting to be accessed in the right order in production-environment. But such a situation is reproduceable.
One other note.. I said DRAM is a symmetric operation.. This is because in modern DRAM the entire row is read or written to at a time (tens of thousands of bits). In SRAM,only a single cache-line (roughly 128bits) is read/written at a time. Further, in some architectures, there is simultaneous access to different sections of the cache (2 read, 1 write caches, for example). A registry is the ultimate cache with many potential input and output ports to each and every bit...
While you make several good points. I do have some counter-points.
A VM otoh does get this capability for free.
Let me qualify this as saying you don't have to do or pay for anything extra to achieve this.
Err... whether garbage collection gains or looses you performance depends very much on your application. I am not convinced that any garbage collector can even be theoretically faster than automatic variables.
By automatic, if you mean stack-resident variables, then I agree (with the caveat of dangerous code design), but if you mean malloc'd variables, then I don't see what the problem is. malloc has to worry about a great number of things, not least of which is memory fragmentation. I happen to have done a non-trivial amount of research on memory allocators; though I am no expert. Memory allocators can be optimized for allocation speed, fragmentation efficiency, concurrency, cache coherence, etc. but not all (obviously). As it happens, a copying garbage collector gives you all of the above EXCEPT when your buffer runs out; and thereby requires a garbage collection. So long as you you have large heap and you're not worried about the latency from garbage collection, then copying collectors are VERY fast. Allocation is literally a mutex lock, a stack-pointer range check, a stack-pointer increment, then a mutex unlock.
Now, because latency is often a real issue, most modern GC's apply additional complexity/logic which slows down the normal case to minimize the worst case; e.g. generational garbage collection which may require read or write boundry op-codes inserted. But code-wise, these varients are identical. Thus you achieve a flexibility not possible in a dynamic-memory-egnostic system such as c/c++.
I'd be interested to know how you have more control over the design of 3rd party libraries in Java than in C++
I didn't really mean design, but environment; Specifically in terms of the dynamic memory allocator. But, just to make the differentiation complete, java allows byte-code load-time modification. This is very common in "aspect oriented programming" such as in the database realm (JBoss/OJB) or object proxying. In Java, by introspection you can prepend/append/search-replace method calls or even individual instructions as need be. Note that this isn't any different than a custom pre-processor for C, but tends to be cleaner and thus doesn't require the [3rd party] coder to adhere to a particular convention.. Moreoever, this works on already shipped binaries, as opposed to requireing preprocessing to occur on the original source code.
Except that in enterprise computing (as opposed to scientific computing), we are not interested in JUST throughput, but more often the time-to-shipment of the application, and the robustness of the code. Robust code is often abstracted or is littered with superfelous code (i.e. redundant checks for nullity).
Code that is easy to read, easy to maintain is often not very performant, because you aren't allowed to make special-case optimizations at the code level, since they are often a nightmare for other's to interpret.
In terms of efficient elegant code, it is trivial to use a hash table over a linked list in java (in fact, linked lists are harder to implement). Thus a LOT of java code uses such O(k) algorithms. On the other hand, in c it's relatively easier to use bitmaps than a hashed set, and thus c has less overhead for a common practice. But, as a consequence, bitmaps often have an upper-bound (no more than 32 entries) (yes, I know you can use bitmapped c structures). But a hash table is easier to read and harder to screw up than a boolean-logic bitmap, so it is often a better choice for "enterprise code".
So my response is that it depends on how you define "efficient programming". Do you mean efficient execution (which really is optimized programming), or efficient writing and maintanance of code. I suspect you mean the former, but what you should mean is the latter.
What's more, as far as a business man, you have to weigh the cost of development time v.s. performance of application. Well written non buggy, easily adaptable code requires little future man hours, and can take advantage of moore's law. If the software is successful, "scaleable" code can run on ever more expensive hardware (clustering). Highly optimized software may not be easily clusterable, or may not lend well to adaptations; each adaptation would require re-optimizing the code. The classic example here is Java's "Reflections", where a text configuration file is often used to link unrelated code together. I see this a lot in databases where we map new tables to code which may or may not be a proper fit.. The reflective configuration handles the remainder of the impedence mismatching. Note that you can do this in c as well, but it wouldn't be the fastest solution by far.
if the JIT/javac/JVM uses profiling information, gcc should too, for fair comparison.
I disagree. What is being compared are stock products. It's like saying if this car has a turbo-charger, then it should only be compared to other cars that have a turbo-charger.
This is more like comparing a toyota to a mustang. The mustang can accelerate faster, but the speed-limits of highways prohibit it from traveling faster than the toyota could travel.. The fact that the honda gets better gas mileage and thus requires fewer pit-stops gives the toyota an ironic "average speed advantage" over the mustang in a cross-country race.
What is being shown here are two stock environments, "gcc" and sun's JRE. There are external profilers for BOTH gcc and java. What's more you can compile java down to assembly. But we are not testing a profiler or a cross-language compiler, we're testing the stock compilers.
The author did say he might try Intel's compiler next. Likewise, perfectly valid tests would be a 3'rd party profiler as applied to gcc or Intel.
My point is that the alleged java run-time profiling is merely an attribute of one product over another. If you required running a profiler on the gcc and not an external one on Java, then I would argue that Java is at a disadvantage, because java can't shut off it's internal profiler. ("-client" shuts off more than the profiler, it shuts off most of the useful jit as is thus a pseudo byte-code interpreter).
I'm inclined to agree with you, except that the benchmarks were qualified as talking about being relevant to enterprise applications. In such a situation, run-time optimizations are critical.
While it is entirely possible [in c/c++] to use a profiler to generate compiler hints so as to generate even more efficient code, this is rarely performed, and often is not free. A VM otoh does get this capability for free.
Additionally, the java memory manager has a slight edge over tradditional malloc's for total throughput (though the best throughput configurations have horrible spuradic response times). It is also possible to choose a different memory manager for c/c++, but this too is rarely used.. Moreover, it is much harder to have 3'rd party code integrate well with a garbage-collector model. Java enforces garbage collection, and thus optionally gets the particular performance gains (being free to trade off throughput for responsiveness no matter what 3'rd part code is integrated).
As was pointed out, one of the strenghts of C/C++ are pass-by-value, which allows memory allocations to be avoided all-together, but at the cost of copy-time and robustness of code. If a method call requires instantiation, c/c++ have the option of passing in a local [stack resident] structure to be populated by the method. However, this is fodder for buffer-overflow exploits, and notorious for otherwise bad code (accidently caching the address of a value that lives on the stack). Thus, given that c++ will use "new" and thus generally perform a malloc, the same performance issues above apply, and c/c++ may have the additional overhead of copy-by-value.
The fact that you have to explicity declare a c++ parameter as pass-by-reference suggests that those interested in "good programming practices" (tm) will only make a pass-by-reference if you intend to modify it's contents. Thus "clean" code in c++ will be copy-intensive... For fairness, clean java code should always make immutable wrappers for any non-modifyable code, thus requiring an all together different liability (and thus I can't make any claims as to which would be faster; wrapper object instantiation or deep parameter-copy). Though all primatives are available in java as immutable objects (Strings, Dates, etc). Moreoever, clean OO-code should always use method getters, and make all fields private (not even protected). Both C++ and jit'd java can inline these getters.
I haven't looked at the benchmark code, but the above are common components which make a big difference when scaling to large enterprise applications, or even when merely writing a glue application which integrates many large 3'rd party libraries. In c++ you don't have a lot of control over the 3'rd party libraries (in terms of their design trade-offs), but with a VM, you are largely sheltered and have many configurable alternatives.
I can't confirm the details, but it was my understanding that the Alan Cox fork in RedHat 9 had an implementation where the swap had to be at LEAST as big as main memory.. Theoretically the reason is that you preform pre-swapping.. The idea is that if you waited until the last second to do any swapping, then your most efficient choice would be to swap non-dirty pages.. but if instead during idle periods of IO you swap dirty pages, then when it comes time to swap, just about everything is fair game, and you can truely swap out the LRU pages with great efficiency.
Thus you'd pre-swap once you got to like 60% full memory.
More-over, as others' have said, unless you have as much RAM as the average hard-disk space used / day, then you are in a non-optimal operating environment, since your cache isn't as big as it should be.. cache flushing swapping.. They're almost identical in user-time experience (though aruably, re-reading a contiugous chunk of file-data is going to be faster than unswapping randomly positioned data; but how many files are contiguous these days?).
Thus if you have a daemon with a LOT of setup code which is never used again after startup, then it makes sense to permanently swap this out to disk to free up space for the cache.
Not usually true.. Simple economics, corporations are interested in profit maximization.. As the price of a good goes up, the quantity sold NECESSARILY goes down. The perfect price for a given audience is based on the aggregate demand curve (generally not a known equation, but rather can be approximated through polls/sampling/etc). From the demand curve, you can directly compute the marginal revenue curve (for straight line demand curves, the marginal revenue curve bisects it). You then take your cost curve, (which becomes more expensive as you produce greater quantities), and see where that intersects the marginal revenue curve. This tells you how many to produce (in a monopoly or in monopolistic-competition). You then can charge as high as the demand curve will allow for that quantity.
Now you can play dirty games when you lock customers in via licenses, since there is a barrier to exit, but even in this circumstance, existing customers have a demand curve, beyond which they will no longer accept your service, and you will certainly bar new customers from entering.
In any case, as you increase your costs (via taxes, fees, what-have-you), you raise the cost curve, BUT, the demand curve has NOT changed.. Moreover, presumably you previously chose a profit-maximizing position.. If you merely raise the price, and hold the quantity steady, then many of your customers will exit the market (as the demand curve REQUIRES). You will no longer be at a profit maximizing position, and WILL lose revenue.
Thus, in the face of rising costs (e.g. new taxes), you must recompute the intersection of the old marginal-revenue curve and the new cost-curve.. This will give you the new quantity to produce (which will be smaller than before).. You then choose the new price point on the demand curve at that quantity.
There are two types of customer-bases.. "elastic" and "inelastic". Elastic customers will exit the market at very small increases in price (say milk, gas, etc). In-elastic customers are essentially addicted to the produce (say medical drugs, cigarets, BMW's, etc). If you have an inelastic product, then you can pass on a greater percentage of your costs (possibly 100%) with little fear of losing customers. Especially if the entire market does the same, such that they can not substitute your product for a competetor.
If all gas stations or all cell-providers apply a $10 tax/fee to cell service, then subscribership should not go down much, since there are no alternatives for the "addicted" service.. However, you will necessarily exceed some house-holds' budgets, who will necessarily go down to a $30 + $5 plan, or simply drop coverage (paying the exit fees). Cell providers compensate by making their sub $40 services less attractive, which keeps more of their premium subscribers, but then completely alienates lower-budgeted brackets.
The key is that they are definitely monitoring the demand curves, and valueing out various scenereos. They know they what can get away with.. But the main point is that they do NOT just blindly pass along all costs.. What T-Mobile has recognized is that their particular demand curve can support a higher price, and that the best way for them to raise prices is to keep the deceptive $40/mo retail-price, and up it by nearly $10. The "new" taxes/fees are complete lies. It is deceptive advertising plain and simple.. NOWHERE does T-Mobile tell you that you are subscribing to a $50/mo plan when you sign up for their $39.99 plan. And this is what I think is wrong. They can morally charge what ever the heck they want for a service, but they should be honest about the costs. Especially with $150 cancelation fees.
On the other hand, my beef is probably because I'm use to a different sort of pricing tactic, called "sales" evaporation.. Retailers list a price MUCH higher than what the sell the product for.. They advertise the retail price all over the place, but when you get to the shelf, it's usually much cheaper.. So when the store wants to raise
Well, I think Descartes made a wonderful philosophical exploration, which ultimately showed that it would be impossible for God to convince us of his existence. Him throwing a light show would be little different than taking excstacy, or subsequent generations claiming that our generation had something in the drinking water.
The best that could happen would be regular guest appearances, from generation to genreation. But you have to consider what the purpose of our life and our role for God would be in such a circumstance.. IF there is a God, and IF we are fashioned in some manner compatible with any of the relgious texts (Hindi, Shinto, Jewish, etc), then there are certain rules to abide by. Philosophical rules. You can't have free-thinking if you control thought.. If we are some advanced program, computing the question to life-the-universe-and-everything, then it makes sence that our God doesn't already know the result, or that we are in a state of flux in God's synthesis of some as-yet-unseen future state-of-the-universe. Thus it would not be logical for God to be all-knowing, and all-powerful.. Our existence would be superfluous.
So, taking free-thought as a possible necessity of our existence (exemplified in the Jewish Genesis story), then the degree by which God was ALLOWED to control us (such that he accomplishes his goal) is deminished. The more God influences us, the less free we are. The more undenyable doubt he imposes on us, the less wonder and speculation we can produce.
It is logical that God would be a marginally absent God, AND that God would manifest itself in many incompatible forms, since this produces a healthy degree of diversity, opposition, congregation, etc.
The point of this is not to prove God, as I started out saying that it is impossible. But merely to keep the fire of the debate alive.
For most Americans, God is irrelevant, we have devized our own sets of "morals". We cling to a God-like figure, not because we crave justification for our suffering, but because we were brought up with theology, and the Pascal dilemma scares many people (if I don't believe and it turns out to be true, I'm f***d). While this is all fine and good, the danger is a certain progression into anarchy.
Adam smith shows how society is best off when everybody acts selfishly. We only tell the truth because we recognize that getting caught lying will ruin you business-wise. But those that are willing to risk not getting caught are more effective business-wise than those that refrain.. So eventually the truth-tellers die off and the successful liers will prevail. Sure there will be "market corrections" from time to time, but the general state must degrade.
Religion is a mechanism of control for regular "market corrections". Yes, it is often exploited, but if it did not exist for the lives of 51% of the population, we would surely devolve rapidly into self annilation.
Logic CAN be a savior, but only by creating a new religion of logic.. A congregation of watchful eyes, providing a high probability of being caught in counter-society acts. This is essentially 1984 or at least a religion waiting for exploitation.
My opinion is one of moderation. We need religion (of some form), but we need regular change (so as to unseat power figures); Absolute power corrupting absolutely and all.
And leading back to the beginning, if there is a God, and God is manipulating us here and there for God's purposes, and we are deviating too far from God's needs, then surely God will perform a market correction of some sort. That we have not had such a correction in quite some time implies that we are headed in the right direction.. Be it atheism (suggesting previous corrections were merely stories/ primitive interpretations of natural events), or moderated/alternating relgion.
All acts, categorizable as either good or evil, are so as to fullfill a personal need. Look at American Indian's who were very gracious hosts to the initial settlers. Was this because they had the fear and awe of God in them? No, it is because the had some very practical experience with how to manage small societies. And that experience told them that they needed to support their neighbors, because you never know when you'll need their help. At that time, the shore-side Indians had no advantage in raiding the settlers, and good will provided them certain insurance. Mind you, they most likely were not very methodical, this was simply learned practice; good manners.
Single-mindedness does NOT foster kindness/gentleness, etc.. Mainly because the probability of encountering one who is of a different mind is too great. This, as history shows, single-mindedness is more likely to produce unifying actions (which can involve aggression, imposing shame, acting immorally so as to produce a "moral" outcome (e.g. The ends justifies the means)).
When you are within the homogeneous society, then things can be peaceful, but as history has also shown, there has been NO evidence of non polymorphic religion or philosophy. Judaism morphed into orthodox and reformed. Christianity morphed from day two into dozens of wholely incompatible religions, was later unified through state-power, almost immediately divided again.. then finally divided into factions which wished to kill one another over incompatible ways of life (Irish/British). Arabic cultural religions (rooted in Abrahamism) morphed into Islam which, like Christianity, immediately apon their founders' death split into rival factions (which till this day war against one another). Same message, only differece is one of leadership (read power).
Do not confuse the tendency for like people to congregate, with the logical benifits of independently derived hospitality. A man can be wise, dumb, genereous, selfish, hateful, or caring. But a religion is about homogeneity. It serves a useful purpose (as it facilitates the individuals' personal aspirations), but religion in and of itself is a cold machine, who ultimately craves survival and growth (much like a corporation). And it should be treated as such.
Except that Jesus is proported to have died for original sin, not every-day sins. So the question is NOT whether each possible alien race has their own Jesus, but whether they had also pissed off their God in their beginning story, such that their devinity was revoked.
Except that Israel is in the middle, and for some reason, the US can't leave Israel to their own devices.. We have to keep funding them financially, militarily and politically, which is one of the main concerns that Muslim neighbors have with the US.
So, we'd not have ridden ourselves of any problems..
I'm nervous pointing this out, but in our E&M class we were directed to a pseudo-science web site (our professor assures us that the presented pseudo-science violates certain well understood principles).
But among the dozens of pdf's this web site provides, one is on the ocean rift polar flips. rift.pdf
In short, what it says is that as the mid-atlantic rift rips apart, hot magma comes to the surface, and that liquid is a lesser magnetic conductor (lower permeability) than the pre-existing high iron-content solid's crust. This plus the 1/r^2 magnetic strength of the source of earth's magnetism (namely the core of the earth) mean that the magnetic fields generated by the solid crust to the left and the right of the mid-atlantic fissure are MUCH stronger than that of the distant core.
The effect of having a closer magnet oriented in the opposite direction is that the next cooling layer of magma will orient it's magnetic field in the opposite direction of the previous layer (to complete the regional loop). Thus every new mid-atlantic fissure eruption / layer, causes a new anti-parallel magnetic field... Presumably, this is what geologists are measuring when they find magnetic poles pointing in differing directions.
As another warning, the wesite uses it's pseudo-science to demonstrate that certain E&M effects would be greater than our classical E&M says it would be for such a fissure reverse polarization.. So please take with a grain of salt.. None the less, I tend to like simpler solutions than a chaotic tri-poled earth magnetic field, or whatever currently is the explanation.. The crux of this pdf makes intuitive sence from a lay-persons' perspective.
So if you can make a CPU which emulates x86 code as fast as the competition, then go right ahead and try.
The key is that software writers (other than assembly) don't care about hardware; they care about maximizing the number of customers. Customers want cheap, fast and good software and hardware. If most customers currently have x86, and it would cost more to develop for other platforms (think beta-testing on every type of hardware), then software makers can minimize costs, and expediate release dates by supporting only one platform. Since x86 is the historical basis, customers can mostly only purchase x86 software, so they maximize their utility by purchasing x86 hardware, and the cycle repeats.
To introduce incompatible (or innefficient at backward emulation) hardware, customers will have a minimial initial set of commercial software that will run on it. So they won't purchase the new hardware unless their work-station/desktop will run nothing other than core utilities (OS MP software, for example), and thus there is no market for software writers.
OS writers may love hardware enhancements, but they don't make the bulk of software demand. Video games, office software (ACT, exchange, visio, photoshop, Nero, etc) are limited to very vew platforms (MAC/x86), so you're giving up a lot, even with newer software.
Apple had enough monopolistic pull in the MAC software world to make the hardware transition. Windows / Intel do not have such pull; how long did it take to migrate from DOS -> NT? And the irony is that OS/2 was not serious competition, so what did MS have to lose by going full protected mode win32 in the early days of win98? The reason is that they were trying to maximize their revenue stream, and I trust MS, of all companies, to know exactly how to do so.
Here is what I would have suggested. AMD64 adds an entirely new operating mode of execution. This is identical to the Itanium x86-mode, EXCEPT that AMD kept the x86 instruction format. This reuses the I-decoder, and more importantly, garuntees compatible instruction formats. The Itanium SUCKS at running x86-code because there is an impedence mismatch between x86 and EPIC logical instruction units. The Itanium solves totally different problems than x86-assembly is asking the CPU to solve. If Itanium requires smart compilers talking it's exact langauge to operate efficiently, then running x86 is like being given driving directions in greek for a road in France when you're in New York. The only difference is that you happen to have the same logical output when you're done. To make matters worse, x86 compilers do all sorts of bizzar re-arrangements of code with the full knowledge that they're maximizing the concurrent execution and minimizing delays FOR THE PENTIUM IV. These bizzar arrangements are just line-noise to the Itanium which can in no way take advantage of the re-ordering, and often time is spend decoding and excecting the equivalent of noops.
The point is that, any radical divergence, even by AMD64 from the core macro-op concepts are going to have likewise impedence mismatches for running legacy IA32 code. Still, I don't know why they didn't make all instructions 32bit aligned, and simply have seperate instruction decoders for 64 and 32bit instructions. They could have preserved the logical units, and given a HUGE performance boost.. But I haven't read enough AMD-64 details to know the motivations in this respect.
I think C deserves a little more respect than a blanket comment like this.
We still have assembly languages today for several reasons, even though it's been "dead" since the 80's. Driver writers, compiler writers, and high performance inner-loops of scientific apps NEED snippets of assembly.
Thanks to the design goal of c (as the paint on the metal), you can now program in mixed c/assembly and thus never have to actually write anything in raw assembly files anymore. But you still write with the intention of generating specific sections of assembly.
The people that write c are those that are resource conscious. I am not aware of ANY other language that is allows resource management as well as C. "performance" is just one resource, and I know many argue that JIT's counter-balance the performance advantages of optimized c. I still refuse to belive JIT's have ever approached -O3 performance, but am willing to concede that a well written VM app can perform acceptibly.
ButMemory is another key resource management position that sometimes requires hard computer science to derive workable solutions.. When you abstract how resources are utilized (via a VM), then it negates the value of such hard computer science. Note that this ONLY applies to a particular problem space. Though, a non-trivial problem space to be sure.
The point is thus that the classic paradigm of "the right tool for the job" is essential here. There are MANY problems that are best done with low level, very concise languages like c. Most OS components, VMs, or fast-duty-cycle applications should very well have core work done in c/assembly.
The obvious other end of the stick is managing large amounts of code, for which assembly need not apply, and c is indeed becoming a distant memory as I think you are implying. Yes, web-services and many such fast-to-deploy applications transcend c, but don't be too quick to write-off the value in having a generation of computer scientists that are not well enough versed at writing low level applications.
More interesting to me is the idea of a string inside a "potential-well", which tunnels for non perfectly-infinite barriors.
From my undergrad days of Elec-eng. Infinite barriors do not allow quantum particles (like electrons) to pass. But anything less than an infinite barrior will allow even the most lowly energetic particle to pass with some miniscule probability.
It stands to reason that some of the energy in the hole is near the inside of the event horizon (due to density-distributions). So long as the hole is perfectly spherical, there will be no place from which highly concentrated energy can exceed the escape velocity.
But if we replace the point-mass of the hole with a ball of strings, then we have fluxuating/undulating HIGHLY energetic strings. By nature, this energy is not going to be uniform, and may very well be periodic. This may allow regular minute disturbances in the event horizon such that super-charged strings near that rupture points can escape like a black-hole solar-flair.
Such flairs would give information about the non-uniformity of the hole, and thus provide information about the structure of the inside of the hole.
It's no less difficult then trying to figure out the internal structure of an active star.
Further, my lay-mind considers that holes may be as useful to the cosmos as stars.. Providing some alternate structured energy-source. Gravity-waves? Worm-holes? intersteller weapons?:)
My understanding of generics is that the type-cast is completely omitted.. If the compiler can PROVE that what is going in to the collection is a Foo class, then when you pull the material back out, no type-cast is needed. Thus it is in the retrieval of generalized objects that performance is saved.
So again, to my understanding there is NO downcasting.
That'll change once they start ramping up the clock speeds, and the effects of a longer pipeline become less significant.
I disagree.. I think that the performance enhancements were due to factors other than the lenghtened pipe and fast clock.. The clock merely compensates (currently badly) for the added [wasteful] buffers, longer latency, and deminishing marginal return on a single enhanced variable (clock-speed).
Intel needs to create a market for it's higher priced CPUs.. So by having a nominal performance chip, they can increase the other variables (cache performance being a big one), and thus charge an enormous premium.
I believe that they could go a long way to enhance the performance of their existing P4 archtecture, but they need more marketing power.. They don't want to waste time/money advertising Pentium 5. Additionaly, the "extreme-edition" moniker on a similarly clocked CPU is going to be a hard-sell. Thus they will make the most money on clock-enhancements.
AMD has the potential to capitalize on this by getting a higher benchmark rating, virtually for free, so I don't really see this as a big win.
The only issue is that it's cheaper to design a CPU with more stages than to optimize a lower-stage-count to get more Instr/sec. So AMD might not be in a position to get a truely faster cpu out any time soon, and relabeling their existing CPU's won't go over very well.
However, increasing the pipeline should allow Intel engineers to achieve higher clock speeds, as the longest transistor path will likely be shorter (faster switching times).
While this is possible, don't forget that adding more stages means adding more inter-stage buffers.. These buffers are pure wasted processing / switching time.
Since each instruction now requires passing through more total buffers, the amount of work performed each clock tick is even further reduced (compared to simply dividing the problem by the new ratio of stages).
Next, there is the classic trade-off of keeping those acursed pipelines full.. I'm not aware of us achiving pipeline saturation yet, so adding more stages merely means an even more sparse pipe. The only situation where more stages == more throughput is if most of the stages are busy.
And finally there's data-dependencies.. With a move to C++ languages (much of microsoft) and perl/java/CLI VM's running amuck, the number of instructions until a conditional branch / data-dependent-lookup is declining, and thus the performance hit of longer pipelines is sky-rocketing. Sure you can create a contrived nested loop benchmark that can fill those pipes, but that's not very practical.
IF the pipelines were fully decoupled (non interlocking), and the virtual threading (Xeon) worked well with it, then I could see these extra stages being of use. Otherwise, pure marketing.
lack of documented/fixed object layout precludes direct memory manipulation of data - mostly a problem in I/O
Just FYI, this is fixed with NIO. The idea is that you have a generic class to a byte-stream, which MAY be backed by non-relocatable, non-gcable memory. I believe this would generally require a native method to set up the memory-block (or the use of some java library which already does), but the idea is that it is handled.
And while I agree with your argument that it's the paradigms of java which impeed it's performance, we are seeing ever more incursions of high-perf. paradigms enter into the core language (noting that you always had the possibility of writing such routines and UNIX sockets, static memory regions, UNIX selects, etc, just that it wouldn't be portable).
And there is one advantage that Java has over staticly compiled languages.. It's JIT facilitates run-time optimizations.. Things that are RARELY ever utilized by static compilers.. They've always existed, but only big labels ever bother with them. Often this is useful in deciding which branches to take in if-statements, or to decide when to inline (cache-space/subroutine-delay trade-off)
Just to elaborate.. The main advantage of NIO is when you anticipate an arbitrary number of threads..
Conversely, when you have a finite number, 1-thread-per-stream asynchronous IO is VERY desirable; both in coding, and in some small ways even in efficiency (immeidate responses; limited only by context switching time).. In contrast, IO-multiplexing may have certain tasks take long periods of time (stalling other channels).. Then you have to manually keep track of such situations as you code and push them off to worker threads in certain types of problems.
But there is simply no substitute when you want thousands of simultaneous idle connections (such as message servers) for IO-MUX.
Not that it's better, just solves a particular solution.
Slashdot Mirror
Shouldn't be a problem.. Have you seen the latency on modern Cache implementations? We're already at a BEST case of 2 clock delays with minimal concurrency. We're seeing 8 and even 16 clock cycle delays for L2 / L3 caches. Cache has always been hierarchical.. The lowest latency is always very small.. What this technology provides is effectively extraction of L2 cache with the complete transparenc y of adding L3 cache.. Think 128Meg L3 cache 8Meg L2 cache; something completely impractical for regular general CPU design.. Since you can "upgrade" your cache by replacing a peer-chip, now you can pay-as-you-go.. Spend a thousand dollars a year, upgrading one cache chip at a time.. And we've seen what's happened with the SDRAM market once commodetized. Pretty soon SDRAM may dissapear completely, being replaced by (albeit high power) gigabyte SRAM L4 modules.
If cost effective, and if they can get past the alignment issues, this is spectacular.
Actually, I see a lot of code that has ifdefs in java. I have no idea why you are suggesting that this horrible method of coding is not available.
Firstly, many java apps these days are built with "ant", which contains a java tokenizer for God's sake.. This performs search-replace on the java code for special tokens; often based around version of th e JVM currently compiling the code or sometimes even based on the platform.
There are apache commons tools which can ask questions like isWindows, isUnix, bla bla bla, and so you KNOW there is platform specific code running around the open-source community.
I use a java editor which is very specifically tied to a particular version of java; it will physically not run on any other version. Subsequent releases of the editor use newer version.. It's very frustrating, but thankfully it's very easy to install multiple versions of JVM's on the same machine.
Moroever, if what you want is that totally different code is rendered for different platforms, consider this. Java HATES switch statements; only integers can be applied and most everything in java is an object; (whereas in c/c++ most things are integers; easily fitting into a switch statement). Thus if you want a switch statement, the better design paradigm is to have a base class and subclass it for each switchable item. Then you choose the appropriate derived class (I personally perfer hash-table lookups).. The advantage is that ANY redundant code in the would-be switch statement can be refactored out and reused in the base class. It's more elegant design, often easier to read; provides smaller, more concise code, bla bla bla.
So obviously if you can ask the platform which environment it is, then you can choose subclasses which implement the platform specific material.. This is much more elegant than littered #ifdefs in the middle of a conditional of an if-statement.
The argument of #ifdef performance is moot in java, since you have run-time optimization.. If you have an if statement that can not possibly be true, the compiler removes it. Thus an ant pre-compiler, resolves the equivalent of ifdefs. However, the JVM itself is likely to determine constancy (generally due to a finally clause) and thereby compile-in or out even run-time configuration exclusions. The bane and bueaty of java is that you've outsourced performance to a JVM vendor.. jRock is fast but unstable (in my experience), while sun and IBM are pretty good all around.
As far as platform issues exist. Java is slightly better than perl at being cross platform neutral (though perl is catching up). These two I would consider to be the best all-around cross-platform languages.. Sure you have kiddy languages such as BASIC or pascal (or elegant ones such as lisp).. But these languages don't work well with their host OS.. They don't translate paths correctly for one. Nor do they even allow multi-threading as java perl does.
Java is not without it's flaws, to be sure.. And even the repairing of flaws have left an unsightly appendage of sorts. But once you get past memory / CPU requirements, Java is one of my favorite platforms
OJB, torque, and hybernate are excelent well supported 3'rd party OODB tools which provide optimistic/pessimistic locking, Object caching (to speed up object-graph navigation) and near minimalistic support (especially when used with xdoclet).. You literally write the class as you would use it (not even fully mapping all the columns to fields if you don't need them), and create collections wherever you would have a 1:n or m:n association. Then in the javadoc prior to each data-structure, put a one liner in xdoclet form which allows the reflection-based (or intermediate compiler, depending on the technology) interpreter to determine how to associate your OO data with the relational data.
:)
If you use aspect oriented programming (aspectj or dynaop) you literally never even have to worry about how and when the data gets persisted or retrieved, since that's handled as a separate configuration (typically as a prefix or suffix to all create or remove methods within the model).
The caching system makes for faster operation than pure SQL when you have more than one query per operation. Yes you can obviously create a single custom query which does everything all at once, and this will be optimal, but for enterprise applications there are often too many unrelated activities going on. Having an intermediate layer cache the most-recently accessed rows (in their post-transformed state) means you don't have to worry about such performance issues... When profiling, you find the hot-spots and do some custom SQL to "pre-fetch" the necessary data so that subsequent sections of the activity are once again fast.
Probably not a one-size-fits all solution. But after several years of attempting various custom OO layers atom RDBMS's (specifically, postgres, MS SQL server), these open source 3'rd party tools have put me to shame.
You could use inheretance. postgres, for example implements inheretance in tables by internally performing the same search across all tables that are derived by the base table.
:)
So if, for example, you had a base tabe
create sequence unique_seq;
create table base (id bigint default nextid('unique_seq'), varchar(255) comment);
create table foo (my_data varchar(255)) inherents base;
create table bar (my_data int) inherets base;
select comment from base*;
Doing syntax off top of head. Internally this expands to
union
select comment from foo;
select comment from bar;
Granted since comments might be null, this is a waste of space and a violation of one normal form or another.
But as another poster pointed out, most modern database systems implement 64/128bit named pk's.
Cool idea though.
I have one good example of why the 2D data-strutures are not ending their lives just yet. spread-sheets. The world today is not run by databases, but by middle-management that use MS Excel to quickly throw-together vast collections of data and ask questions of that data.
While MS does provide a rudimentary database system in office, the defacto-standard these days is Excel. Yes it's a HORIBLE data depot (unreliable, corruptable, mangleable), but computers are fast enough and with enough memory that few in management can fully tax it's ability, so they rarely find a need to delegate out an Access or centralized database-system.
Modern Excel allows you to perform full blown SQL queries on a disconnected set of excel spread-sheets. And the fact that an excel editor is far superior than most front-ends to a database-backend is the real killer.
Since spread-sheets are fundamentally two dimentional objects, and they are so prolific in even the non programming world, I strongly challenge claims that suggest such facilities are pasee'.
I'm not sure if your argument is merely about SQL or whether you're referring to 2D flat structures. But even if it is only about SQL, I'd suggest that SQL can be far more expressive than a complex setup of pivot-tables in excel (which essentially performs the same operation as joins on a table). The fact that most GUI's are merely SQL-generators to a common ODBC backend is a testement to this.
Of course, I'm ignoring that using Excel to ask questions is often done in poor practice (slash had an article about how statistical applications should be used instead). But most OODB / RDBMS system designers don't bother with the statistics either.
Sorry, but you aren't reading the article correctly.
Bit-errors are "hardware" problems, not software problems. By definition, a software problem is due to incorrect coding - it assumes hardware that perfectly conforms to spec, and with zero error. It would be impossible to write software (on modern hardware at least) that compensates for all bit-errors. Yes we have ecc memory and caches, but they are only one component. Now reliable hardware errors can be corrected for in software (the division error in old pentiums, for example). Also high-probability error-points (such as inter-machine communication) is designed with explicit redundancy/error-correction/detection. BUT this is data, not the base instruction. I am not aware of software solutions to correct for software instructions. (Ok, perfectly redundent CPU's which an I/O comparator, but this doesn't solve the problem of the DRAM bit-errors).
As for SRAM, in the CPU, that's even more volitle than DRAM. It has much higher current requirements, and thus has a higher probability of heat-related errors. They change values more often than main-memory, and have MUCH higher performance requirements. Most SRAM has ecc these days.
The static part of SRAM just means it's continually held at a certain logic-level. But in modern CPU's that's contingent apon a steady input voltage. With millions of taps on the voltage (and especially with over-clocked CPUs with faster than spec switching times, and often over-pumped voltages) the probability of a temporary voltage drain on on of millions of taps is very high.
With DRAM, there is a very controlled simultaneous refresh of a row (or column, don't remember which). Depending on the technology (I believe SDRAM falls into this category, but I'm not completely sure; yes I know S means Synchronous, not static), micro-caches (read as static ram) exist for the purpose of fast column accesses. When switching rows, the cache is written back in parallel to the row. When a particular row has aged too long, general memory access is halted so that a quick DRAM -> SRAM -> DRAM can occur (e.g. a refresh). This all happens transparently within the DRAM (though depending on the technology, the memory-controller may have to send the appropriate signals).
My point there is that in these types of memory architectures, refreshes are no more dangerous than regular memory reads.. The only possible danger here is if a particular memory cell will expire (discharge) sooner than spec, but isn't caught during testing because it happens to be refreshed in the wrong order; it's thus a time-bomb waiting to be accessed in the right order in production-environment. But such a situation is reproduceable.
One other note.. I said DRAM is a symmetric operation.. This is because in modern DRAM the entire row is read or written to at a time (tens of thousands of bits). In SRAM,only a single cache-line (roughly 128bits) is read/written at a time. Further, in some architectures, there is simultaneous access to different sections of the cache (2 read, 1 write caches, for example). A registry is the ultimate cache with many potential input and output ports to each and every bit...
While you make several good points. I do have some counter-points.
A VM otoh does get this capability for free.
Let me qualify this as saying you don't have to do or pay for anything extra to achieve this.
Err... whether garbage collection gains or looses you performance depends very much on your application. I am not convinced that any garbage collector can even be theoretically faster than automatic variables.
By automatic, if you mean stack-resident variables, then I agree (with the caveat of dangerous code design), but if you mean malloc'd variables, then I don't see what the problem is. malloc has to worry about a great number of things, not least of which is memory fragmentation. I happen to have done a non-trivial amount of research on memory allocators; though I am no expert. Memory allocators can be optimized for allocation speed, fragmentation efficiency, concurrency, cache coherence, etc. but not all (obviously). As it happens, a copying garbage collector gives you all of the above EXCEPT when your buffer runs out; and thereby requires a garbage collection. So long as you you have large heap and you're not worried about the latency from garbage collection, then copying collectors are VERY fast. Allocation is literally a mutex lock, a stack-pointer range check, a stack-pointer increment, then a mutex unlock.
Now, because latency is often a real issue, most modern GC's apply additional complexity/logic which slows down the normal case to minimize the worst case; e.g. generational garbage collection which may require read or write boundry op-codes inserted. But code-wise, these varients are identical. Thus you achieve a flexibility not possible in a dynamic-memory-egnostic system such as c/c++.
I'd be interested to know how you have more control over the design of 3rd party libraries in Java than in C++
I didn't really mean design, but environment; Specifically in terms of the dynamic memory allocator. But, just to make the differentiation complete, java allows byte-code load-time modification. This is very common in "aspect oriented programming" such as in the database realm (JBoss/OJB) or object proxying. In Java, by introspection you can prepend/append/search-replace method calls or even individual instructions as need be. Note that this isn't any different than a custom pre-processor for C, but tends to be cleaner and thus doesn't require the [3rd party] coder to adhere to a particular convention.. Moreoever, this works on already shipped binaries, as opposed to requireing preprocessing to occur on the original source code.
Except that in enterprise computing (as opposed to scientific computing), we are not interested in JUST throughput, but more often the time-to-shipment of the application, and the robustness of the code. Robust code is often abstracted or is littered with superfelous code (i.e. redundant checks for nullity).
Code that is easy to read, easy to maintain is often not very performant, because you aren't allowed to make special-case optimizations at the code level, since they are often a nightmare for other's to interpret.
In terms of efficient elegant code, it is trivial to use a hash table over a linked list in java (in fact, linked lists are harder to implement). Thus a LOT of java code uses such O(k) algorithms. On the other hand, in c it's relatively easier to use bitmaps than a hashed set, and thus c has less overhead for a common practice. But, as a consequence, bitmaps often have an upper-bound (no more than 32 entries) (yes, I know you can use bitmapped c structures). But a hash table is easier to read and harder to screw up than a boolean-logic bitmap, so it is often a better choice for "enterprise code".
So my response is that it depends on how you define "efficient programming". Do you mean efficient execution (which really is optimized programming), or efficient writing and maintanance of code. I suspect you mean the former, but what you should mean is the latter.
What's more, as far as a business man, you have to weigh the cost of development time v.s. performance of application. Well written non buggy, easily adaptable code requires little future man hours, and can take advantage of moore's law. If the software is successful, "scaleable" code can run on ever more expensive hardware (clustering). Highly optimized software may not be easily clusterable, or may not lend well to adaptations; each adaptation would require re-optimizing the code. The classic example here is Java's "Reflections", where a text configuration file is often used to link unrelated code together. I see this a lot in databases where we map new tables to code which may or may not be a proper fit.. The reflective configuration handles the remainder of the impedence mismatching. Note that you can do this in c as well, but it wouldn't be the fastest solution by far.
if the JIT/javac/JVM uses profiling information, gcc should too, for fair comparison.
I disagree. What is being compared are stock products. It's like saying if this car has a turbo-charger, then it should only be compared to other cars that have a turbo-charger.
This is more like comparing a toyota to a mustang. The mustang can accelerate faster, but the speed-limits of highways prohibit it from traveling faster than the toyota could travel.. The fact that the honda gets better gas mileage and thus requires fewer pit-stops gives the toyota an ironic "average speed advantage" over the mustang in a cross-country race.
What is being shown here are two stock environments, "gcc" and sun's JRE. There are external profilers for BOTH gcc and java. What's more you can compile java down to assembly. But we are not testing a profiler or a cross-language compiler, we're testing the stock compilers.
The author did say he might try Intel's compiler next. Likewise, perfectly valid tests would be a 3'rd party profiler as applied to gcc or Intel.
My point is that the alleged java run-time profiling is merely an attribute of one product over another. If you required running a profiler on the gcc and not an external one on Java, then I would argue that Java is at a disadvantage, because java can't shut off it's internal profiler. ("-client" shuts off more than the profiler, it shuts off most of the useful jit as is thus a pseudo byte-code interpreter).
I'm inclined to agree with you, except that the benchmarks were qualified as talking about being relevant to enterprise applications. In such a situation, run-time optimizations are critical.
While it is entirely possible [in c/c++] to use a profiler to generate compiler hints so as to generate even more efficient code, this is rarely performed, and often is not free. A VM otoh does get this capability for free.
Additionally, the java memory manager has a slight edge over tradditional malloc's for total throughput (though the best throughput configurations have horrible spuradic response times). It is also possible to choose a different memory manager for c/c++, but this too is rarely used.. Moreover, it is much harder to have 3'rd party code integrate well with a garbage-collector model. Java enforces garbage collection, and thus optionally gets the particular performance gains (being free to trade off throughput for responsiveness no matter what 3'rd part code is integrated).
As was pointed out, one of the strenghts of C/C++ are pass-by-value, which allows memory allocations to be avoided all-together, but at the cost of copy-time and robustness of code. If a method call requires instantiation, c/c++ have the option of passing in a local [stack resident] structure to be populated by the method. However, this is fodder for buffer-overflow exploits, and notorious for otherwise bad code (accidently caching the address of a value that lives on the stack). Thus, given that c++ will use "new" and thus generally perform a malloc, the same performance issues above apply, and c/c++ may have the additional overhead of copy-by-value.
The fact that you have to explicity declare a c++ parameter as pass-by-reference suggests that those interested in "good programming practices" (tm) will only make a pass-by-reference if you intend to modify it's contents. Thus "clean" code in c++ will be copy-intensive... For fairness, clean java code should always make immutable wrappers for any non-modifyable code, thus requiring an all together different liability (and thus I can't make any claims as to which would be faster; wrapper object instantiation or deep parameter-copy). Though all primatives are available in java as immutable objects (Strings, Dates, etc). Moreoever, clean OO-code should always use method getters, and make all fields private (not even protected). Both C++ and jit'd java can inline these getters.
I haven't looked at the benchmark code, but the above are common components which make a big difference when scaling to large enterprise applications, or even when merely writing a glue application which integrates many large 3'rd party libraries. In c++ you don't have a lot of control over the 3'rd party libraries (in terms of their design trade-offs), but with a VM, you are largely sheltered and have many configurable alternatives.
I can't confirm the details, but it was my understanding that the Alan Cox fork in RedHat 9 had an implementation where the swap had to be at LEAST as big as main memory.. Theoretically the reason is that you preform pre-swapping.. The idea is that if you waited until the last second to do any swapping, then your most efficient choice would be to swap non-dirty pages.. but if instead during idle periods of IO you swap dirty pages, then when it comes time to swap, just about everything is fair game, and you can truely swap out the LRU pages with great efficiency.
Thus you'd pre-swap once you got to like 60% full memory.
More-over, as others' have said, unless you have as much RAM as the average hard-disk space used / day, then you are in a non-optimal operating environment, since your cache isn't as big as it should be.. cache flushing swapping.. They're almost identical in user-time experience (though aruably, re-reading a contiugous chunk of file-data is going to be faster than unswapping randomly positioned data; but how many files are contiguous these days?).
Thus if you have a daemon with a LOT of setup code which is never used again after startup, then it makes sense to permanently swap this out to disk to free up space for the cache.
Not usually true.. Simple economics, corporations are interested in profit maximization.. As the price of a good goes up, the quantity sold NECESSARILY goes down. The perfect price for a given audience is based on the aggregate demand curve (generally not a known equation, but rather can be approximated through polls/sampling/etc). From the demand curve, you can directly compute the marginal revenue curve (for straight line demand curves, the marginal revenue curve bisects it). You then take your cost curve, (which becomes more expensive as you produce greater quantities), and see where that intersects the marginal revenue curve. This tells you how many to produce (in a monopoly or in monopolistic-competition). You then can charge as high as the demand curve will allow for that quantity.
Now you can play dirty games when you lock customers in via licenses, since there is a barrier to exit, but even in this circumstance, existing customers have a demand curve, beyond which they will no longer accept your service, and you will certainly bar new customers from entering.
In any case, as you increase your costs (via taxes, fees, what-have-you), you raise the cost curve, BUT, the demand curve has NOT changed.. Moreover, presumably you previously chose a profit-maximizing position.. If you merely raise the price, and hold the quantity steady, then many of your customers will exit the market (as the demand curve REQUIRES). You will no longer be at a profit maximizing position, and WILL lose revenue.
Thus, in the face of rising costs (e.g. new taxes), you must recompute the intersection of the old marginal-revenue curve and the new cost-curve.. This will give you the new quantity to produce (which will be smaller than before).. You then choose the new price point on the demand curve at that quantity.
There are two types of customer-bases.. "elastic" and "inelastic". Elastic customers will exit the market at very small increases in price (say milk, gas, etc). In-elastic customers are essentially addicted to the produce (say medical drugs, cigarets, BMW's, etc). If you have an inelastic product, then you can pass on a greater percentage of your costs (possibly 100%) with little fear of losing customers. Especially if the entire market does the same, such that they can not substitute your product for a competetor.
If all gas stations or all cell-providers apply a $10 tax/fee to cell service, then subscribership should not go down much, since there are no alternatives for the "addicted" service.. However, you will necessarily exceed some house-holds' budgets, who will necessarily go down to a $30 + $5 plan, or simply drop coverage (paying the exit fees). Cell providers compensate by making their sub $40 services less attractive, which keeps more of their premium subscribers, but then completely alienates lower-budgeted brackets.
The key is that they are definitely monitoring the demand curves, and valueing out various scenereos. They know they what can get away with.. But the main point is that they do NOT just blindly pass along all costs.. What T-Mobile has recognized is that their particular demand curve can support a higher price, and that the best way for them to raise prices is to keep the deceptive $40/mo retail-price, and up it by nearly $10. The "new" taxes/fees are complete lies. It is deceptive advertising plain and simple.. NOWHERE does T-Mobile tell you that you are subscribing to a $50/mo plan when you sign up for their $39.99 plan. And this is what I think is wrong. They can morally charge what ever the heck they want for a service, but they should be honest about the costs. Especially with $150 cancelation fees.
On the other hand, my beef is probably because I'm use to a different sort of pricing tactic, called "sales" evaporation.. Retailers list a price MUCH higher than what the sell the product for.. They advertise the retail price all over the place, but when you get to the shelf, it's usually much cheaper.. So when the store wants to raise
Well, I think Descartes made a wonderful philosophical exploration, which ultimately showed that it would be impossible for God to convince us of his existence. Him throwing a light show would be little different than taking excstacy, or subsequent generations claiming that our generation had something in the drinking water.
The best that could happen would be regular guest appearances, from generation to genreation. But you have to consider what the purpose of our life and our role for God would be in such a circumstance.. IF there is a God, and IF we are fashioned in some manner compatible with any of the relgious texts (Hindi, Shinto, Jewish, etc), then there are certain rules to abide by. Philosophical rules. You can't have free-thinking if you control thought.. If we are some advanced program, computing the question to life-the-universe-and-everything, then it makes sence that our God doesn't already know the result, or that we are in a state of flux in God's synthesis of some as-yet-unseen future state-of-the-universe. Thus it would not be logical for God to be all-knowing, and all-powerful.. Our existence would be superfluous.
So, taking free-thought as a possible necessity of our existence (exemplified in the Jewish Genesis story), then the degree by which God was ALLOWED to control us (such that he accomplishes his goal) is deminished. The more God influences us, the less free we are. The more undenyable doubt he imposes on us, the less wonder and speculation we can produce.
It is logical that God would be a marginally absent God, AND that God would manifest itself in many incompatible forms, since this produces a healthy degree of diversity, opposition, congregation, etc.
The point of this is not to prove God, as I started out saying that it is impossible. But merely to keep the fire of the debate alive.
For most Americans, God is irrelevant, we have devized our own sets of "morals". We cling to a God-like figure, not because we crave justification for our suffering, but because we were brought up with theology, and the Pascal dilemma scares many people (if I don't believe and it turns out to be true, I'm f***d). While this is all fine and good, the danger is a certain progression into anarchy.
Adam smith shows how society is best off when everybody acts selfishly. We only tell the truth because we recognize that getting caught lying will ruin you business-wise. But those that are willing to risk not getting caught are more effective business-wise than those that refrain.. So eventually the truth-tellers die off and the successful liers will prevail. Sure there will be "market corrections" from time to time, but the general state must degrade.
Religion is a mechanism of control for regular "market corrections". Yes, it is often exploited, but if it did not exist for the lives of 51% of the population, we would surely devolve rapidly into self annilation.
Logic CAN be a savior, but only by creating a new religion of logic.. A congregation of watchful eyes, providing a high probability of being caught in counter-society acts. This is essentially 1984 or at least a religion waiting for exploitation.
My opinion is one of moderation. We need religion (of some form), but we need regular change (so as to unseat power figures); Absolute power corrupting absolutely and all.
And leading back to the beginning, if there is a God, and God is manipulating us here and there for God's purposes, and we are deviating too far from God's needs, then surely God will perform a market correction of some sort. That we have not had such a correction in quite some time implies that we are headed in the right direction.. Be it atheism (suggesting previous corrections were merely stories/ primitive interpretations of natural events), or moderated/alternating relgion.
All acts, categorizable as either good or evil, are so as to fullfill a personal need. Look at American Indian's who were very gracious hosts to the initial settlers. Was this because they had the fear and awe of God in them? No, it is because the had some very practical experience with how to manage small societies. And that experience told them that they needed to support their neighbors, because you never know when you'll need their help. At that time, the shore-side Indians had no advantage in raiding the settlers, and good will provided them certain insurance. Mind you, they most likely were not very methodical, this was simply learned practice; good manners.
Single-mindedness does NOT foster kindness/gentleness, etc.. Mainly because the probability of encountering one who is of a different mind is too great. This, as history shows, single-mindedness is more likely to produce unifying actions (which can involve aggression, imposing shame, acting immorally so as to produce a "moral" outcome (e.g. The ends justifies the means)).
When you are within the homogeneous society, then things can be peaceful, but as history has also shown, there has been NO evidence of non polymorphic religion or philosophy. Judaism morphed into orthodox and reformed. Christianity morphed from day two into dozens of wholely incompatible religions, was later unified through state-power, almost immediately divided again.. then finally divided into factions which wished to kill one another over incompatible ways of life (Irish/British). Arabic cultural religions (rooted in Abrahamism) morphed into Islam which, like Christianity, immediately apon their founders' death split into rival factions (which till this day war against one another). Same message, only differece is one of leadership (read power).
Do not confuse the tendency for like people to congregate, with the logical benifits of independently derived hospitality. A man can be wise, dumb, genereous, selfish, hateful, or caring. But a religion is about homogeneity. It serves a useful purpose (as it facilitates the individuals' personal aspirations), but religion in and of itself is a cold machine, who ultimately craves survival and growth (much like a corporation). And it should be treated as such.
Except that Jesus is proported to have died for original sin, not every-day sins. So the question is NOT whether each possible alien race has their own Jesus, but whether they had also pissed off their God in their beginning story, such that their devinity was revoked.
Except that Israel is in the middle, and for some reason, the US can't leave Israel to their own devices.. We have to keep funding them financially, militarily and politically, which is one of the main concerns that Muslim neighbors have with the US.
So, we'd not have ridden ourselves of any problems..
I'm nervous pointing this out, but in our E&M class we were directed to a pseudo-science web site (our professor assures us that the presented pseudo-science violates certain well understood principles).
But among the dozens of pdf's this web site provides, one is on the ocean rift polar flips.
rift.pdf
In short, what it says is that as the mid-atlantic rift rips apart, hot magma comes to the surface, and that liquid is a lesser magnetic conductor (lower permeability) than the pre-existing high iron-content solid's crust. This plus the 1/r^2 magnetic strength of the source of earth's magnetism (namely the core of the earth) mean that the magnetic fields generated by the solid crust to the left and the right of the mid-atlantic fissure are MUCH stronger than that of the distant core.
The effect of having a closer magnet oriented in the opposite direction is that the next cooling layer of magma will orient it's magnetic field in the opposite direction of the previous layer (to complete the regional loop). Thus every new mid-atlantic fissure eruption / layer, causes a new anti-parallel magnetic field... Presumably, this is what geologists are measuring when they find magnetic poles pointing in differing directions.
As another warning, the wesite uses it's pseudo-science to demonstrate that certain E&M effects would be greater than our classical E&M says it would be for such a fissure reverse polarization.. So please take with a grain of salt.. None the less, I tend to like simpler solutions than a chaotic tri-poled earth magnetic field, or whatever currently is the explanation.. The crux of this pdf makes intuitive sence from a lay-persons' perspective.
So if you can make a CPU which emulates x86 code as fast as the competition, then go right ahead and try.
The key is that software writers (other than assembly) don't care about hardware; they care about maximizing the number of customers. Customers want cheap, fast and good software and hardware. If most customers currently have x86, and it would cost more to develop for other platforms (think beta-testing on every type of hardware), then software makers can minimize costs, and expediate release dates by supporting only one platform. Since x86 is the historical basis, customers can mostly only purchase x86 software, so they maximize their utility by purchasing x86 hardware, and the cycle repeats.
To introduce incompatible (or innefficient at backward emulation) hardware, customers will have a minimial initial set of commercial software that will run on it. So they won't purchase the new hardware unless their work-station/desktop will run nothing other than core utilities (OS MP software, for example), and thus there is no market for software writers.
OS writers may love hardware enhancements, but they don't make the bulk of software demand. Video games, office software (ACT, exchange, visio, photoshop, Nero, etc) are limited to very vew platforms (MAC/x86), so you're giving up a lot, even with newer software.
Apple had enough monopolistic pull in the MAC software world to make the hardware transition. Windows / Intel do not have such pull; how long did it take to migrate from DOS -> NT? And the irony is that OS/2 was not serious competition, so what did MS have to lose by going full protected mode win32 in the early days of win98? The reason is that they were trying to maximize their revenue stream, and I trust MS, of all companies, to know exactly how to do so.
Here is what I would have suggested. AMD64 adds an entirely new operating mode of execution. This is identical to the Itanium x86-mode, EXCEPT that AMD kept the x86 instruction format. This reuses the I-decoder, and more importantly, garuntees compatible instruction formats. The Itanium SUCKS at running x86-code because there is an impedence mismatch between x86 and EPIC logical instruction units. The Itanium solves totally different problems than x86-assembly is asking the CPU to solve. If Itanium requires smart compilers talking it's exact langauge to operate efficiently, then running x86 is like being given driving directions in greek for a road in France when you're in New York. The only difference is that you happen to have the same logical output when you're done. To make matters worse, x86 compilers do all sorts of bizzar re-arrangements of code with the full knowledge that they're maximizing the concurrent execution and minimizing delays FOR THE PENTIUM IV. These bizzar arrangements are just line-noise to the Itanium which can in no way take advantage of the re-ordering, and often time is spend decoding and excecting the equivalent of noops.
The point is that, any radical divergence, even by AMD64 from the core macro-op concepts are going to have likewise impedence mismatches for running legacy IA32 code. Still, I don't know why they didn't make all instructions 32bit aligned, and simply have seperate instruction decoders for 64 and 32bit instructions. They could have preserved the logical units, and given a HUGE performance boost.. But I haven't read enough AMD-64 details to know the motivations in this respect.
C is inferior, yes. It's hardly dead though.
I think C deserves a little more respect than a blanket comment like this.
We still have assembly languages today for several reasons, even though it's been "dead" since the 80's. Driver writers, compiler writers, and high performance inner-loops of scientific apps NEED snippets of assembly.
Thanks to the design goal of c (as the paint on the metal), you can now program in mixed c/assembly and thus never have to actually write anything in raw assembly files anymore. But you still write with the intention of generating specific sections of assembly.
The people that write c are those that are resource conscious. I am not aware of ANY other language that is allows resource management as well as C. "performance" is just one resource, and I know many argue that JIT's counter-balance the performance advantages of optimized c. I still refuse to belive JIT's have ever approached -O3 performance, but am willing to concede that a well written VM app can perform acceptibly.
ButMemory is another key resource management position that sometimes requires hard computer science to derive workable solutions.. When you abstract how resources are utilized (via a VM), then it negates the value of such hard computer science. Note that this ONLY applies to a particular problem space. Though, a non-trivial problem space to be sure.
The point is thus that the classic paradigm of "the right tool for the job" is essential here. There are MANY problems that are best done with low level, very concise languages like c. Most OS components, VMs, or fast-duty-cycle applications should very well have core work done in c/assembly.
The obvious other end of the stick is managing large amounts of code, for which assembly need not apply, and c is indeed becoming a distant memory as I think you are implying. Yes, web-services and many such fast-to-deploy applications transcend c, but don't be too quick to write-off the value in having a generation of computer scientists that are not well enough versed at writing low level applications.
More interesting to me is the idea of a string inside a "potential-well", which tunnels for non perfectly-infinite barriors.
:)
From my undergrad days of Elec-eng. Infinite barriors do not allow quantum particles (like electrons) to pass. But anything less than an infinite barrior will allow even the most lowly energetic particle to pass with some miniscule probability.
It stands to reason that some of the energy in the hole is near the inside of the event horizon (due to density-distributions). So long as the hole is perfectly spherical, there will be no place from which highly concentrated energy can exceed the escape velocity.
But if we replace the point-mass of the hole with a ball of strings, then we have fluxuating/undulating HIGHLY energetic strings. By nature, this energy is not going to be uniform, and may very well be periodic. This may allow regular minute disturbances in the event horizon such that super-charged strings near that rupture points can escape like a black-hole solar-flair.
Such flairs would give information about the non-uniformity of the hole, and thus provide information about the structure of the inside of the hole.
It's no less difficult then trying to figure out the internal structure of an active star.
Further, my lay-mind considers that holes may be as useful to the cosmos as stars.. Providing some alternate structured energy-source. Gravity-waves? Worm-holes? intersteller weapons?
Generics just automate this downcasting.
My understanding of generics is that the type-cast is completely omitted.. If the compiler can PROVE that what is going in to the collection is a Foo class, then when you pull the material back out, no type-cast is needed. Thus it is in the retrieval of generalized objects that performance is saved.
So again, to my understanding there is NO downcasting.
That'll change once they start ramping up the clock speeds, and the effects of a longer pipeline become less significant.
I disagree.. I think that the performance enhancements were due to factors other than the lenghtened pipe and fast clock.. The clock merely compensates (currently badly) for the added [wasteful] buffers, longer latency, and deminishing marginal return on a single enhanced variable (clock-speed).
Intel needs to create a market for it's higher priced CPUs.. So by having a nominal performance chip, they can increase the other variables (cache performance being a big one), and thus charge an enormous premium.
I believe that they could go a long way to enhance the performance of their existing P4 archtecture, but they need more marketing power.. They don't want to waste time/money advertising Pentium 5. Additionaly, the "extreme-edition" moniker on a similarly clocked CPU is going to be a hard-sell. Thus they will make the most money on clock-enhancements.
AMD has the potential to capitalize on this by getting a higher benchmark rating, virtually for free, so I don't really see this as a big win.
The only issue is that it's cheaper to design a CPU with more stages than to optimize a lower-stage-count to get more Instr/sec. So AMD might not be in a position to get a truely faster cpu out any time soon, and relabeling their existing CPU's won't go over very well.
However, increasing the pipeline should allow Intel engineers to achieve higher clock speeds, as the longest transistor path will likely be shorter (faster switching times).
While this is possible, don't forget that adding more stages means adding more inter-stage buffers.. These buffers are pure wasted processing / switching time.
Since each instruction now requires passing through more total buffers, the amount of work performed each clock tick is even further reduced (compared to simply dividing the problem by the new ratio of stages).
Next, there is the classic trade-off of keeping those acursed pipelines full.. I'm not aware of us achiving pipeline saturation yet, so adding more stages merely means an even more sparse pipe. The only situation where more stages == more throughput is if most of the stages are busy.
And finally there's data-dependencies.. With a move to C++ languages (much of microsoft) and perl/java/CLI VM's running amuck, the number of instructions until a conditional branch / data-dependent-lookup is declining, and thus the performance hit of longer pipelines is sky-rocketing. Sure you can create a contrived nested loop benchmark that can fill those pipes, but that's not very practical.
IF the pipelines were fully decoupled (non interlocking), and the virtual threading (Xeon) worked well with it, then I could see these extra stages being of use. Otherwise, pure marketing.
Just FYI, this is fixed with NIO. The idea is that you have a generic class to a byte-stream, which MAY be backed by non-relocatable, non-gcable memory. I believe this would generally require a native method to set up the memory-block (or the use of some java library which already does), but the idea is that it is handled.
And while I agree with your argument that it's the paradigms of java which impeed it's performance, we are seeing ever more incursions of high-perf. paradigms enter into the core language (noting that you always had the possibility of writing such routines and UNIX sockets, static memory regions, UNIX selects, etc, just that it wouldn't be portable).
And there is one advantage that Java has over staticly compiled languages.. It's JIT facilitates run-time optimizations.. Things that are RARELY ever utilized by static compilers.. They've always existed, but only big labels ever bother with them. Often this is useful in deciding which branches to take in if-statements, or to decide when to inline (cache-space/subroutine-delay trade-off)
Just to elaborate.. The main advantage of NIO is when you anticipate an arbitrary number of threads..
Conversely, when you have a finite number, 1-thread-per-stream asynchronous IO is VERY desirable; both in coding, and in some small ways even in efficiency (immeidate responses; limited only by context switching time).. In contrast, IO-multiplexing may have certain tasks take long periods of time (stalling other channels).. Then you have to manually keep track of such situations as you code and push them off to worker threads in certain types of problems.
But there is simply no substitute when you want thousands of simultaneous idle connections (such as message servers) for IO-MUX.
Not that it's better, just solves a particular solution.