Language performance is complex. While increasing overhead by a constant amount is perfectly acceptible (e.g. every aspect of the language takes between K and M times as long) (this could be due to extra conditional-checks to validate run-time-data such as null pointers, etc), it's not acceptible for languages to have larger big-O notational times. e.g. instead of O(k) you have O(n), O(nlog(n)) or worse O(n^2).
In simple languages like C, you natively do efficient things (like variable manipulation, memory allocation (usually)), function calling, etc. But for example, in perl, method invocation is O(n) at best, and often involves dynamic memory allocation and thus can be O(nlog(n)). Note that this is JUST for invocation, to say nothing of what the function might try and do. It's effectively a constant operation in most other languages. Thus any tight loops really requires performance tuning possibly involving native libraries.
The whole point of big-o analysis is to determine the scalability. O(n) inside an O(n^2) loop is O(m * n^2) which could approach O(n^3) in the worst case. Imagine a client-side email reader dealing with thouands of emails per mailbox. Your numbers of transactions become impossibly large and any arbitrary computer speed will not suffice.
While I'm not up to speed on.NET, it facilitates C#, so I assume it handles struct-like data-structures. Java has heavy-weight data-structures, so it's much harder to write performant high data-volume-throughput algorithms efficiently (sometimes the JIT can make life happy at least).
Since our processors are only about 2,000 times faster (VERY loosly speaking) than we were 20 years ago, but we're dealing with data-sets thousands of times larger (amplifying the effects of O(nlogn) and O(n^2)), I suggest that performance always has, and always will matter. Thus we should never blindly trade functionality for inherent performance reduction. There should be a valid argument for each instance.
Even if the core was loaded, there's still the JIT. But serious, I can't imagine that it would affect run-time performance.
I'm no expert, but it's likely that many core components are written in C for the.NET server, where-as the java community shuns this (via native calls).
And yes, it does have special opcodes for strings (REP MOVB) too.
I'm relatively sure but these op-codes are somewhat inefficient from the Pentium on; they're recoded via micro-code. While it's possible to still optimize (via utilizing closer-to-metal assembly language), this generally falls into the category of vectored complex and slow code which benchmarks rarely consider. Further, any such optimized complexities could slow down the otherwise streamlined micro-code.
That being said, it's probably possible to achieve code-size gains (through cache conservation) due to the 8086 sized instructions. However, even this probably doesn't generally apply because both the Athlon's and the P4's try to store the assembly language decoded in pseudo-micro-code form in their lowest level caches. Therefore a required 4 -> 16 micro-ops might be larger than a gcc RISC compile version of the same string operation. (Note, read RISC as meaning non-specialized CISC instructions)
What the poster was trying to say (though it wasn't fully representative of the population) is that since building a PC can be an enjoyment, and sometimes even a communal thing, it's economic costs are reduced, since in some instances we would pay to have a "put-together" toy, such a puzzles, models, etc. So on a case-by-case situation, the lower purchasing price and the negative opportunity cost (due to enjoying putting it together) and having the thrill of running a machine that you know you've built, leads to lower total [economic] cost.
Further, the viral reduction and reduced administrative overhead of MACs do contribute to it's value (or rather, reduce the associated economic costs relative to a PC), but the lack of utility from having PC-centric applications offsets much of this. Further, sophisticated administrators can dramatically reduce viral instances (e.g. NEVER run email attachments, avoid using MS office, or at least restrict it' usage, have external fire-walls, etc). Unfortunately we can't all be savy admins, but I've been viral free running virtually every OS I've ever heard of for most my life. Yes it factors in, but again, on a case-by-case basis, this isn't as much a cost as you're suggesting.
Further, the "accounting" cost of having a lan party with MAC's is significantly higher than one of nicely configured PCs. So much so that it's often impractical for the average user. PC's allow downgrading parts (e.g. upgrading piecemeal, then when a new machine is purcahsed, the old parts can be re-instated), further reducing "accounting" costs, and facilitating greater utility from existing purchases. Most notably, I've NEVER paid more than $500 for a PC (thanks to component reuse), and consequently I have over a dozen machines at my house (switch boxed, networked, what-have-you). At any given time, I have 2 state-of-the-art machines. This could never happen with MAC's (especially the iMAC).
That being said, the original poster and myself don't constitute the majority of the population. For such cases, your arguments are much stronger. There IS an opportunity cost involved with building a machine for a friend or for a company. The responsibility alone adds to the economic cost. In such instances, I recommend Dells, Compaqs, etc, simply because support issues are too critical. Though often I'll point them to something like mwave.com or comp-fairs with pre-fabbed OEM systems with 3 year system warranties (and lifetime warrenties on parts). In general though, I'm NEVER as satisfied with a name-brand product as with a grass-roots product.. Grass roots OEM's provide linear expansion cost increases where-as name-brands make their bread-and butter off upgrades. Further, name-brands tend to produce proprietary parts with little 3'rd party support. (Packard Bell / Gateway use to be SUCH a pain in the ass). MAC's fall into this category, plus the loss of compatibility with the main-stream.
having a 20 cycle multiply kills you if you have even one instruction dependent upon the result of the multiply.
Not true. You're thinking of 20 stages being for the raw operation, when in fact, only a few stages are dependent on the actual operation, the rest are for setup (I-decode, mem/reg fetch, data-transfer) and write-back. Thus if i2 depends on i1, then both will go through the i-decode and register fetch, and only a handful of double-pumped clock-ticks will be wasted waiting for the output of i1; i2 will immediately proceed as soon as the data is available. (wasting possibly 2 to 4 [double pumped] clock-ticks).
Now I'm not completely sure about the P4 internal design, but I've studied the MIPs architecture and it's definately possible to have zero delays (except for branch mispredictions and non-register memory-loads). The only real limitations are if the added complexity of having look-ahead multiplexors on the data-input lines slows the rest of the system down too much to warrant doing so.
Further, having 20 stages means you can have a faster clock. Thus if only 25% of your instructions are data-dependent to a greater degree then there are a number of stages between instructions (e.g. if there would be any ACTUAL internal blocking), but you're clocked 50% faster, then you've you'll always have faster operation. If however, the faster clock speed means that 50% of your instructions run faster (saving 25% of operations to slow memory loads / complex FPU operations), then you'll have a total throughput which is signficantly higher.
These are indeed opposing forces. Having fewer stages with fewer gates in each doing more efficient work with higher clock-rates is an ideal. But all-things-being-equal, (materials/innovation/instructions/etc), deeper pipes tend to produce higher throughput (to a point for a given technology). Intel obviously must have simulated various numbers of stages to determine a given optimal point given the current technology. Though their minds were most likely clouded by the MHZ myth's marketing possibilities.
Well said, but it's more than just memory spaces, it's the more abstract concept of address spaces. For example, hard-disk sector numbering, or any resource enumeration. It dramatically simplies coding for such resources. Think of the number of penneys in the stock market. This number is in the trillions, so a nice 64bit int would be very nice (though not required as you suggest).
Shouldn't 16-bit chips be enough because as we all know 64k should be enough for everybody.
Cute, but just fyi, it was 640K, and that wasn't the limit of the CPU, it was a choice of where to end the user-memory space and where to begin the driver memory space.
See posting for details of why the 16bit x86 bit chip could do more than 64K.
I've seen several responses, and few were well informed. The number of bits is exactly equal to the number of digits the computer can work with.. Think of this as having a hand-held calculator with 10 digits. You can only do meaningful work up to those 10 digits. It's possible to represent larger numbers using floating point (exponential notation), but then you lose precision, since you can only display 10 digits worth of decimal (thus if you added 1 to a centillion, it would be rounded off).
Computers happen to use base-2 instead of base-10, so it needs more digits to do the same work as a 10-decimal-place hand-held. In fact, it takes roughly 32 bits to approximately represent those 10 decimal digits. 2 ^ 32 = 4 billion. (The 9'th decimal place).
Thus more bits, means you can represent a larger number (just like more positions on your calculator means you can represent the bigger salary of an enron executive). However, if all the numbers you're working with are small, then there's no benifit to having more digits. It just means more work for the poor machine.. PLUS there's a subtle slow-down associated with larger bit-counts.
Now there are several reasons why you'd want larger counts, and the most important is the memory size. 32bits gets us roughly 4 billion, or 4 Gig of memory, or even 4 billion clusters on a hard-disk (e.g. max of 4 billion inodes, etc). Going to 64bits gives us an unimaginably large number, but takes up twice as much over-head. 64bits / 8 bits/ byte = 8 bytes for a single number, as opposed to 4 bytes for a number. So the DOS FAT64 table would take up twice as much space, and so on with other File-Systems. Likewise all pointers and integers in memory would be 8 bytes instead of 4, increasing code size, and wasting precious cach-space.
Note, however, that it's entirely possible to work with larger number than your core can represent. Think of the calculator again.. If you know that the US budget is on the order of 2 trillion dollars, than you can just assume the extra left most digits and do all your work in the < 4 billion region, externally keeping track of all the carry's (just like in elementary math). Likewise it's relatively easy to combine multiple 32 bit registers to act as a 64bit register, though it takes some effort on the programmers part. Plus this isn't as fast as if it were simply a 64bit number to begin with.
Thus computer engineers have not arbitrarily increased bit-size from archetecture to archetecture. The original 8-bit machines worked fine for their embedded controller realms. 90% of all work was 8-bit, and so they could justfiy the expense of manually working out 16, 24 or 32bit arithmetic. Plus for certain important operations, the CPU would automaticaly combine multiple 8 bit registers to form a 16 bit address.
The beloved 8086 from which all PC's have derived used two 16 bit registers combined in an awkward way. Normally you'd think 2 concatenated 16 bit registers would equal 32 bits (and thus allow 4Gig of memory), but what they actually did was overlap most of the bits so that you really only had a 20bit number (which maxes out at 1 million). Thus The original IBM PC's could have up to 1 Meg of memory. The advantage was that you exclusively worked with 16 bit numbers which were REALLY small (2 bytes each) and REALLY fast (hardly any delay since you could optimize much of it's operation). However, the CPU had to perform an ADD for every memory access (since it had to produce the overlayed 20 bit number). Another problem is that while you could access 1 meg of memory, you could only do it 64K at a time. All arrays had to be <= 64k which is a REALLY big problem.
When Intel went 32bit, they kept the same crappy memory scheme of overlaying 16 bit registers atop a pointer-register. The only difference was that the pointers became 32bits. For most purposes this was sufficient, so only a single overlay was used. However, DOS compatibility required using one of the 16bit registers to provide an offset into a DOS memory frame. Theoretically it's possible to achieve higher than 4 gig of system memory on IA-32 machines through the use of these 64 thousand base-registers, maxing out at 48 bits. In fact, the CPU's actually allow something near this address space on their pin-outs, but very few motherboards accomodate this.. PLUS, a single application would have to be written in order to internally segment itself having arrays no bigger than 4 gig each (the exact same problem with 8086 16-bit register overlaying). Plus I'm not aware of OS-support for this capability (though it's theoretically possible). I'm pretty sure Linux doesn't support it at least.
Even though the IA-32's 16bit segment selectors are generally not used (except for 16bit mode DOS support), they're still an impediment, since they involve adding a base to a pointer on every operation. I'm not 100% sure, but I think this mode can be deactivated for performance enhancement, but other aspects of the IA-32 memory model involve such slow-downs.
RISC architecture, on the other hand uses bit-concatenation techniques to avoid having to perform additions for every memory access, and thus can provide clean memory access efficiently, though with no possibility for extension beyond it's physical register size (e.g. <= 4 gig).
An important thing to consider is that programs are designed to operate within it's address space. The larger the address space, the more advanced a solution can be programmed. In the 16-bit constrained world, for example, you'd have to artificially break a problem down into 64/32k chunks. In the 4 gig world, you can't treat arbitrarily large data sets; you have to worry about overflow for things like file generation, compressors.. pkzip can't backup your whole hard drive because it integer overflows after 4 gig, etc. More and more, we're hitting the 4 gig limit, and program designers say that's the user's problem; they don't bother breaking up their application into nice and neat 4 gig chunks because 99% of the time their applications won't hit that boundry.
By going to a 64bit space, developers can once again safely ignore the possibility of their application being used on ever larger data sets. No disk drives currently exist that would require >64 bit address spaces within a backup tool. It opens up a whole new avenue of uses for simpler programs.
-----------
In summation, bit-size does not strictly limit the largest number a CPU can natively achieve, nor does it limit the max memory size. However, it does facilitate efficient access of larger number-spaces. That larger number-space comes at a cost of CPU complexity/cost/ and even performance when 99% of operations don't warrent the extra size.. Still, as more and more common tasks cause us to run into the 4 gig limit, we have a choice.. Either program like we did on the 8086 and other 8/16/20/24 bit archetectures, manually segmenting the data-space into discontiguous chunks, or we move to platforms that natively give us headroom.
Superscalar performance is improved by using the larger registers to execute more instructions in parallel.
You're assuming that the 64bit registers equates to 2 32bit or 4 16bit. These are independent concepts. The PowerPC's Altivec (sp?) and Intel's SSE (and AMD's 3DNow) do what you're talking about, and this was all done with 32bit Integer cores. They simply added new specialized registers, or remapped existing registers.
Let's be clear here, the 64bit refers to the integer core. 64bit floating point registers have been here for virtually forever. Intel even has 80bit, and other RISC platforms tout 128bit floating point, but these provide only precision, NOT performance enhancements. (float v.s. double v.s. long double).
The only thing benifit 64bit provides is faster 64bit arithemetic (long int), which is essential for >4Gig contiguous memory spaces, but also for other types of calculations. The reason I say faster is because 64bit int-arithematic is possible with smaller registers, but only via emulation (though it's not as bad as you'd suspect since there's hardware support such as add-with-carry).
Recently we started using maxq. It has two modes.. One is a proxy server which you'd set your browser to. It records the post/get arguments you used for the page and records it into a jython file. The backend then uses HTTPUnit to fire off the pages.
It isn't a complete solution.. I had to create a perl filter work with mime-multi-part data, or indeed any form-data that has carriage returns.
But since it's a simple mixture of python and java, it was relatively easy to apply statistics to the processes and search for all sorts of possible error-types.
The problem with simple non-human web crawlers is two fold. First there are pages that require valid form-data. Secondly, a "nightly sanity test" is going to be operating on production data.. You'll need to carefully manage such data.
It still takes more than running Word to expose the contents of your hard drive though.
The article mentions that the reason this is an issue is because the manner in which files would be stolen follow a normal business process among corportate types... Receiving an email from a company member. Editing it (for markup or review), then sending an email to someone else. Secretaries are good candidates for generic attacks, since they'd often need to review documents. But even executives are prone to such unattentative activity.
(It has been a long time, but afaik, a simple fork() is not forking off a complete new process, but a childprocess which runs as a thread inside the mother process, or am I mistaken? (if not: why then the threadsafetly crap NOW, because a fork() will result in the same issues)
Forking is the process of producing an effective duplicate of a process at the point of the fork-system call. File-handles, and other system resources are maintained across both processes. In fact, the ONLY difference between them is the Process ID and the Parent Process ID. (Actually, I think system times might also have changed). The return value of the fork-call is either 0 (for child) or the child-process ID (for the parent).
Originally, fork would perform a complete memory copy. But in UNIX, the only way to execute a new program was to fork, then run exec*(..). So they invented vfork which wouldn't actually copy the memory. It's man page said specifically that you MUST run exec as soon as possible after vfork since you were still operating wih SOME shared resources (but it wasn't anywhere close to being considered a separate thread).
Now, virtually every UNIX platform has deprecated the vfork call. fork now sets a flag on all the VM page's meta-data called copy-on-write. In the real hardware VM pages, it generally just sets all owned pages to read-only. This causes a hardware exception whenever a write occurs. The OS then checks the OS-meta data for the associated page. If the copy-on-write flag is set then instead of throwin a core-dump, it produces an exact duplicate of the 4k (or what-ever) chunk of memory, then it resets writability of at least one of the pages (if there were only one forked process, then it sets writability to both the old and new VM pages, otherwise, it decrements the copy-on-write count for that page.
The net result is that when you fork in a modern UNIX system, it's pretty fast (aside from all the increments on the copy-on-write; e.g. if a process has 1Gig of memory, forking is a little expensive). In Apache 1.3, having a master process forking worker processes means that if a newly forked worker just dishes out a static page, then only a dozen or so VM pages will ever need to be written to, and thus 99% of all the memory will be shared with the parent.. Shared for caching, and shared for less system-over-head. Unfortunately if you're using mod_perl / mod_php, then you'll most likely hit lots of random portions of memory thereby triggering lots of hardware exceptions and VM-copies. Thus the longer a 1.3 process runs, the more memory it takes up (especially considering their memory heap-management). That's one reason why we have the kill-child-worker-after-X-requests option in Apache.
I'm not sure how mod_jk works. I don't know if it performs a sub-thread off each apache process, or if it works like tomcat4 with it's co-processing (like fast-CGI). I can't imagine that it would work well as a thread-per-Apache-Worker, because it modifies virtually every byte of it's memory space periodically.
In Linux, the only difference between threads and processes is that during the initial VM-reflagging, the copy-on-write isn't set; in fact that stage is completely skipped. Thus we save a tiny bit of performance on the initial call, and we are completely free to modify data without a tiny interruption.
Incidently, hardware exceptions are REALLY bad when done regularly because modern CPU's (Intel especially) have deep speculative pipelines and slow memory latencies. Thus an exception half-way up the pipe has to throw almost everything away. Then if/when the instruction is restarted (after cleaning up after the copy-on-write), it has to start back at the first stage (and all memory must be reloaded). While this is only a small fraction of general execution under forking.. Heavy amounts of forking can bring a system to it's knees (wasting some 90% of all CPU on the forking VM-copying process). I've seen this first hand with Apache and CGI or with a custom version of FastCGI where simply running Apache Benchmark (ab) made the system unuseble for 10 minutes (doing nothing but forking, and queing forks).
So in response to your question, the child is not "part" of the mother except that some resources are temporarily shared until they're modified. Because of the read-only nature, they are completely thread-safe (except for externally shared resources like IPC's and file-handles). Incidently, Apache makes great use of shared file-handles. The master process opens the port 80 socket, and it's workers get references to it (via the fork). Everybody except the master process then "accepts" on the http port(s). The OS then round-robin hands off new connection requests to the workers in turn. This was just a freebe of the UNIX model. In fact, the only "magic" that Apache has to use is an IPC shared memory segment (or shared file handle) in order to have the master process reap exceess child-workers.
Well, I think the key concern is that perl6 is being completely re-imagined. Instead of being a data-structure navigator, it's a byte-code interpretor. More importantly, the byte-codes are elementary operations instead of macro-operations which would otherwise be optimized. This is an example of a niche change.. Instead of doing it as efficiently or as cleanly as possible, they're going to be competing directly with python / java / C# byte-code-interpretors. And they'll fail for java because of binding differences inherent efficiencies.
I've seen the perl5 internals, and yes it can be messy. I _can_ see the desire to move away from macro's to functions; especially since a good compiler should be able to optimize this away. But perl6 is going to have several layers of indirection.
Further, I can understand the desire to move from ref-counted memory management to a copying-collector; it prevents having to free-the-mallocs. But you could have a hybrid ref-count-when-you-want, mark-sweep-when-you're-lazy. Perl's ref-counting manages strings much better than java's garbage collector; mostly because temporary allocations are immediately reclaimed in perl5, where-as they're just as wasteful as intermediately-lived object allocations in java.
On the one hand, Larry has decided to do a rewrite and avoid all the pitfalls associated with perl5.. But I'm not convinced that this total rewrite isn't going to have even more problems than when it began.. More importantly, it'll be in the same class as every other VM out there and thus not be able to distinguish itself.. And thus lose it's niche.
I'm more satisfied with the idea of a perl6 -> java-byte-code compiler similar to jython, since then you get to have the best of both worlds. A widely supported VM with all the huffman encoding of a perl language.
Still, I support the perl6 move; trying to help it be as good as it can given it's new inherent limitations.
perl 6 niche
on
Ask Larry Wall
·
· Score: 5, Interesting
perl 1-5 have been great UNIX configuration/management languages. This includes small-scale webserver platforms. It's very difficult to find any other language that is as versitile in this respect where it reigns in it's niche. It is the perfect combination of speed, power, simplicity and huffman encoding (especially given the co-UNIX-tools look-and-feel).
Perl 6 on the other hand, changes this formula around; favoring a more general solution that potentially reduces performance (due to abstractions), and deviates substantially from the UNIX-family-syntax - Namely: c-ish-syntax ( colon, question mark, select, exception-handling, etc), awk/sedish reg-ex's, raw c-libray-wrappers, etc. It was these very similarities that made learning and accepting perl so trivial since learning CIS and UNIX administration was sufficient to master perl in 2 days.
My question is: does perl 6 have a niche in mind? Or is it spreading itself too thinly; competing more and more against Java/python/C# and thus losing it's identifiable niche?
The HBO series (if you can get it) costs the prices of 3 rentels a month, and you get a selection of much more than that. Plus I've personally loved their programming of Spawn, Sex & the City, Sapranos (haven't seen yet, but it's critically(sp?) aclaimed), 6 feet under, and various other network-like specials that I do tend to enjoy (even though they have an obvious lower-budget feel).
The best part is that only one person in a group of friends really needs to get it (I only ever personally got it once several years ago during a promotion).
Through the use of digital VCR's (mostly computers) and broad-band, it's entirely possible to share among your friends entire libraries.
Further, the digital versions can come with component-video and Digital Dolby surround; something the networks are no where near ready for (the movies they play are generally too old to have the cinematic experience; especially coupled with commercials; who cares about The Tonight Show in HDTV).
Personally I hate sports, but that's available too.
"Flimsy"? I've been a professional Java developer for six years. I have written server software (running to Solaris and Linux) and client software (Swing applications running on Windows, Macintosh, and Linux)....
Number of Java crashes I have seen in the past few years: Zero.
Swing was horrendously buggy initially. In fact, we found many a case where the old java 1.1 cored on solaris (with and without swing; though swing had a much greater propensity to crash or hang). None of the companies I've worked with has dared use swing in production code, so I don't know how good it is these days.
As for robustness, I'd like to point out that core dumping isn't the only metric. Java uses more memory than any other language I've seen used at the enterprise level. (I'm sure there are worse, but I've not enountered them). Using any sort of swap with java is insane, because of it's garbage collection model (In my opinion, a mixed blessing at best). I've actually written several garbage collectors and memory managers, and my opionion is that any such mark/sweet or collector is not suitable for arbitrarily large enterprise apps. Once you can get your app into a state where it's out of main memory, you're thrashing to the hard drive on every gc. Heaven forbid your app actually requires more memory than you have physical by itself. It's bad enough when you have two competing java apps fighting for memory.
Personally, I prefer ref-counting, which adds run-time performance overhead, but avoids the swap-thrashing issue for heavy-loads. I know that java is capable of utilizing any garbage collection scheme it chooses, but the defaults are never ref-counting; even on such hungry apps.
The main reason I dislike non-ref-counted garbage collection is that a simple loop which allocates and throws away strings produces hundreds of thousands of memory allocations under many systems (such as in many jdbc drivers). These simple small and allocations would be trivial to maintain under ref-counting.
Sorry for ranting, but I just so happen to be plagued with these issues (a servlet engine idling at 298Meg even with different VM's and settings).
Further on the stability issue. Not allowing static linking, and allowing new versions of classes to sneak in and thereby cause crashes is a common occurance with that java-model.
Java is obviously only as stable as your computer,
So is visual basic, but I think make such a statement about VB is misleading, since even syntax errors can lay dormant in VB waiting for just the right section of code to be accessed; crashing your app. I definately believe java to be a robust "syntactic language", but the underlying platform is still very sensative to design and maintanance mishaps.
There is a large amount of indeterminism associated with Java.. When will it garbage collect, when will file handles be closed, how much memory is it going to need, etc. These things make it harder to design robust enterprise systems (though not impossible). These are the sorts of gotcha's that reduce Java' stability in my opinion. Yes you can design bad c-code, but it's almost impossible to attain determinism with java in some areas.
As far as "imagine running an entire OS with a single such point of failure", that is perhaps the most ridiculous thing I've ever heard. Are you suggesting the Linux kernel is not a single point of failure?
There is a javaOS, by the way. A hardware product an old company of mine created used it. And I'm not suggesting that linux isn't a single point of failure.. I AM suggesting that the platform the linux kernel was developed on is more inherently stable than java. The key word was "such", which meant my so called "flimsy" java being the weakest link and also being a single point of failure for everything. Thus the most stable you can get a javaOS pales in comparison to the most you can get with c. Granted, an initial build of a javaOS is probably going to be more stable than that of c due to java's inherent type-safety.
Java is getting better; yes. And VM writers are free to develop better memory managers. But it's still bleeding edge in my opinion. I wouldn't consider java as having 4 nines availability; especially if the latest features in each release are being utilized. What's worse, the fact that most old features keep getting deprecated, it's nearly impossible to maintain a properly robust API (e.g. to say, yes, java.io is finally robust since it's had 2 major versions behind it).
In the Summary part, there were these additional comments:
eliminating checked exceptions (as Bruce Eckel has advocated),
Don't know enough to understand what this means. Is he wanting to get rid of catch clauses?
limiting objects to a single thread as in Eiffel
My initial impression is that this is very good. I know that I was really worried when I first found that java only has single inheritance, but I've usually found work-arounds, and this definately seems a clean design.. Thus it shouldn't be too much of a stretch to accept this thread-isolation. I don't fully understand how it would work (do cross object method invocations require a transfer of run-time control? That seems terribly inefficient).
I know that perl5.8 / 6 is using a novel method of thread control. The app is multi-threaded, BUT, each thread runs a fully independent VM. Variables must be explicitly shared. It just seems very clean.
BTW, on Linux, there is no real difference between a process and a thread, so Sun's JVM is already "multi-process" on Linux.
You confuse me, because you obviously must understand the difference between threaded and multi-processed, yet you claim that there's no difference in Linux. There are numerous functional differences between the two. First and foremost, you have 100% isolation (sand-boxing). You're not concerned with race-conditions (well, you have to go out of your way to produce them at least), you have to explicitly share material (e.g. pipes or magical fork-aware objects), you're crash-proof (apache has a master process image; if one worker "thread" dies for almost any reason (baring OS problems), it VERY quickly forks a new worker which is 100% ready to go), and finally, MP has better caching issues with multiple CPUs (e.g. no shared and slow writable cache). To boot, while MT saves more total memory, MP more efficiently distributes it to workers. Non modified memory is freely shared in a safe manner (marked as read-only by the OS, and thereby efficiently cached by each CPU), and only modified memory gets moved. Granted, in JVM's garbage collector, the entire heap is constantly remodified.
As other's have said, I support the general idea of Apple method of sharing memory space between JVM's; though I don't know it's particulars. Most notably, the shared memory should be read-only (to avoid interdependency crashes). Next, it should only be shared per user (or at least copy-on-write), to disallow viral infections.
My concern is obviously for that of robustness. Java is already flimsy as it is in this respect (imagine running an entire OS with a single such point of failure).
Maybe I misinterpreted the original post, but I thought that this had more to do 64-bit vs. 32- bit (and the limitations of a 32-bit platform) than it has to do with AMD vs. Intel.
While we're extrapolating a lot from so little information, I happened to get the opposite impression. 32 -> 64 isn't that big of a deal for Linux since it's already readily available. The big issue is the uniform adoption of AMD's x86-64 or a rift in the x86 32/64 migration path. It would be horrible for the industry in general (not just Linux), if the application base was split between two high-volume 64bit implementations. I would love to see an x86-64 binary rpm work on both intel and AMD; thereby minimizing how maintanance issues.
Personally, I love the x86-64 memory architecture; it's more RISC-like, and begins to chuck away the old 16-bit mode legacy mutations. I get the feeling that Linus was excited by the new kernel-specific features in the archetecture, and thus would probably like to see that become the main-stream linux driver-set. Pure extrapolation here though.
Two things. First, the newer perl camel book contains just about everything you need to know, so you could just reread the appropriate sections of interest there.
Secondly, and more importantly, the way I've managed migration is to simply reread the man-pages. If you've ever read the perl man pages, they're rather nice. Most importantly, you'll recognize a lot of material from previous reads. Thus for each new version, I simply skim certain man pages (like man perlre).
Next, I've noticed in the past couple releases, there's a man perl5005delta, and now perl56delta and perl561delta.
In terms of man pages for reg ex's, each feature stands out, and you'll quickly come to learn the (xx..) commands. There are definately a couple that stand out in terms of usefulness: (?=..), ?!, ?<=, ?<!, and possibly ?>. These involve look head and behind assertions (and their negatives). The last one is a non-backtracking forward expression.. Great for avoiding nearly infinite backuptracking issues.
And, in case you don't find a good collection of info. I'll throw this change.. "our" is now the global equivalent of "my". It replaces "use vars qw($x $y $z);". I say this because I wan't as much perl code to do this as possible.
...cooling will raise the "speed" of the chip, which in turn will add heat, which will counteract the cooling you do.
But it can't make it worse than it was. Yes there is a paracitic resistance to increases in performance, but that's like the graduated tax-scale.. You can't lose money by making more, you only get taxed at a greater percentage for each additional dollar (not the preceeding dollars).
We used clearcase extensively at an old company of mine, and it was great for internal projects. I definately don't think it has any place for open-source, however. Mounting file systems over the internet is definately out.
As someone pointed out, many of the types of issues questioned in this tread are configuration management issues, not version control issues. Case in point, as powerful as clearcase was, we developed a MASSIVE set of wrapper scripts to automate many regular and complex tasks. These scripts would have been portable to many styles of version control (though probably not CVS).
The main thing I didn't like about clearcase was it's dependence on the central server. I personally hate operating off mounted file systems. They're great for sharing info, but I've flat out refused to make my home directory nfs'd for a good reason.. It's slow and unreliable. There's always a point where something goes wrong or some administration is going on behind the scenes, and your desktop freezes. Likewise compilations are many times slower due to massive accesses to medium to small sized files.
It is great for administrators though.. Backups are a sinch (since distributed data is all really stored centrally). It's also somewhat scalable since you can have separate servers perform different functions.
It is expensive, however; both in licensing and hardware.
Only problem with perforce is it doesn't support distributed offline work.
You have to connect to the central database for EVERYTHING. All files are locked until you manually checkout a file. If you have a slow network connection or disconnect periodically, you have to reconnect every time you want to make a change (add a file, edit a file, change attributes on a file, see what files have changed, etc).
For open source development this can be a major problem.
Further, a centralized database can be problematic for separate development trees (not branches). The best you can do is copy the database to a new machine and run from there.
One feature I like of "arch" is that you can have decentralized development with independent trees/databases, and merge them back into the main database at a later date. There are several frustrations/limitations with arch so I'm not recommending it, just showing that someone else has solved this problem.
In general, I like CVS's (and arch's) view-private meta-data which allows a subset of operations to be performed. Not least of which is which files have been changed,and the ability to modify files without central authority. Other than that, I like just about all the features of perforce.
You're discussing a different question, that of our existence, which is not the same as the question of the existence of deities.
Yes and no. Many philosophers spent their lives trying to prove existence through the use of the proof of dieties. Descartes merely managed to prove a questioning being exists as that which questions, and kant rationalized that a fact (a more useful component of existence, or truth) is something that can be traced to a time and a place. They both heavily delved into theological proofs, but I've been utterly unimpressed by those approaches. My point is merely that the two questions are usually intertwined.
Science tells us how things work, but it very rarely answers any real "why" questions, or at best, it pushes them back a level.
For example, Newtonian physics didn't tell us anything about what gravity "is" - it's simply a mysterious force generated by mass.
...
but says nothing about what spacetime "is" or what warping of it "means".
I disagree. And further return the finger of misleading back towards you. It's possible to phrase a question such that an obvious (but incorrect) answer manifests itself.
Newton quantified gravity, and you say he was incapable of saying why gravity is or works. But another point of view is to say that he created gravity to say "why" things fall. "why" do planets orbit the sun (or the moon the earth). "why" are there tides? Why is there the phrase "all things that go up, must come down". Further, the science of force tells us "why" a bird can fly, and more importantly, an understanding of this question allows us to formulate theories on how we too can fly.
Science is filled with questions and answers for why. Relativity, quantum physics, string theory, and ethereal-theory all attempt to answer questions left after Newton. That is the beauty of science, we're never left with a lacking of questions of why. Most importantly, it constantly finds answers to many of them; Just maybe not the ones we're interested in at the moment. Many of the answers are to questions we didn't even know we needed to ask (such as with nuclear science).
As for the "why's" of existance. It may be a useless question; much like asking, what is the significance of a roll of 3 comming immidiately after a roll of 2. Perhaps in some particular context the question is important, but outside that context it's patently useless. We ask why do we exist for several reasons (actually, I personally don't ask the question because I don't fall into that context; I don't have a need to know that why. Life seems to make sence without it); We ask it because we feel empty and need some purpose / challenge / destination. This mentality easily manifests itself in a society based on conquest / advancement / rewards and punishment. But this is much like looking at some distance, noticing that it's finite, then assuming that if a finite length can exist, it's opposite, an infinite, must also exist. Thus we can speculate that distance can be infinitely long (though much scientific logic and evidence contradicts this for our universe; e.g. the logical thought that the universe can not be both infinitely old and infinitely large which requires a white sky instead of a black one.). Likewise, we can see the pattern that short durations of life can be made more meaningful through accomplishment and the over-comming of hardship and thus attempt to apply it to the entirety of not only one's life, but all existance. There is, likewise, no evidence that this is the case, and further, the rampant proliferation of rewarded evil-doers and abused altruists poses tremendous evidence contrary to such a mechanism. e.g. people that don't work hard get rewarded, people that never endure hard-ships have triumphs, those that strive for what is right are made to look bad, stolen from, started over, die young, etc.
Note that this doesn't disprove why-filled existance, but merely says that those that have faith in a particular "why" have no empirical evidence, and are thus imagining things (even if their imagry turns out to be true in the end).
What's more, the point of science for eyons (e.g. zillions of moments.:) has been to combat societal arbirary dogma reguarding the why's and more importantly the constrained how's (e.g. theologically enforced rules). Plato's dialectic was an attempt to argue with his jailor about the reasoning for his imprisonment. The cause was that he violated some theological dogmatic rule that had no logical basis. "Why is it wrong", he asked. "Because the Gods say it is wrong". But of course, nobody had ever heard the God's speak, thus the information could eventually be traced back to some human theologan. In our retrospective point-of-view, we easily label them as arbirary pagans with primitive and unfair legislation. But we're no better today. We feel with Christianity, Judaism and Islam that we have a good handle on morality, but in fact all come to differing conclusions on contemporary problems.
The "whys" of today are no more determined by theology than by science. Theology can say when it's all right to have an abortion, e.g. some theological figure can make some analogy / parable / declaration which provides difinitive direction for their flock. Likewise science can say when there is a self sustaining level of biological activity within the fetus or pre sex-cells. Both approaches are heavily subject to interpretation, but do offer mechanisms for truths. And as with our discussion here, provide some satisfaction that we understand "why" something is right or wrong. i.e. I might understand that a sex-cell is not a whole person, and thus morally accept any abuse of sex cells, so long as they're not mated. Thus would argue that all abortion is illegal. Though religious conservatives tend to make this claim, they use science - NOT theological dogma - to make this claim. And of course, this is a dangerous game, because I can say that the half cell has all the required elements to "live" as a skin cell or a neuron or a heart cell; It can process food into energy and atuate that energy in a self-promoting fashion. It can regenerate it's cell walls, etc. etc. Thus I personally would argue that all life is equally valuable, no matter it's insignificance; from a sexless ameoba to a multi-cellular televangelist. Most importantly, this implies that plants are just as alive and valuable as animals, so I'd argue that vegans are completely deluded (as opposed to vegetarians, who may simply prefer the more delecate diet). The counter-balance to this is that my use of science says that ther is no hardened line for such a moral question. The "why" is this law valid blurs away, just as "why" does gravity work fades. My answer to both is that we're not spoiled little humans that have all the answers presented on a silver plate. We're going to have to work hard (individually or as a group) to resolve these unanswered questions. What is the appropriate threshold between killing and murder? What is the extent that we can discern and utilize cosmology?
Why do we live? Personally, I say this is another useless question. I say that to "live" is scientifically ambiguious and thus a misnomer. More properly, if categorized with consistent labels such as compatible with organic molecular structure, or at a higher level, obtaining self-consciousness, we can easily answer many moral questions. Unfortunately, science must constantly revise it's categorizations.. From "what goes up must come down", to "force fields, which include gravity", to "relativity, which handles high velocities or massive bodies", to quntum physics which redefines small spaces to string theory, which redefines the number of dimensions in which we live. When dealing with science, we simply have to "live in the moment" and trust our current understandings. With religion, we have to "let go of our self" and give in to another's interpretation of divinity. Similarly with faith (which is more general than organized religion), we have to place values on experiences that often frustrate our desired courses in life (e.g. historical "profits" and "saints" had experiences that made them believe not only in an almighty, but in the almighty's plan which required timultuous life styles from them, such that others would follow and benifit).
There are several dynamic forces at work here, and whenever you have dynamics, you don't have absolutism.
Negative forces: Economic free rider problem: Person one pays for a good/service, and person 2..n benifits for free. The problem is that if a firm knows that only 1 person will purchase, then they either have to fully charge, or not produce.
Lack of control: When you control a comodity, you have a monopoly and can have secondary incomes ($4 drinks at the movies, for example). It's not garunteed profit, but it always helps. Presumably if secondary income is great enough, you can even reduce the price of the main good (i.e. MS Windows, amusement park entrance fees, etc) to maximize revenue. The music industry has numerous secondary revenue's. Most importantly, control over what is a best seller. Radio-brainwashing and store-marketing are key to make a pre-determined best seller. Search-based music downloading removes promotional viability. The general effect of brain-washing is to produce die-hard fans. I suspect that research would show that a hardened fan will spend more dollars than a casual fan (I know many such people). Thus it pays to have a fully polarized population; no matter what particular artist they're obsessed with.
Open Market: The more competitors, the lower the viable price. If new *good* artists choose not to sign with record companies (because of the generation alternative distributions), then there will be popular media titles outside the revenue streams of existing big media. Since there's a limit to the total capable media-expendatures (namely everybody's income scaled by some reasonable amount), this necessarily reduces the amount of existing media giant purchases.
Positive forces: Better competition: With the open-market item, more competition usually leads to more variety and better quality (though quality can go down when companies compete on price alone; but this doesn't seem to be the case in entertainment fields; there are enough consumers that are willing to pay premiums for entertainment).
Cheaper: More efficient distributions means lower costs. (Don't have to print CDs, artists don't necessarily have to spend marketing dollars)
Less purchasing risk: A negative effect of media marketing tactics is that you often purchase CDs which have minimal enjoyment (just as much as you knew it had to have, but not an ounce more; i.e. only liking a single song on a CD, sometimes less). A common tactic is bundling uninteresting goods with a single high-ticket item, and raising the price accordingly. MS learned this tactic well. With an search-based system, only the interesting media ever need be acquired. Thus the consumer would be less averse towards a given purchase (even if music is acquired for free, there is the economic cost of wasted bandwidth or time spent listening to bad music). Even if the consumer ultimately didn't like the media, they must have had some interest in acquiring it (word-of-mouth, flashy titles, etc).
Greater economic welfare: Along with the above reduction in purchasing risk is the increase in the number of consumers that purchase what they want, which counts as increased utility. High economic welfare can be interpreted has having a greater level of total happiness.
Luxury utility: Rational people maximize their time and minimize their frustration. This means that people are willing to make tradeoffs, such as exchanging money for services or goods that make their mundane work go faster, or go-away (such as hiring an accountant). Obviously, the more wealthy a person is, the more likely they'll spend money on simpler and simpler things (like parking a car). The same applies to the media industry. Some people will pay to not have to deal with burning a CD, or finding music, then downloading it. Beyond a certain point of wealth the time spent doing these things takes away from time working (e.g. physical loss of money) or in relaxing (time spent away from work). Thus there is a definite demand for the service of collecting media and making it readily available (such as a theater, the radio, or venues such as music stores (even online ones)).
Conscious: Many people will obide by their conscious; feeling a desire to do good and support good things (such as artists that they like). It's the same as droping money into the hat of a street-musician. They too are plagued with the free-rider problem, but find some semblence of an income. In some european countries, you even have to audition to be allowed to perform in the subways (since it had a definite market). When you download trial-ware software, you're encouraged (on the honor system) to pay the author if you like it. A rational person will contribute since they know it'll encourage more such software which focuses on pleasing the consumer. The other aspect of consciousness is that when we go out of our way to circumvent a form of security, we know that's we're idealistically hurting someone else (if I sneak into someone's house, I'm hurting their sence of autonomy, whether they catch me or not). To continue with the act we either justify it (they make too much money anyway), live in shame or blow it off (usually a person that can casually blow things off tends to do so in all aspects of their life; psychologically being hardened). In general, the more good-willed a society is, the less hardened the people will be, and the less likely they'll have reasons to justify their free-rider position, equating to more good-will payments.
Media Quality: Lets face it, currently MP3 isn't viable on hi-fi. It's possible to make this the case, but it's generally inaccessible to the majority of the population. How many people know how to hook up their computer to their stereo. How many people know how to turn downloaded MP3's into PCM files capable of saving onto a traditional audio-CD (playable on the hi-fi)? If a person doesn't care about the quality of highly compressed audio, and they have sufficiently high quality computer audio equipment, then this isn't an issue. But there are those (myself included) who are frustrated by _any_ popping or lack of quality due to audio-compression (or lack of full surround capability). Bandwidth is still too constrainted to acquire decent quality (DSL/cable only uploads at 15KBps), to say nothing of video quality. While this is only a temporariy issue (assuming we ever get to home gigabit down/upload streams), it still causes people like me to seek out legitimate DTS CDs, DVD-Audio, nearly-original-quality DVDs (meaning that even DVD does compress the video in sometimes noticable ways). Thus while I always try to make mp3 copies of my purchased CD's, I still make use of my originals in a CD-juke-box. Sure it lacks the flexibility of my mp3 jukebox, but this does not mean I don't have additional utility. Further, most people don't purchase RCA output jack-capable sound-cards (usually the Sound Blaster Gold series), so 1/8 connectors definately lose something over my fiber-optic CD-player-to-reciever with 14 gauge monster-wire-to-speakers-which-spread-throughout-m y-house.
Tangibility: There is a bizzar human essence (or psychosis if you like) that desires tangibility. People tend to not feel content unless they can regress to their childhood and physically feel some otherwise abstract concept. To hold a CD, to know that even if my computer crashes, I still have my "originals". To "own a house", or "own a CD collection", are irrational, yet undeniable urges. There are many subtle undertoning advantages to such tangibility, but our higher level mind simply attributes the "good" flag to it. Thus, even though we might download a Nine Inch Nails song, we might purchase the CD and the DVD-video just to "have it". I believe that this is probably the single biggest contributor to the napster golden age for the media giants.
Summary: Negative. The only negative that affects society as a whole is the free-rider problem which ultimately says "don't produce".
Positive. There are natural financial markets in the media industry that counter-act the free-rider problem; namely good-will and quality-persistence (hi-fidelity), with the subtle tangibility aspect looming in the distance.
Slashdot Mirror
Language performance is complex. While increasing overhead by a constant amount is perfectly acceptible (e.g. every aspect of the language takes between K and M times as long) (this could be due to extra conditional-checks to validate run-time-data such as null pointers, etc), it's not acceptible for languages to have larger big-O notational times. e.g. instead of O(k) you have O(n), O(nlog(n)) or worse O(n^2).
.NET, it facilitates C#, so I assume it handles struct-like data-structures. Java has heavy-weight data-structures, so it's much harder to write performant high data-volume-throughput algorithms efficiently (sometimes the JIT can make life happy at least).
In simple languages like C, you natively do efficient things (like variable manipulation, memory allocation (usually)), function calling, etc. But for example, in perl, method invocation is O(n) at best, and often involves dynamic memory allocation and thus can be O(nlog(n)). Note that this is JUST for invocation, to say nothing of what the function might try and do. It's effectively a constant operation in most other languages. Thus any tight loops really requires performance tuning possibly involving native libraries.
The whole point of big-o analysis is to determine the scalability. O(n) inside an O(n^2) loop is O(m * n^2) which could approach O(n^3) in the worst case. Imagine a client-side email reader dealing with thouands of emails per mailbox. Your numbers of transactions become impossibly large and any arbitrary computer speed will not suffice.
While I'm not up to speed on
Since our processors are only about 2,000 times faster (VERY loosly speaking) than we were 20 years ago, but we're dealing with data-sets thousands of times larger (amplifying the effects of O(nlogn) and O(n^2)), I suggest that performance always has, and always will matter. Thus we should never blindly trade functionality for inherent performance reduction. There should be a valid argument for each instance.
Even if the core was loaded, there's still the JIT. But serious, I can't imagine that it would affect run-time performance.
.NET server, where-as the java community shuns this (via native calls).
I'm no expert, but it's likely that many core components are written in C for the
-Michael
And yes, it does have special opcodes for strings (REP MOVB) too.
I'm relatively sure but these op-codes are somewhat inefficient from the Pentium on; they're recoded via micro-code. While it's possible to still optimize (via utilizing closer-to-metal assembly language), this generally falls into the category of vectored complex and slow code which benchmarks rarely consider. Further, any such optimized complexities could slow down the otherwise streamlined micro-code.
That being said, it's probably possible to achieve code-size gains (through cache conservation) due to the 8086 sized instructions. However, even this probably doesn't generally apply because both the Athlon's and the P4's try to store the assembly language decoded in pseudo-micro-code form in their lowest level caches. Therefore a required 4 -> 16 micro-ops might be larger than a gcc RISC compile version of the same string operation. (Note, read RISC as meaning non-specialized CISC instructions)
What the poster was trying to say (though it wasn't fully representative of the population) is that since building a PC can be an enjoyment, and sometimes even a communal thing, it's economic costs are reduced, since in some instances we would pay to have a "put-together" toy, such a puzzles, models, etc. So on a case-by-case situation, the lower purchasing price and the negative opportunity cost (due to enjoying putting it together) and having the thrill of running a machine that you know you've built, leads to lower total [economic] cost.
Further, the viral reduction and reduced administrative overhead of MACs do contribute to it's value (or rather, reduce the associated economic costs relative to a PC), but the lack of utility from having PC-centric applications offsets much of this. Further, sophisticated administrators can dramatically reduce viral instances (e.g. NEVER run email attachments, avoid using MS office, or at least restrict it' usage, have external fire-walls, etc). Unfortunately we can't all be savy admins, but I've been viral free running virtually every OS I've ever heard of for most my life. Yes it factors in, but again, on a case-by-case basis, this isn't as much a cost as you're suggesting.
Further, the "accounting" cost of having a lan party with MAC's is significantly higher than one of nicely configured PCs. So much so that it's often impractical for the average user. PC's allow downgrading parts (e.g. upgrading piecemeal, then when a new machine is purcahsed, the old parts can be re-instated), further reducing "accounting" costs, and facilitating greater utility from existing purchases. Most notably, I've NEVER paid more than $500 for a PC (thanks to component reuse), and consequently I have over a dozen machines at my house (switch boxed, networked, what-have-you). At any given time, I have 2 state-of-the-art machines. This could never happen with MAC's (especially the iMAC).
That being said, the original poster and myself don't constitute the majority of the population. For such cases, your arguments are much stronger. There IS an opportunity cost involved with building a machine for a friend or for a company. The responsibility alone adds to the economic cost. In such instances, I recommend Dells, Compaqs, etc, simply because support issues are too critical. Though often I'll point them to something like mwave.com or comp-fairs with pre-fabbed OEM systems with 3 year system warranties (and lifetime warrenties on parts). In general though, I'm NEVER as satisfied with a name-brand product as with a grass-roots product.. Grass roots OEM's provide linear expansion cost increases where-as name-brands make their bread-and butter off upgrades. Further, name-brands tend to produce proprietary parts with little 3'rd party support. (Packard Bell / Gateway use to be SUCH a pain in the ass). MAC's fall into this category, plus the loss of compatibility with the main-stream.
having a 20 cycle multiply kills you if you have even one instruction dependent upon the result of the multiply.
Not true. You're thinking of 20 stages being for the raw operation, when in fact, only a few stages are dependent on the actual operation, the rest are for setup (I-decode, mem/reg fetch, data-transfer) and write-back. Thus if i2 depends on i1, then both will go through the i-decode and register fetch, and only a handful of double-pumped clock-ticks will be wasted waiting for the output of i1; i2 will immediately proceed as soon as the data is available. (wasting possibly 2 to 4 [double pumped] clock-ticks).
Now I'm not completely sure about the P4 internal design, but I've studied the MIPs architecture and it's definately possible to have zero delays (except for branch mispredictions and non-register memory-loads). The only real limitations are if the added complexity of having look-ahead multiplexors on the data-input lines slows the rest of the system down too much to warrant doing so.
Further, having 20 stages means you can have a faster clock. Thus if only 25% of your instructions are data-dependent to a greater degree then there are a number of stages between instructions (e.g. if there would be any ACTUAL internal blocking), but you're clocked 50% faster, then you've you'll always have faster operation. If however, the faster clock speed means that 50% of your instructions run faster (saving 25% of operations to slow memory loads / complex FPU operations), then you'll have a total throughput which is signficantly higher.
These are indeed opposing forces. Having fewer stages with fewer gates in each doing more efficient work with higher clock-rates is an ideal. But all-things-being-equal, (materials/innovation/instructions/etc), deeper pipes tend to produce higher throughput (to a point for a given technology). Intel obviously must have simulated various numbers of stages to determine a given optimal point given the current technology. Though their minds were most likely clouded by the MHZ myth's marketing possibilities.
Well said, but it's more than just memory spaces, it's the more abstract concept of address spaces. For example, hard-disk sector numbering, or any resource enumeration. It dramatically simplies coding for such resources. Think of the number of penneys in the stock market. This number is in the trillions, so a nice 64bit int would be very nice (though not required as you suggest).
Shouldn't 16-bit chips be enough because as we all know 64k should be enough for everybody.
Cute, but just fyi, it was 640K, and that wasn't the limit of the CPU, it was a choice of where to end the user-memory space and where to begin the driver memory space.
See posting for details of why the 16bit x86 bit chip could do more than 64K.
I've seen several responses, and few were well informed.
The number of bits is exactly equal to the number of digits the computer can work with.. Think of this as having a hand-held calculator with 10 digits. You can only do meaningful work up to those 10 digits. It's possible to represent larger numbers using floating point (exponential notation), but then you lose precision, since you can only display 10 digits worth of decimal (thus if you added 1 to a centillion, it would be rounded off).
Computers happen to use base-2 instead of base-10, so it needs more digits to do the same work as a 10-decimal-place hand-held. In fact, it takes roughly 32 bits to approximately represent those 10 decimal digits. 2 ^ 32 = 4 billion. (The 9'th decimal place).
Thus more bits, means you can represent a larger number (just like more positions on your calculator means you can represent the bigger salary of an enron executive). However, if all the numbers you're working with are small, then there's no benifit to having more digits. It just means more work for the poor machine.. PLUS there's a subtle slow-down associated with larger bit-counts.
Now there are several reasons why you'd want larger counts, and the most important is the memory size. 32bits gets us roughly 4 billion, or 4 Gig of memory, or even 4 billion clusters on a hard-disk (e.g. max of 4 billion inodes, etc). Going to 64bits gives us an unimaginably large number, but takes up twice as much over-head. 64bits / 8 bits/ byte = 8 bytes for a single number, as opposed to 4 bytes for a number. So the DOS FAT64 table would take up twice as much space, and so on with other File-Systems. Likewise all pointers and integers in memory would be 8 bytes instead of 4, increasing code size, and wasting precious cach-space.
Note, however, that it's entirely possible to work with larger number than your core can represent. Think of the calculator again.. If you know that the US budget is on the order of 2 trillion dollars, than you can just assume the extra left most digits and do all your work in the < 4 billion region, externally keeping track of all the carry's (just like in elementary math). Likewise it's relatively easy to combine multiple 32 bit registers to act as a 64bit register, though it takes some effort on the programmers part. Plus this isn't as fast as if it were simply a 64bit number to begin with.
Thus computer engineers have not arbitrarily increased bit-size from archetecture to archetecture. The original 8-bit machines worked fine for their embedded controller realms. 90% of all work was 8-bit, and so they could justfiy the expense of manually working out 16, 24 or 32bit arithmetic. Plus for certain important operations, the CPU would automaticaly combine multiple 8 bit registers to form a 16 bit address.
The beloved 8086 from which all PC's have derived used two 16 bit registers combined in an awkward way. Normally you'd think 2 concatenated 16 bit registers would equal 32 bits (and thus allow 4Gig of memory), but what they actually did was overlap most of the bits so that you really only had a 20bit number (which maxes out at 1 million). Thus The original IBM PC's could have up to 1 Meg of memory. The advantage was that you exclusively worked with 16 bit numbers which were REALLY small (2 bytes each) and REALLY fast (hardly any delay since you could optimize much of it's operation). However, the CPU had to perform an ADD for every memory access (since it had to produce the overlayed 20 bit number). Another problem is that while you could access 1 meg of memory, you could only do it 64K at a time. All arrays had to be <= 64k which is a REALLY big problem.
When Intel went 32bit, they kept the same crappy memory scheme of overlaying 16 bit registers atop a pointer-register. The only difference was that the pointers became 32bits. For most purposes this was sufficient, so only a single overlay was used. However, DOS compatibility required using one of the 16bit registers to provide an offset into a DOS memory frame. Theoretically it's possible to achieve higher than 4 gig of system memory on IA-32 machines through the use of these 64 thousand base-registers, maxing out at 48 bits. In fact, the CPU's actually allow something near this address space on their pin-outs, but very few motherboards accomodate this.. PLUS, a single application would have to be written in order to internally segment itself having arrays no bigger than 4 gig each (the exact same problem with 8086 16-bit register overlaying). Plus I'm not aware of OS-support for this capability (though it's theoretically possible). I'm pretty sure Linux doesn't support it at least.
Even though the IA-32's 16bit segment selectors are generally not used (except for 16bit mode DOS support), they're still an impediment, since they involve adding a base to a pointer on every operation. I'm not 100% sure, but I think this mode can be deactivated for performance enhancement, but other aspects of the IA-32 memory model involve such slow-downs.
RISC architecture, on the other hand uses bit-concatenation techniques to avoid having to perform additions for every memory access, and thus can provide clean memory access efficiently, though with no possibility for extension beyond it's physical register size (e.g. <= 4 gig).
An important thing to consider is that programs are designed to operate within it's address space. The larger the address space, the more advanced a solution can be programmed. In the 16-bit constrained world, for example, you'd have to artificially break a problem down into 64/32k chunks. In the 4 gig world, you can't treat arbitrarily large data sets; you have to worry about overflow for things like file generation, compressors.. pkzip can't backup your whole hard drive because it integer overflows after 4 gig, etc. More and more, we're hitting the 4 gig limit, and program designers say that's the user's problem; they don't bother breaking up their application into nice and neat 4 gig chunks because 99% of the time their applications won't hit that boundry.
By going to a 64bit space, developers can once again safely ignore the possibility of their application being used on ever larger data sets. No disk drives currently exist that would require >64 bit address spaces within a backup tool. It opens up a whole new avenue of uses for simpler programs.
-----------
In summation, bit-size does not strictly limit the largest number a CPU can natively achieve, nor does it limit the max memory size. However, it does facilitate efficient access of larger number-spaces. That larger number-space comes at a cost of CPU complexity/cost/ and even performance when 99% of operations don't warrent the extra size.. Still, as more and more common tasks cause us to run into the 4 gig limit, we have a choice.. Either program like we did on the 8086 and other 8/16/20/24 bit archetectures, manually segmenting the data-space into discontiguous chunks, or we move to platforms that natively give us headroom.
Superscalar performance is improved by using the larger registers to execute more instructions in parallel.
You're assuming that the 64bit registers equates to 2 32bit or 4 16bit. These are independent concepts. The PowerPC's Altivec (sp?) and Intel's SSE (and AMD's 3DNow) do what you're talking about, and this was all done with 32bit Integer cores. They simply added new specialized registers, or remapped existing registers.
Let's be clear here, the 64bit refers to the integer core. 64bit floating point registers have been here for virtually forever. Intel even has 80bit, and other RISC platforms tout 128bit floating point, but these provide only precision, NOT performance enhancements. (float v.s. double v.s. long double).
The only thing benifit 64bit provides is faster 64bit arithemetic (long int), which is essential for >4Gig contiguous memory spaces, but also for other types of calculations. The reason I say faster is because 64bit int-arithematic is possible with smaller registers, but only via emulation (though it's not as bad as you'd suspect since there's hardware support such as add-with-carry).
Recently we started using maxq.
It has two modes.. One is a proxy server which you'd set your browser to. It records the post/get arguments you used for the page and records it into a jython file. The backend then uses HTTPUnit to fire off the pages.
It isn't a complete solution.. I had to create a perl filter work with mime-multi-part data, or indeed any form-data that has carriage returns.
But since it's a simple mixture of python and java, it was relatively easy to apply statistics to the processes and search for all sorts of possible error-types.
The problem with simple non-human web crawlers is two fold. First there are pages that require valid form-data. Secondly, a "nightly sanity test" is going to be operating on production data.. You'll need to carefully manage such data.
It still takes more than running Word to expose the contents of your hard drive though.
The article mentions that the reason this is an issue is because the manner in which files would be stolen follow a normal business process among corportate types... Receiving an email from a company member. Editing it (for markup or review), then sending an email to someone else. Secretaries are good candidates for generic attacks, since they'd often need to review documents. But even executives are prone to such unattentative activity.
Forking is the process of producing an effective duplicate of a process at the point of the fork-system call. File-handles, and other system resources are maintained across both processes. In fact, the ONLY difference between them is the Process ID and the Parent Process ID. (Actually, I think system times might also have changed). The return value of the fork-call is either 0 (for child) or the child-process ID (for the parent).
Originally, fork would perform a complete memory copy. But in UNIX, the only way to execute a new program was to fork, then run exec*(..). So they invented vfork which wouldn't actually copy the memory. It's man page said specifically that you MUST run exec as soon as possible after vfork since you were still operating wih SOME shared resources (but it wasn't anywhere close to being considered a separate thread).
Now, virtually every UNIX platform has deprecated the vfork call. fork now sets a flag on all the VM page's meta-data called copy-on-write. In the real hardware VM pages, it generally just sets all owned pages to read-only. This causes a hardware exception whenever a write occurs. The OS then checks the OS-meta data for the associated page. If the copy-on-write flag is set then instead of throwin a core-dump, it produces an exact duplicate of the 4k (or what-ever) chunk of memory, then it resets writability of at least one of the pages (if there were only one forked process, then it sets writability to both the old and new VM pages, otherwise, it decrements the copy-on-write count for that page.
The net result is that when you fork in a modern UNIX system, it's pretty fast (aside from all the increments on the copy-on-write; e.g. if a process has 1Gig of memory, forking is a little expensive). In Apache 1.3, having a master process forking worker processes means that if a newly forked worker just dishes out a static page, then only a dozen or so VM pages will ever need to be written to, and thus 99% of all the memory will be shared with the parent.. Shared for caching, and shared for less system-over-head. Unfortunately if you're using mod_perl / mod_php, then you'll most likely hit lots of random portions of memory thereby triggering lots of hardware exceptions and VM-copies. Thus the longer a 1.3 process runs, the more memory it takes up (especially considering their memory heap-management). That's one reason why we have the kill-child-worker-after-X-requests option in Apache.
I'm not sure how mod_jk works. I don't know if it performs a sub-thread off each apache process, or if it works like tomcat4 with it's co-processing (like fast-CGI). I can't imagine that it would work well as a thread-per-Apache-Worker, because it modifies virtually every byte of it's memory space periodically.
In Linux, the only difference between threads and processes is that during the initial VM-reflagging, the copy-on-write isn't set; in fact that stage is completely skipped. Thus we save a tiny bit of performance on the initial call, and we are completely free to modify data without a tiny interruption.
Incidently, hardware exceptions are REALLY bad when done regularly because modern CPU's (Intel especially) have deep speculative pipelines and slow memory latencies. Thus an exception half-way up the pipe has to throw almost everything away. Then if/when the instruction is restarted (after cleaning up after the copy-on-write), it has to start back at the first stage (and all memory must be reloaded). While this is only a small fraction of general execution under forking.. Heavy amounts of forking can bring a system to it's knees (wasting some 90% of all CPU on the forking VM-copying process). I've seen this first hand with Apache and CGI or with a custom version of FastCGI where simply running Apache Benchmark (ab) made the system unuseble for 10 minutes (doing nothing but forking, and queing forks).
So in response to your question, the child is not "part" of the mother except that some resources are temporarily shared until they're modified. Because of the read-only nature, they are completely thread-safe (except for externally shared resources like IPC's and file-handles). Incidently, Apache makes great use of shared file-handles. The master process opens the port 80 socket, and it's workers get references to it (via the fork). Everybody except the master process then "accepts" on the http port(s). The OS then round-robin hands off new connection requests to the workers in turn. This was just a freebe of the UNIX model. In fact, the only "magic" that Apache has to use is an IPC shared memory segment (or shared file handle) in order to have the master process reap exceess child-workers.
Well, I think the key concern is that perl6 is being completely re-imagined. Instead of being a data-structure navigator, it's a byte-code interpretor. More importantly, the byte-codes are elementary operations instead of macro-operations which would otherwise be optimized. This is an example of a niche change.. Instead of doing it as efficiently or as cleanly as possible, they're going to be competing directly with python / java / C# byte-code-interpretors. And they'll fail for java because of binding differences inherent efficiencies.
I've seen the perl5 internals, and yes it can be messy. I _can_ see the desire to move away from macro's to functions; especially since a good compiler should be able to optimize this away. But perl6 is going to have several layers of indirection.
Further, I can understand the desire to move from ref-counted memory management to a copying-collector; it prevents having to free-the-mallocs. But you could have a hybrid ref-count-when-you-want, mark-sweep-when-you're-lazy. Perl's ref-counting manages strings much better than java's garbage collector; mostly because temporary allocations are immediately reclaimed in perl5, where-as they're just as wasteful as intermediately-lived object allocations in java.
On the one hand, Larry has decided to do a rewrite and avoid all the pitfalls associated with perl5.. But I'm not convinced that this total rewrite isn't going to have even more problems than when it began.. More importantly, it'll be in the same class as every other VM out there and thus not be able to distinguish itself.. And thus lose it's niche.
I'm more satisfied with the idea of a perl6 -> java-byte-code compiler similar to jython, since then you get to have the best of both worlds. A widely supported VM with all the huffman encoding of a perl language.
Still, I support the perl6 move; trying to help it be as good as it can given it's new inherent limitations.
perl 1-5 have been great UNIX configuration/management languages. This includes small-scale webserver platforms. It's very difficult to find any other language that is as versitile in this respect where it reigns in it's niche. It is the perfect combination of speed, power, simplicity and huffman encoding (especially given the co-UNIX-tools look-and-feel).
Perl 6 on the other hand, changes this formula around; favoring a more general solution that potentially reduces performance (due to abstractions), and deviates substantially from the UNIX-family-syntax - Namely: c-ish-syntax ( colon, question mark, select, exception-handling, etc), awk/sedish reg-ex's, raw c-libray-wrappers, etc. It was these very similarities that made learning and accepting perl so trivial since learning CIS and UNIX administration was sufficient to master perl in 2 days.
My question is: does perl 6 have a niche in mind? Or is it spreading itself too thinly; competing more and more against Java/python/C# and thus losing it's identifiable niche?
The HBO series (if you can get it) costs the prices of 3 rentels a month, and you get a selection of much more than that. Plus I've personally loved their programming of Spawn, Sex & the City, Sapranos (haven't seen yet, but it's critically(sp?) aclaimed), 6 feet under, and various other network-like specials that I do tend to enjoy (even though they have an obvious lower-budget feel).
The best part is that only one person in a group of friends really needs to get it (I only ever personally got it once several years ago during a promotion).
Through the use of digital VCR's (mostly computers) and broad-band, it's entirely possible to share among your friends entire libraries.
Further, the digital versions can come with component-video and Digital Dolby surround; something the networks are no where near ready for (the movies they play are generally too old to have the cinematic experience; especially coupled with commercials; who cares about The Tonight Show in HDTV).
Personally I hate sports, but that's available too.
"Flimsy"? I've been a professional Java developer for six years. I have written server software (running to Solaris and Linux) and client software (Swing applications running on Windows, Macintosh, and Linux)....
Number of Java crashes I have seen in the past few years: Zero.
Swing was horrendously buggy initially. In fact, we found many a case where the old java 1.1 cored on solaris (with and without swing; though swing had a much greater propensity to crash or hang). None of the companies I've worked with has dared use swing in production code, so I don't know how good it is these days.
As for robustness, I'd like to point out that core dumping isn't the only metric. Java uses more memory than any other language I've seen used at the enterprise level. (I'm sure there are worse, but I've not enountered them). Using any sort of swap with java is insane, because of it's garbage collection model (In my opinion, a mixed blessing at best). I've actually written several garbage collectors and memory managers, and my opionion is that any such mark/sweet or collector is not suitable for arbitrarily large enterprise apps. Once you can get your app into a state where it's out of main memory, you're thrashing to the hard drive on every gc. Heaven forbid your app actually requires more memory than you have physical by itself. It's bad enough when you have two competing java apps fighting for memory.
Personally, I prefer ref-counting, which adds run-time performance overhead, but avoids the swap-thrashing issue for heavy-loads. I know that java is capable of utilizing any garbage collection scheme it chooses, but the defaults are never ref-counting; even on such hungry apps.
The main reason I dislike non-ref-counted garbage collection is that a simple loop which allocates and throws away strings produces hundreds of thousands of memory allocations under many systems (such as in many jdbc drivers). These simple small and allocations would be trivial to maintain under ref-counting.
Sorry for ranting, but I just so happen to be plagued with these issues (a servlet engine idling at 298Meg even with different VM's and settings).
Further on the stability issue. Not allowing static linking, and allowing new versions of classes to sneak in and thereby cause crashes is a common occurance with that java-model.
Java is obviously only as stable as your computer,
So is visual basic, but I think make such a statement about VB is misleading, since even syntax errors can lay dormant in VB waiting for just the right section of code to be accessed; crashing your app. I definately believe java to be a robust "syntactic language", but the underlying platform is still very sensative to design and maintanance mishaps.
There is a large amount of indeterminism associated with Java.. When will it garbage collect, when will file handles be closed, how much memory is it going to need, etc. These things make it harder to design robust enterprise systems (though not impossible). These are the sorts of gotcha's that reduce Java' stability in my opinion. Yes you can design bad c-code, but it's almost impossible to attain determinism with java in some areas.
As far as "imagine running an entire OS with a single such point of failure", that is perhaps the most ridiculous thing I've ever heard. Are you suggesting the Linux kernel is not a single point of failure?
There is a javaOS, by the way. A hardware product an old company of mine created used it. And I'm not suggesting that linux isn't a single point of failure.. I AM suggesting that the platform the linux kernel was developed on is more inherently stable than java. The key word was "such", which meant my so called "flimsy" java being the weakest link and also being a single point of failure for everything. Thus the most stable you can get a javaOS pales in comparison to the most you can get with c. Granted, an initial build of a javaOS is probably going to be more stable than that of c due to java's inherent type-safety.
Java is getting better; yes. And VM writers are free to develop better memory managers. But it's still bleeding edge in my opinion. I wouldn't consider java as having 4 nines availability; especially if the latest features in each release are being utilized. What's worse, the fact that most old features keep getting deprecated, it's nearly impossible to maintain a properly robust API (e.g. to say, yes, java.io is finally robust since it's had 2 major versions behind it).
In the Summary part, there were these additional comments:
eliminating checked exceptions (as Bruce Eckel has advocated),
Don't know enough to understand what this means. Is he wanting to get rid of catch clauses?
limiting objects to a single thread as in Eiffel
My initial impression is that this is very good. I know that I was really worried when I first found that java only has single inheritance, but I've usually found work-arounds, and this definately seems a clean design.. Thus it shouldn't be too much of a stretch to accept this thread-isolation. I don't fully understand how it would work (do cross object method invocations require a transfer of run-time control? That seems terribly inefficient).
I know that perl5.8 / 6 is using a novel method of thread control. The app is multi-threaded, BUT, each thread runs a fully independent VM. Variables must be explicitly shared. It just seems very clean.
BTW, on Linux, there is no real difference between a process and a thread, so Sun's JVM is already "multi-process" on Linux.
You confuse me, because you obviously must understand the difference between threaded and multi-processed, yet you claim that there's no difference in Linux. There are numerous functional differences between the two. First and foremost, you have 100% isolation (sand-boxing). You're not concerned with race-conditions (well, you have to go out of your way to produce them at least), you have to explicitly share material (e.g. pipes or magical fork-aware objects), you're crash-proof (apache has a master process image; if one worker "thread" dies for almost any reason (baring OS problems), it VERY quickly forks a new worker which is 100% ready to go), and finally, MP has better caching issues with multiple CPUs (e.g. no shared and slow writable cache). To boot, while MT saves more total memory, MP more efficiently distributes it to workers. Non modified memory is freely shared in a safe manner (marked as read-only by the OS, and thereby efficiently cached by each CPU), and only modified memory gets moved. Granted, in JVM's garbage collector, the entire heap is constantly remodified.
As other's have said, I support the general idea of Apple method of sharing memory space between JVM's; though I don't know it's particulars. Most notably, the shared memory should be read-only (to avoid interdependency crashes). Next, it should only be shared per user (or at least copy-on-write), to disallow viral infections.
My concern is obviously for that of robustness. Java is already flimsy as it is in this respect (imagine running an entire OS with a single such point of failure).
Maybe I misinterpreted the original post, but I thought that this had more to do 64-bit vs. 32- bit (and the limitations of a 32-bit platform) than it has to do with AMD vs. Intel.
While we're extrapolating a lot from so little information, I happened to get the opposite impression. 32 -> 64 isn't that big of a deal for Linux since it's already readily available. The big issue is the uniform adoption of AMD's x86-64 or a rift in the x86 32/64 migration path. It would be horrible for the industry in general (not just Linux), if the application base was split between two high-volume 64bit implementations. I would love to see an x86-64 binary rpm work on both intel and AMD; thereby minimizing how maintanance issues.
Personally, I love the x86-64 memory architecture; it's more RISC-like, and begins to chuck away the old 16-bit mode legacy mutations. I get the feeling that Linus was excited by the new kernel-specific features in the archetecture, and thus would probably like to see that become the main-stream linux driver-set. Pure extrapolation here though.
My 10b
Two things. First, the newer perl camel book contains just about everything you need to know, so you could just reread the appropriate sections of interest there.
Secondly, and more importantly, the way I've managed migration is to simply reread the man-pages. If you've ever read the perl man pages, they're rather nice. Most importantly, you'll recognize a lot of material from previous reads. Thus for each new version, I simply skim certain man pages (like man perlre).
Next, I've noticed in the past couple releases, there's a man perl5005delta, and now perl56delta and perl561delta.
In terms of man pages for reg ex's, each feature stands out, and you'll quickly come to learn the (xx..) commands. There are definately a couple that stand out in terms of usefulness: (?=..), ?!, ?<=, ?<!, and possibly ?>. These involve look head and behind assertions (and their negatives). The last one is a non-backtracking forward expression.. Great for avoiding nearly infinite backuptracking issues.
And, in case you don't find a good collection of info. I'll throw this change.. "our" is now the global equivalent of "my". It replaces "use vars qw($x $y $z);". I say this because I wan't as much perl code to do this as possible.
...cooling will raise the "speed" of the chip, which in turn will add heat, which will counteract the cooling you do.
But it can't make it worse than it was. Yes there is a paracitic resistance to increases in performance, but that's like the graduated tax-scale.. You can't lose money by making more, you only get taxed at a greater percentage for each additional dollar (not the preceeding dollars).
We used clearcase extensively at an old company of mine, and it was great for internal projects. I definately don't think it has any place for open-source, however. Mounting file systems over the internet is definately out.
As someone pointed out, many of the types of issues questioned in this tread are configuration management issues, not version control issues. Case in point, as powerful as clearcase was, we developed a MASSIVE set of wrapper scripts to automate many regular and complex tasks. These scripts would have been portable to many styles of version control (though probably not CVS).
The main thing I didn't like about clearcase was it's dependence on the central server. I personally hate operating off mounted file systems. They're great for sharing info, but I've flat out refused to make my home directory nfs'd for a good reason.. It's slow and unreliable. There's always a point where something goes wrong or some administration is going on behind the scenes, and your desktop freezes. Likewise compilations are many times slower due to massive accesses to medium to small sized files.
It is great for administrators though.. Backups are a sinch (since distributed data is all really stored centrally). It's also somewhat scalable since you can have separate servers perform different functions.
It is expensive, however; both in licensing and hardware.
My 10b cents.
-Michael
Only problem with perforce is it doesn't support distributed offline work.
You have to connect to the central database for EVERYTHING. All files are locked until you manually checkout a file. If you have a slow network connection or disconnect periodically, you have to reconnect every time you want to make a change (add a file, edit a file, change attributes on a file, see what files have changed, etc).
For open source development this can be a major problem.
Further, a centralized database can be problematic for separate development trees (not branches). The best you can do is copy the database to a new machine and run from there.
One feature I like of "arch" is that you can have decentralized development with independent trees/databases, and merge them back into the main database at a later date. There are several frustrations/limitations with arch so I'm not recommending it, just showing that someone else has solved this problem.
In general, I like CVS's (and arch's) view-private meta-data which allows a subset of operations to be performed. Not least of which is which files have been changed,and the ability to modify files without central authority. Other than that, I like just about all the features of perforce.
Yes and no. Many philosophers spent their lives trying to prove existence through the use of the proof of dieties. Descartes merely managed to prove a questioning being exists as that which questions, and kant rationalized that a fact (a more useful component of existence, or truth) is something that can be traced to a time and a place. They both heavily delved into theological proofs, but I've been utterly unimpressed by those approaches. My point is merely that the two questions are usually intertwined.
I disagree. And further return the finger of misleading back towards you. It's possible to phrase a question such that an obvious (but incorrect) answer manifests itself.
Newton quantified gravity, and you say he was incapable of saying why gravity is or works. But another point of view is to say that he created gravity to say "why" things fall. "why" do planets orbit the sun (or the moon the earth). "why" are there tides? Why is there the phrase "all things that go up, must come down". Further, the science of force tells us "why" a bird can fly, and more importantly, an understanding of this question allows us to formulate theories on how we too can fly.
Science is filled with questions and answers for why. Relativity, quantum physics, string theory, and ethereal-theory all attempt to answer questions left after Newton. That is the beauty of science, we're never left with a lacking of questions of why. Most importantly, it constantly finds answers to many of them; Just maybe not the ones we're interested in at the moment. Many of the answers are to questions we didn't even know we needed to ask (such as with nuclear science).
As for the "why's" of existance. It may be a useless question; much like asking, what is the significance of a roll of 3 comming immidiately after a roll of 2. Perhaps in some particular context the question is important, but outside that context it's patently useless. We ask why do we exist for several reasons (actually, I personally don't ask the question because I don't fall into that context; I don't have a need to know that why. Life seems to make sence without it); We ask it because we feel empty and need some purpose / challenge / destination. This mentality easily manifests itself in a society based on conquest / advancement / rewards and punishment. But this is much like looking at some distance, noticing that it's finite, then assuming that if a finite length can exist, it's opposite, an infinite, must also exist. Thus we can speculate that distance can be infinitely long (though much scientific logic and evidence contradicts this for our universe; e.g. the logical thought that the universe can not be both infinitely old and infinitely large which requires a white sky instead of a black one.). Likewise, we can see the pattern that short durations of life can be made more meaningful through accomplishment and the over-comming of hardship and thus attempt to apply it to the entirety of not only one's life, but all existance. There is, likewise, no evidence that this is the case, and further, the rampant proliferation of rewarded evil-doers and abused altruists poses tremendous evidence contrary to such a mechanism. e.g. people that don't work hard get rewarded, people that never endure hard-ships have triumphs, those that strive for what is right are made to look bad, stolen from, started over, die young, etc.
Note that this doesn't disprove why-filled existance, but merely says that those that have faith in a particular "why" have no empirical evidence, and are thus imagining things (even if their imagry turns out to be true in the end).
What's more, the point of science for eyons (e.g. zillions of moments.
The "whys" of today are no more determined by theology than by science. Theology can say when it's all right to have an abortion, e.g. some theological figure can make some analogy / parable / declaration which provides difinitive direction for their flock. Likewise science can say when there is a self sustaining level of biological activity within the fetus or pre sex-cells. Both approaches are heavily subject to interpretation, but do offer mechanisms for truths. And as with our discussion here, provide some satisfaction that we understand "why" something is right or wrong. i.e. I might understand that a sex-cell is not a whole person, and thus morally accept any abuse of sex cells, so long as they're not mated. Thus would argue that all abortion is illegal. Though religious conservatives tend to make this claim, they use science - NOT theological dogma - to make this claim. And of course, this is a dangerous game, because I can say that the half cell has all the required elements to "live" as a skin cell or a neuron or a heart cell; It can process food into energy and atuate that energy in a self-promoting fashion. It can regenerate it's cell walls, etc. etc. Thus I personally would argue that all life is equally valuable, no matter it's insignificance; from a sexless ameoba to a multi-cellular televangelist. Most importantly, this implies that plants are just as alive and valuable as animals, so I'd argue that vegans are completely deluded (as opposed to vegetarians, who may simply prefer the more delecate diet). The counter-balance to this is that my use of science says that ther is no hardened line for such a moral question. The "why" is this law valid blurs away, just as "why" does gravity work fades. My answer to both is that we're not spoiled little humans that have all the answers presented on a silver plate. We're going to have to work hard (individually or as a group) to resolve these unanswered questions. What is the appropriate threshold between killing and murder? What is the extent that we can discern and utilize cosmology?
Why do we live? Personally, I say this is another useless question. I say that to "live" is scientifically ambiguious and thus a misnomer. More properly, if categorized with consistent labels such as compatible with organic molecular structure, or at a higher level, obtaining self-consciousness, we can easily answer many moral questions. Unfortunately, science must constantly revise it's categorizations.. From "what goes up must come down", to "force fields, which include gravity", to "relativity, which handles high velocities or massive bodies", to quntum physics which redefines small spaces to string theory, which redefines the number of dimensions in which we live. When dealing with science, we simply have to "live in the moment" and trust our current understandings. With religion, we have to "let go of our self" and give in to another's interpretation of divinity. Similarly with faith (which is more general than organized religion), we have to place values on experiences that often frustrate our desired courses in life (e.g. historical "profits" and "saints" had experiences that made them believe not only in an almighty, but in the almighty's plan which required timultuous life styles from them, such that others would follow and benifit).
-Michael
I'm inclined to agree with you.
m y-house.
There are several dynamic forces at work here, and whenever you have dynamics, you don't have absolutism.
Negative forces:
Economic free rider problem: Person one pays for a good/service, and person 2..n benifits for free. The problem is that if a firm knows that only 1 person will purchase, then they either have to fully charge, or not produce.
Lack of control:
When you control a comodity, you have a monopoly and can have secondary incomes ($4 drinks at the movies, for example). It's not garunteed profit, but it always helps. Presumably if secondary income is great enough, you can even reduce the price of the main good (i.e. MS Windows, amusement park entrance fees, etc) to maximize revenue. The music industry has numerous secondary revenue's. Most importantly, control over what is a best seller. Radio-brainwashing and store-marketing are key to make a pre-determined best seller. Search-based music downloading removes promotional viability. The general effect of brain-washing is to produce die-hard fans. I suspect that research would show that a hardened fan will spend more dollars than a casual fan (I know many such people). Thus it pays to have a fully polarized population; no matter what particular artist they're obsessed with.
Open Market:
The more competitors, the lower the viable price. If new *good* artists choose not to sign with record companies (because of the generation alternative distributions), then there will be popular media titles outside the revenue streams of existing big media. Since there's a limit to the total capable media-expendatures (namely everybody's income scaled by some reasonable amount), this necessarily reduces the amount of existing media giant purchases.
Positive forces:
Better competition:
With the open-market item, more competition usually leads to more variety and better quality (though quality can go down when companies compete on price alone; but this doesn't seem to be the case in entertainment fields; there are enough consumers that are willing to pay premiums for entertainment).
Cheaper:
More efficient distributions means lower costs. (Don't have to print CDs, artists don't necessarily have to spend marketing dollars)
Less purchasing risk:
A negative effect of media marketing tactics is that you often purchase CDs which have minimal enjoyment (just as much as you knew it had to have, but not an ounce more; i.e. only liking a single song on a CD, sometimes less). A common tactic is bundling uninteresting goods with a single high-ticket item, and raising the price accordingly. MS learned this tactic well. With an search-based system, only the interesting media ever need be acquired. Thus the consumer would be less averse towards a given purchase (even if music is acquired for free, there is the economic cost of wasted bandwidth or time spent listening to bad music). Even if the consumer ultimately didn't like the media, they must have had some interest in acquiring it (word-of-mouth, flashy titles, etc).
Greater economic welfare:
Along with the above reduction in purchasing risk is the increase in the number of consumers that purchase what they want, which counts as increased utility. High economic welfare can be interpreted has having a greater level of total happiness.
Luxury utility:
Rational people maximize their time and minimize their frustration. This means that people are willing to make tradeoffs, such as exchanging money for services or goods that make their mundane work go faster, or go-away (such as hiring an accountant). Obviously, the more wealthy a person is, the more likely they'll spend money on simpler and simpler things (like parking a car). The same applies to the media industry. Some people will pay to not have to deal with burning a CD, or finding music, then downloading it. Beyond a certain point of wealth the time spent doing these things takes away from time working (e.g. physical loss of money) or in relaxing (time spent away from work). Thus there is a definite demand for the service of collecting media and making it readily available (such as a theater, the radio, or venues such as music stores (even online ones)).
Conscious:
Many people will obide by their conscious; feeling a desire to do good and support good things (such as artists that they like). It's the same as droping money into the hat of a street-musician. They too are plagued with the free-rider problem, but find some semblence of an income. In some european countries, you even have to audition to be allowed to perform in the subways (since it had a definite market). When you download trial-ware software, you're encouraged (on the honor system) to pay the author if you like it. A rational person will contribute since they know it'll encourage more such software which focuses on pleasing the consumer. The other aspect of consciousness is that when we go out of our way to circumvent a form of security, we know that's we're idealistically hurting someone else (if I sneak into someone's house, I'm hurting their sence of autonomy, whether they catch me or not). To continue with the act we either justify it (they make too much money anyway), live in shame or blow it off (usually a person that can casually blow things off tends to do so in all aspects of their life; psychologically being hardened). In general, the more good-willed a society is, the less hardened the people will be, and the less likely they'll have reasons to justify their free-rider position, equating to more good-will payments.
Media Quality:
Lets face it, currently MP3 isn't viable on hi-fi. It's possible to make this the case, but it's generally inaccessible to the majority of the population. How many people know how to hook up their computer to their stereo. How many people know how to turn downloaded MP3's into PCM files capable of saving onto a traditional audio-CD (playable on the hi-fi)? If a person doesn't care about the quality of highly compressed audio, and they have sufficiently high quality computer audio equipment, then this isn't an issue. But there are those (myself included) who are frustrated by _any_ popping or lack of quality due to audio-compression (or lack of full surround capability). Bandwidth is still too constrainted to acquire decent quality (DSL/cable only uploads at 15KBps), to say nothing of video quality. While this is only a temporariy issue (assuming we ever get to home gigabit down/upload streams), it still causes people like me to seek out legitimate DTS CDs, DVD-Audio, nearly-original-quality DVDs (meaning that even DVD does compress the video in sometimes noticable ways). Thus while I always try to make mp3 copies of my purchased CD's, I still make use of my originals in a CD-juke-box. Sure it lacks the flexibility of my mp3 jukebox, but this does not mean I don't have additional utility. Further, most people don't purchase RCA output jack-capable sound-cards (usually the Sound Blaster Gold series), so 1/8 connectors definately lose something over my fiber-optic CD-player-to-reciever with 14 gauge monster-wire-to-speakers-which-spread-throughout-
Tangibility:
There is a bizzar human essence (or psychosis if you like) that desires tangibility. People tend to not feel content unless they can regress to their childhood and physically feel some otherwise abstract concept. To hold a CD, to know that even if my computer crashes, I still have my "originals". To "own a house", or "own a CD collection", are irrational, yet undeniable urges. There are many subtle undertoning advantages to such tangibility, but our higher level mind simply attributes the "good" flag to it. Thus, even though we might download a Nine Inch Nails song, we might purchase the CD and the DVD-video just to "have it". I believe that this is probably the single biggest contributor to the napster golden age for the media giants.
Summary:
Negative. The only negative that affects society as a whole is the free-rider problem which ultimately says "don't produce".
Positive. There are natural financial markets in the media industry that counter-act the free-rider problem; namely good-will and quality-persistence (hi-fidelity), with the subtle tangibility aspect looming in the distance.