You lost yours the moment you began arguing both sides of the same argument. One for Opteron (set up for SMP, which incedently means set up for context switching and context sharing) and another for G5 (implication that P4's context switching is not slow compared to G5, which is also very optimized for SMP).
Among other things. Like, "I don't own a P4, but I'm bragging about the one I'm using right now."
Sorry, I just don't have the time to play games with people like you. I'll condecend when it sounds like you deserve it. And you, my poor comrade, seem to yearn for it.
I won't claim to understand why so many people on slashdot are so eager to make arguments so patently false. For a moment I thought you were actually saying something and began to respond.
A great deal of experience. I've be using OS X off and on since the public beta, on a large selection of machines all the way up to (recently and briefly) a 1.6Ghz G5. OS X's GUI remained unresponsive and chunky on all of them.
Okay, at first I thought you were just trolling, because my experiences with the G5 have been liquid smooth. Maybe we're using different meaningw or responsive sand smooth? On my dual 800 and even on my iBook there an be some frame loss when dragging very large windows or doing that minimize effect, but it's only when the machine seems especially occupied, and doesn't affect the rate at which things move.
Maybe you're referring to the mouse-interaction delay bug that very few mice display on some machines? Some mice and some machines apple makes have an odd interaction where your click occurs a few ms after you press the mouse. It can be quite disturbing until you realize it and switch mice.
Maybe you're talking about window resizing? I wouldn't blame the machine. I'd blame the app writers, but even above and beyond that, OSX is pretty much the only game in town doing live resizing, so it's hardly a fair comparison. Of course, you don't seem like one for fair comparisons.
Intel probably disagrees. They've demo'd P4s at over 4Ghz. Heck, crazy overclockers have managed to get currently shipping machines over 4Ghz.
With liquid cooling, in every example I've seen. Sorry, that just isn't going to work for the masses. It also tends to dramatically increase the cost of pre-built machines. Most people, like intel's sales department, don't consider this a "success".
The PC Mag article indicates the Xeon machine is faster at 10 out of 12 Photoshop tasks, and faster overall on the Photoshop benchmark by a bit under 30%.
Umm.. no. Looking at the results and then quoting the article:
At these larger image sizes, although the Wintel test times were quite good, both the G4 and G5 computers proved more adept at distort functions like wave and pinch. Moreover, on the Windows system, loading the controls often took a minute or more. If these times are added back to the actual test times, both Macintosh computers would have clearly outperformed the Windows-based computer.
In other words, they snipped off some time! The G5 had to load the controls to finish the operation and return to normal status. The P4 didn't. Probably, they snipped off some time because it's PC mag, I am not very surprised or very upset. At least they mentioned it in the article.
Let's ignore that for a second or two. I'll say again: there is NO OPTIMIZED OS OR OPTIMIZING COMPILER FOR OSX. So the fact that in general the G5 comes up mighty close to being even after the time-snipping, means it's much faster.
Now, I can't profess to know the software you're using, the size of your inbox or the web pages you browse, but they must be pretty damn impressive if you consider web browsing and email checking to be "processor and memory intensive tasks".
Hmm. I use IMAP. I get a pretty low amount of personal mail and I'm subscribed to Ruby-Talk, which I keep a 1 month archive on. This means I have about 7k-10k messages at any given point.
Indexing those for content is not a trivial task.
Right now I have about 50 tabs open spread over 4 Firebird windows, 5 IE windows, Outlook checking 6 email accounts every 2 minutes, a VMWare machine idling away in the background, MP3s playing, 6 Word documents open, 4 IM windows, 15 terminal windows and about 30G of data being...
Bullshit. But go on.
This machine is a 1.8Ghz Pentium 4. It's somewhat restricted by only 512MB of RAM, but nevertheless I never feel the need for a faster CPU while using it. More memory ? Yes. Faster hard disks ? Yes. Faster C
Given OS X's poor GUI responsiveness, an attempt to recreate a "realistic" multitasking benchmark is going to make it look worse, not better.
Yeah, um, it's plenty responsive on my iBook 800. I do not know where you're drawing this from. Are you complaining that OSX doesn't have a smooth scroll feature like Windows does? They do in Panther, but honestly I don't like them. It's a lot harder to tell how far you're scrolling when there is an animation delay imposed.
The P4 completes a single task faster because it's a faster CPU.
I'm sorry, you can't get away with that here. The P4 has a much, much higher clock rate. It means that yes, for doing one thing, especially one more-or-less simple thing, you probably will win in a footrace. Duh.
It doesn't mean that your machine will do better at multiple parallel tasks. The P4 is just slower at it. Also, its architecture won't do contest switches as quickly between threads. Part of the reason Intel is adding the on-die memory controller and more cache is to try and hide this fact. Intel's hit the limit with the P4, more or less. Maybe they can get a bit more clockspeed, but they're topping out with what's reasonable in an aircooled machine.
The G5s are keeping up with an unoptimized OS, a lack of optimizing compiler, at a clockspeed much lower than the architecture's maximum.
You also need to define "real world". No-one is going to argue that multi-CPU machines, or machines with big CPU caches, or machines with wide, fast buses scale better with multiple CPU-heavy jobs than a single CPU machine. In the "Real world" bit of the market P4s are aimed at, this scenario is neither common nor representative.
Why not ask GamePC to define it. They're the one I'm angry about. You have a funny idea of "real world" must be. Everyday web browsing and use? Everyone I know tends to check their email and browse the web while their email loads. Now, those are both processor and memory intensive tasks. Your mail program index, spam filters, and places your mail in a data hierarchy. Meanwhile your web browser is rendering relatively complex operations. Usually it's doing them in parallel. Scrolling is also relatively expensive.
This is an everyday case that the P4 copes with poorly. The ameliorating effect of the larger cache and memory controller only carries you so far.
A typical game is a nightmare for a single P4 machinel Multiple threads all doing different memory and I/O intensive things, with your video card you can't always use DMA! Sometimes the P4 has to send stuff manually. The P4 can only keep up with modern games by virtue of its high clock speed. As the Opteron and G5 catch up, the performance barrier will only become more and more apparent.
As it stands now, I still feel that a 1.8ghz G5 or Opteron will "blow the doors off" a P4. I've gotten the chance to use said G5 and my friend's P4 is roughly of the spec we're talking about. By the way, did you notice that the G5s aren't set up to use their altivec, while the P4s are going to use SSE? Yet another handicap. The altivec doesn't just help with floating point you know. It does integer ops just as fast, on a variety of sizes. Auto-vectorization in a compiler would turn ordinary code into screamingly fast code. With no OS optimized for it and no optimizing compiler.
The G5 is blindfolded, has one hand tied behind its back and the other opponent has a spear. And it still wins.
Everyone who's tried it agrees, it's impossible to get the G5 to slow down. Three apps open up as fast as one does (unless they have to do network stuff to boot, then the network latency comes in of course). My friend's P4 with lots of the best DDR ram he can slot still stutters on the Start menu, let alone starting several apps at once.
And no, he doesn't suck at building machines. He's actually quite good at it, I assure you.
"Are you also noting that a 3Ghz P4 is quite a bit faster than both of them (and a *lot* cheaper) ?:)"
Umm.. you know why these benchmarks that everyone does are stupid? Because the test the machine doing one task at once. Sure, the task has multiple parts, and may include more than just the processor, but all too often we see these little head-in-the-sand benchmarks that make the 3Ghz P4 look so good.
It's not. Want a real test? Run two of these benchmark tests simultaneously. Run 3. The p4 has a vastly higher clock speed. Unsurprisingly, when you focus it on one small task, it completes it quite fast, even though it's doing so less efficiently.
The Opteron and PPC970 do more things efficiently. As you might guess, this is the "real world" scenario, where our machines do many, many things at once. Your machine is performing dozens of distinct tasks, right now. Many Opteron reviews are claiming the chip doesn't benchmark well under the current idea of what benchmarking should be, but in real world tests they easily outperform the P4s. No one questions them. The G5 and the Xeons are the same way. When you try and take account of the innumerable factors that make a computer fast and condense them down to a small set of "average values" you're going to get a distorted picture, favoring people who play the benchmark game.
Ironically enough, the Xeons and the G5 still royally stomped on everyone else. I find this very satisfying. I like seeing those silly P4 chips lose at their own marketing game.
These benchmarks are stupid, small, outdated, and almost seemed designed from the ground up to favor machines with high clockspeed.
"98% of what we do as software developers can be done with equal speed on a dual-processor G5, a G4-based iMac, or a G3-based iBook."
Speak for yourself. I have done software development on my Dual G4, my 800mhz iBook, and my friends shiny new G5 for an afternoon. IDEs are ever-increasing in complexity and responsibility. Apple's new XCode and VC++ have for a long time done many, many things that require quite a lot of lookups, analysis, and parse tree building.
Sorry, these things create stutters, slowdowns, and obnoxious hangups when I develop. I've used VC++, Eclipse, ProjectBuilder and XCode. All benefit hugely from faster machines. I wince at coding using a real IDE like Eclipse or Xcode on my iBook, which has a max ram loadout. It's not a huge deal on my G4, and I'll wager a G5 eats it alive and asks for seconds.
On the G5, everything was happening instantly. It was kinda eerie. I built the newest Ruby on it for my friend, using xlc (the better cache management actually speeds ruby up appreciably, like 10% in some operations!).
It took about 25-40 seconds ( I wasn't timing, so I'll keep the range broad). That's compared to about 3:25 on my dual G4. Admittedly, I'm not using xlc here, but it gives you something to think about.
Fast compilers are very important to people who rely on their compilers to find errors, the build-fix-build-fix cycle is standard procedure anywhere you go, and faster compiling computers make you wait less time for that.
Well, SCO can easily, trivially, and even somewhat believably claim Scenario One (which they will). Remeber, they're already twisting what everyone says, and outright lying.
In order for any tool to really debunk stuff and be usefull, it has to be extremely comprehensive, thourough, and correct. Otherwise, it's only so much chaff that doesn't help much.
What we need are comparisons so thourough that no one can deny them and look sane.
Not if there is even one different line. Add a comment, say. Or anything. Just one character will ruin that slice. Just one line will completely remove any chance of finding it.
It's still a useful tool. Just not for the SCO case, or any case where the honestly of the authors is in question.
Would it? What if it's been reformatted into the GNU coding style? Spacing matters.
Let's say it was copied more or less verbatim, but the number of lines is slightly different by a comment (which should be ignored). Unless these situations are corrected for, the windows could be misaligned. Suddenly identical regious that are shifted slightly would appear different, and the docs say that it throws out differences.
Even if this tool works much more intelligently than is explained, it wouldn't matter to the SCO case. They'll just claim it's obfuscated, and even the most miniscule of changes would ruin this tools' ability to give accurate results, even with a window of 1.
Having helped work on my University's source code analysis tool that they use to prevent cheating, I can say this kind of approach would even have problems keeping honest people honest, let alone catching dishonest people.
Yeah. See my other post in this thread, where I ask just that. I don't think that this tool is meant for comparing source trees. ESR is smarter than that.
Well, I was looking at ESR's description of the code (I haven't read the code yet), and it seems to say that he takes 3 line slices, MD5s them, then compares them for identical points. I'm sure he compensates for funky whitespace and whatnot like diff and patch do...
But if even one bit of the source is different, the MD5 hash will be quite different. So, the code slices have to be IDENTICAL. This is not a very good system because a simple find-replace could defeat it. A variable's name changed by one letter, or even capitalization, will defeat it.
Unless the code reveals much more complex tricks than ESR describes in the help file, this tool wouldn't be much use in the SCO case. Hell, it wouldn't be much use catching college class cheaters even.
No. Hashes are one way functions. So it'd be kinda pointless. Further, comparing two hashes for anything but equality is meaningless with most good hashing schemes (unless you're a cryptographer).
As someone who's successfully made a facial recognition system, I can say it's not far fetched at all, nor is it something "20 years from now". The tech is all there, it's just a matter of getting it to talk, and applying it correctly.
We can make systems to identify faces, all by themselves, with nearly 100% accuracy and no false positives. The limit of such a system is the volume of the sample material. This is esepcially true with fixed or predictable backgrounds. Likewise, we can make software to find and isolate faces in a picture. I've seen it done.
Sigh. Sure, Apple created a trademark to describe absolutely nothing! What brilliant marketing on their part!
Cut the kid some slack, he's from the Wintel world. I'm sure he's still smarting from the word "Centrino".
Centrino, as we all know, is just everything Intel normally has packaged with a cool logo.:P Woo intel. Don't be so surprised if everyone is so skeptical about corperate action, Microsoft and Intel haven given them plenty to be skeptical about.
Interesting to note that Objective C is much closer to raw C than C++, and as such yes. You can do some stuff with it that's worthwhile.
Also note that David Stes released his POC, which is an Objective-C->C compiler with a runtime he uses (actually it's a bit more than Objective-C) to run ObjC code today.
Apple will probably use this new compiler to recompile their CoreFoundation stuff, which is all C stuff that Carbon and Cocoa tap into. So, a simple recompile of CoreFoundation should net good speed improvements on G4s and MUCH better results on a G5.
So even if IBM chooses not to directly support Objective-C, Apple can still benefit in the short term while they rustle up their very own ObjC->C system (which is NOT a very challenging feat, considering the ObjC runtime is a relatively simple-to-use C library).
Then you make the comparison totally meaningless. That's like saying my friend on the bus beats me when I'm walking, therefore my friend on the bus is a faster. He may weigh 600lbs and need a walker to pee without falling over, but by the logic you're describing, he'd be faster.
You're right, GCC is not making good code for a P4, compared to what Intel's mature compiler can do. Apple, having just migrated to a very new type of PPC processor, has NO MATURE COMPILER. None. So the code they're making on GCC is also quite suboptimal. In fact, the code from GCC generated for a 970 is probably significantly worse than the code generated for a P4 on average. P4s are older, and there is a larger developer interest in almost every case.
So, it's not like Apple is somehow tying the P4 up and leaving it on the train tracks. Apple still gives Intel products the advantage. Until they can get a good optimizing compiler they have to do so. Apple is pulling dead even with machines much more expensive, faster, and with better tricks for accessing RAM in a speedy fashion. They are matching throughput against machines that, by Intel's numbers, should be beating them hands down no question.
Everyone likes to say a cheap-ish P4 is coming up dead even with Apple's most expensive system. I'd also like to point out the flipside of that coin, P4s are tying with Xeons which are much more expensive and are "supposed to be better". What do you suppose that means? Does it mean that this whole G5 and Xeon thing is stupid, and we should all just use P4s?
Maybe it means these benchmarks, while standard, are stupid, and not taking everything into account. It could also mean that Intel is HEAVILY optimizing for the SPECmarks. We know that Intel does it, by their own admission and people pointing out code generation hints.
So yeah, right now, Apple has a machine with no optimized compiler, and no OS to take advantage of it. However, it's keeping up with the best that intel has to offer in an even playing field, compared completely optimized Intel it only comes out slightly behind. These benchmarks show that the G5 is insanely fast, not insanely behind. Apple is taking every handicap and still coming up dead even. All they ask is that the field itself isn't at a ridiculous slant against them, hence the use of GCC to make the comparisons meaningful in any way.
I've rapidly been discovering that in Panther, I need tabs less and less. Expose really is a great way to deal with multiple windows and multiple apps. More and more, I find myself using Expose and a lot of windows instead of tabs, because tabs provide no visual recognition besides a title, which can very frequentlh be identical over multiple pages.
So maybe that trollish AC that replied below this about tabs being a stopgap for a bad window manager is partially correct, if somewhat socially inept. Between app hiding, app switching, and Expose functions for all apps, and-in my opinion, far more useful-just one app, tabs are actually more of an annoyance.
spell checking forum input as I type without my needing to manually request it (I can't believe they still haven't fixed this in Safari).
Err? I don't (nor have I ever) had this problem? Every cocoa text input widget supports spellchecking as you type. It should stay that way once you use the context menu to set it. Is this status of that option resetting itself common?
Yeah, title says it all. I just wanted to plug http://www.fingerworks.com/ for their incredibly good Touchstream Keyboards, that support very natural horisontal and vertical scrolling without taking your fingers off the home row!
Were Apple to release the full Safari source, it wouldn't mean much to most people. Apple Developers would like it. No one else would. It's not like you can use the code with any other OS, and I doubt that GNUStep would handle it.
So really, it's pretty pointless to do so. Apple can appease developers just as well with a good plugin system.
They released their webcore library, man. That's pretty much everything safari is, save for a lot of boring user interface code. Since webcore is just a ObjC wrapper to KHTML, this is no big deal.
However, it's interesting to note that Apple did relase somehthing to the community, and I have yet to see anyone pick up on it. Apple'a "snapback" mode... This is a really useful, I daresay innovative, feature for a web browser. I use it all the time on slashdot. Especially when you have gestural input, either via a keyboard like mine (see my sig) or the cocoa gestures framework, it really makes site naviagation a breeze.
Also, Apple's method of handling bookmarks is significantly different from most. If only they'd incorperate the Omniweb (check for updates) features Safari would be one of the best browsers out there.
I really fail to see how you can draw a line between "click-thru license" and "indentured servitude" unless:
You are an anti-apple troll.
You have no concept what Apple actually asks for.
You think that there is more to a darwin developer account than agreeing to the APSL.
While the first may be true, the second and third are not. It is becoming more and more aparent that "By using this you agree.." licenses are not tenable, which is why many people are moving away from them. Apple effectively makes a click-thru license scheme and you get angry, but when Gnu contemplates it, you don't.
Silly slashdot-ite, double standards are for kids.
That's not what we mean by clean, friend.
on
Ruby 1.8.0 Released
·
· Score: 2, Insightful
I'm a big fan of Ruby and its clean syntax too, but I think MarkusQ (and subsequent repliers) mistake what that means. Ruby's syntax is clean in that there isn't a lot of stuff in the syntax just to define statements, expressions, lists and whatnot. C++ might be called a "dirty" syntax-or at least a "dirty-er" syntax.
A good example of this is the lack of need for semicolons at the end of each line. Ruby has semicolons for statement separators, but you only need to use them when there are multiple statements on one line. For example:
# No need for; puts "Hello World" puts "Hi mom!" # On one line, need; puts "Hello World" ; puts "Hi mom!"
Another example is that you don't have to use straight brackets to delimit arrays. You only must use them to
clarify confusing situations.
It's important to differentiate this attribute from the flexibility of the syntax. Ruby allows you to use, or not use, certain pieces of its syntax to help you adjust to it. For instance, when calling sending a message to an object, you need not use parenthesis to delimit the message parameters. In general there is a synonym for most every syntactic feature. One is the common usage (like//) for regexps) and a more flexible, formal usage (like %r for regexps).
One might be tempted to say that is what's wrong with Perl, and to a degree that's true. Ruby however, keeps its core syntax quite small. The synonyms exist for a clear and obvious purpose. Perl seems to lack that purpose, instead citing TIMTOWTDI.
Thanks, IE. Repost that isn't ruined
on
Ruby 1.8.0 Released
·
· Score: 2, Informative
Never try to post on a windows machine, they're out to get you:P
Don't forget some of the other unique uses of blocks, that make them very, very powerful.
They can be used in unique ways that are pretty darn useful. For instance, you can use them to create configuration blocks for objects, without cluttering the constructor.
A constructor aware of this can use this block to configure the object in ways that normally would require dozens of different constructors, with a relatively unambiguous syntax. Even better, defining those set functions for the configuration block also defines them as instance variables. 2 foe the price of one!:)
With a little thought and use of Ruby's excellent security model, it's possible to even just dump a file into that block, and use the file as the configuration block!
Slashdot Mirror
Even were they to use the specified procedure to change your machine's auth info, they couldn't log in unless you have SSH enabled.
There are very few reasons to have sshd enabled on a portable machine. Can you name some?
You lost yours the moment you began arguing both sides of the same argument. One for Opteron (set up for SMP, which incedently means set up for context switching and context sharing) and another for G5 (implication that P4's context switching is not slow compared to G5, which is also very optimized for SMP).
Among other things. Like, "I don't own a P4, but I'm bragging about the one I'm using right now."
Sorry, I just don't have the time to play games with people like you. I'll condecend when it sounds like you deserve it. And you, my poor comrade, seem to yearn for it.
I won't claim to understand why so many people on slashdot are so eager to make arguments so patently false. For a moment I thought you were actually saying something and began to respond.
Okay, at first I thought you were just trolling, because my experiences with the G5 have been liquid smooth. Maybe we're using different meaningw or responsive sand smooth? On my dual 800 and even on my iBook there an be some frame loss when dragging very large windows or doing that minimize effect, but it's only when the machine seems especially occupied, and doesn't affect the rate at which things move.
Maybe you're referring to the mouse-interaction delay bug that very few mice display on some machines? Some mice and some machines apple makes have an odd interaction where your click occurs a few ms after you press the mouse. It can be quite disturbing until you realize it and switch mice.
Maybe you're talking about window resizing? I wouldn't blame the machine. I'd blame the app writers, but even above and beyond that, OSX is pretty much the only game in town doing live resizing, so it's hardly a fair comparison. Of course, you don't seem like one for fair comparisons.
With liquid cooling, in every example I've seen. Sorry, that just isn't going to work for the masses. It also tends to dramatically increase the cost of pre-built machines. Most people, like intel's sales department, don't consider this a "success".
Umm.. no. Looking at the results and then quoting the article:
In other words, they snipped off some time! The G5 had to load the controls to finish the operation and return to normal status. The P4 didn't. Probably, they snipped off some time because it's PC mag, I am not very surprised or very upset. At least they mentioned it in the article.
Let's ignore that for a second or two. I'll say again: there is NO OPTIMIZED OS OR OPTIMIZING COMPILER FOR OSX . So the fact that in general the G5 comes up mighty close to being even after the time-snipping, means it's much faster.
Hmm. I use IMAP. I get a pretty low amount of personal mail and I'm subscribed to Ruby-Talk, which I keep a 1 month archive on. This means I have about 7k-10k messages at any given point.
Indexing those for content is not a trivial task.
Bullshit. But go on.
Yeah, um, it's plenty responsive on my iBook 800. I do not know where you're drawing this from. Are you complaining that OSX doesn't have a smooth scroll feature like Windows does? They do in Panther, but honestly I don't like them. It's a lot harder to tell how far you're scrolling when there is an animation delay imposed.
I'm sorry, you can't get away with that here. The P4 has a much, much higher clock rate. It means that yes, for doing one thing, especially one more-or-less simple thing, you probably will win in a footrace. Duh.
It doesn't mean that your machine will do better at multiple parallel tasks. The P4 is just slower at it. Also, its architecture won't do contest switches as quickly between threads. Part of the reason Intel is adding the on-die memory controller and more cache is to try and hide this fact. Intel's hit the limit with the P4, more or less. Maybe they can get a bit more clockspeed, but they're topping out with what's reasonable in an aircooled machine.
The G5s are keeping up with an unoptimized OS, a lack of optimizing compiler, at a clockspeed much lower than the architecture's maximum.
Why not ask GamePC to define it. They're the one I'm angry about. You have a funny idea of "real world" must be. Everyday web browsing and use? Everyone I know tends to check their email and browse the web while their email loads. Now, those are both processor and memory intensive tasks. Your mail program index, spam filters, and places your mail in a data hierarchy. Meanwhile your web browser is rendering relatively complex operations. Usually it's doing them in parallel. Scrolling is also relatively expensive.
This is an everyday case that the P4 copes with poorly. The ameliorating effect of the larger cache and memory controller only carries you so far.
A typical game is a nightmare for a single P4 machinel Multiple threads all doing different memory and I/O intensive things, with your video card you can't always use DMA! Sometimes the P4 has to send stuff manually. The P4 can only keep up with modern games by virtue of its high clock speed. As the Opteron and G5 catch up, the performance barrier will only become more and more apparent.
As it stands now, I still feel that a 1.8ghz G5 or Opteron will "blow the doors off" a P4. I've gotten the chance to use said G5 and my friend's P4 is roughly of the spec we're talking about. By the way, did you notice that the G5s aren't set up to use their altivec, while the P4s are going to use SSE? Yet another handicap. The altivec doesn't just help with floating point you know. It does integer ops just as fast, on a variety of sizes. Auto-vectorization in a compiler would turn ordinary code into screamingly fast code. With no OS optimized for it and no optimizing compiler.
The G5 is blindfolded, has one hand tied behind its back and the other opponent has a spear. And it still wins.
Everyone who's tried it agrees, it's impossible to get the G5 to slow down. Three apps open up as fast as one does (unless they have to do network stuff to boot, then the network latency comes in of course). My friend's P4 with lots of the best DDR ram he can slot still stutters on the Start menu, let alone starting several apps at once.
And no, he doesn't suck at building machines. He's actually quite good at it, I assure you.
I have to say, this is probably one of the funniest things I've read this month. It's like a troll in the opposite direction! :)
"Are you also noting that a 3Ghz P4 is quite a bit faster than both of them (and a *lot* cheaper) ? :)"
Umm.. you know why these benchmarks that everyone does are stupid? Because the test the machine doing one task at once. Sure, the task has multiple parts, and may include more than just the processor, but all too often we see these little head-in-the-sand benchmarks that make the 3Ghz P4 look so good.
It's not. Want a real test? Run two of these benchmark tests simultaneously. Run 3. The p4 has a vastly higher clock speed. Unsurprisingly, when you focus it on one small task, it completes it quite fast, even though it's doing so less efficiently.
The Opteron and PPC970 do more things efficiently. As you might guess, this is the "real world" scenario, where our machines do many, many things at once. Your machine is performing dozens of distinct tasks, right now. Many Opteron reviews are claiming the chip doesn't benchmark well under the current idea of what benchmarking should be, but in real world tests they easily outperform the P4s. No one questions them. The G5 and the Xeons are the same way. When you try and take account of the innumerable factors that make a computer fast and condense them down to a small set of "average values" you're going to get a distorted picture, favoring people who play the benchmark game.
Ironically enough, the Xeons and the G5 still royally stomped on everyone else. I find this very satisfying. I like seeing those silly P4 chips lose at their own marketing game.
These benchmarks are stupid, small, outdated, and almost seemed designed from the ground up to favor machines with high clockspeed.
"98% of what we do as software developers can be done with equal speed on a dual-processor G5, a G4-based iMac, or a G3-based iBook."
Speak for yourself. I have done software development on my Dual G4, my 800mhz iBook, and my friends shiny new G5 for an afternoon. IDEs are ever-increasing in complexity and responsibility. Apple's new XCode and VC++ have for a long time done many, many things that require quite a lot of lookups, analysis, and parse tree building.
Sorry, these things create stutters, slowdowns, and obnoxious hangups when I develop. I've used VC++, Eclipse, ProjectBuilder and XCode. All benefit hugely from faster machines. I wince at coding using a real IDE like Eclipse or Xcode on my iBook, which has a max ram loadout. It's not a huge deal on my G4, and I'll wager a G5 eats it alive and asks for seconds.
On the G5, everything was happening instantly. It was kinda eerie. I built the newest Ruby on it for my friend, using xlc (the better cache management actually speeds ruby up appreciably, like 10% in some operations!).
It took about 25-40 seconds ( I wasn't timing, so I'll keep the range broad). That's compared to about 3:25 on my dual G4. Admittedly, I'm not using xlc here, but it gives you something to think about.
Fast compilers are very important to people who rely on their compilers to find errors, the build-fix-build-fix cycle is standard procedure anywhere you go, and faster compiling computers make you wait less time for that.
Well, SCO can easily, trivially, and even somewhat believably claim Scenario One (which they will). Remeber, they're already twisting what everyone says, and outright lying.
:)
In order for any tool to really debunk stuff and be usefull, it has to be extremely comprehensive, thourough, and correct. Otherwise, it's only so much chaff that doesn't help much.
What we need are comparisons so thourough that no one can deny them and look sane.
Maybe SCO isn't the group to do that anyways
Not if there is even one different line. Add a comment, say. Or anything. Just one character will ruin that slice. Just one line will completely remove any chance of finding it.
It's still a useful tool. Just not for the SCO case, or any case where the honestly of the authors is in question.
Would it? What if it's been reformatted into the GNU coding style? Spacing matters.
Let's say it was copied more or less verbatim, but the number of lines is slightly different by a comment (which should be ignored). Unless these situations are corrected for, the windows could be misaligned. Suddenly identical regious that are shifted slightly would appear different, and the docs say that it throws out differences.
Even if this tool works much more intelligently than is explained, it wouldn't matter to the SCO case. They'll just claim it's obfuscated, and even the most miniscule of changes would ruin this tools' ability to give accurate results, even with a window of 1.
Having helped work on my University's source code analysis tool that they use to prevent cheating, I can say this kind of approach would even have problems keeping honest people honest, let alone catching dishonest people.
Yeah. See my other post in this thread, where I ask just that. I don't think that this tool is meant for comparing source trees. ESR is smarter than that.
Well, I was looking at ESR's description of the code (I haven't read the code yet), and it seems to say that he takes 3 line slices, MD5s them, then compares them for identical points. I'm sure he compensates for funky whitespace and whatnot like diff and patch do...
But if even one bit of the source is different, the MD5 hash will be quite different. So, the code slices have to be IDENTICAL. This is not a very good system because a simple find-replace could defeat it. A variable's name changed by one letter, or even capitalization, will defeat it.
Unless the code reveals much more complex tricks than ESR describes in the help file, this tool wouldn't be much use in the SCO case. Hell, it wouldn't be much use catching college class cheaters even.
No. Hashes are one way functions. So it'd be kinda pointless. Further, comparing two hashes for anything but equality is meaningless with most good hashing schemes (unless you're a cryptographer).
As someone who's successfully made a facial recognition system, I can say it's not far fetched at all, nor is it something "20 years from now". The tech is all there, it's just a matter of getting it to talk, and applying it correctly.
We can make systems to identify faces, all by themselves, with nearly 100% accuracy and no false positives. The limit of such a system is the volume of the sample material. This is esepcially true with fixed or predictable backgrounds. Likewise, we can make software to find and isolate faces in a picture. I've seen it done.
It's not improbable, it's just not ready yet.
Cut the kid some slack, he's from the Wintel world. I'm sure he's still smarting from the word "Centrino".
Centrino, as we all know, is just everything Intel normally has packaged with a cool logo. :P Woo intel. Don't be so surprised if everyone is so skeptical about corperate action, Microsoft and Intel haven given them plenty to be skeptical about.
Interesting to note that Objective C is much closer to raw C than C++, and as such yes. You can do some stuff with it that's worthwhile.
Also note that David Stes released his POC, which is an Objective-C->C compiler with a runtime he uses (actually it's a bit more than Objective-C) to run ObjC code today.
Apple will probably use this new compiler to recompile their CoreFoundation stuff, which is all C stuff that Carbon and Cocoa tap into. So, a simple recompile of CoreFoundation should net good speed improvements on G4s and MUCH better results on a G5.
So even if IBM chooses not to directly support Objective-C, Apple can still benefit in the short term while they rustle up their very own ObjC->C system (which is NOT a very challenging feat, considering the ObjC runtime is a relatively simple-to-use C library).
Then you make the comparison totally meaningless. That's like saying my friend on the bus beats me when I'm walking, therefore my friend on the bus is a faster. He may weigh 600lbs and need a walker to pee without falling over, but by the logic you're describing, he'd be faster.
You're right, GCC is not making good code for a P4, compared to what Intel's mature compiler can do. Apple, having just migrated to a very new type of PPC processor, has NO MATURE COMPILER. None. So the code they're making on GCC is also quite suboptimal. In fact, the code from GCC generated for a 970 is probably significantly worse than the code generated for a P4 on average. P4s are older, and there is a larger developer interest in almost every case.
So, it's not like Apple is somehow tying the P4 up and leaving it on the train tracks. Apple still gives Intel products the advantage. Until they can get a good optimizing compiler they have to do so. Apple is pulling dead even with machines much more expensive, faster, and with better tricks for accessing RAM in a speedy fashion. They are matching throughput against machines that, by Intel's numbers, should be beating them hands down no question.
Everyone likes to say a cheap-ish P4 is coming up dead even with Apple's most expensive system. I'd also like to point out the flipside of that coin, P4s are tying with Xeons which are much more expensive and are "supposed to be better". What do you suppose that means? Does it mean that this whole G5 and Xeon thing is stupid, and we should all just use P4s?
Maybe it means these benchmarks, while standard, are stupid, and not taking everything into account. It could also mean that Intel is HEAVILY optimizing for the SPECmarks. We know that Intel does it, by their own admission and people pointing out code generation hints.
So yeah, right now, Apple has a machine with no optimized compiler, and no OS to take advantage of it. However, it's keeping up with the best that intel has to offer in an even playing field, compared completely optimized Intel it only comes out slightly behind. These benchmarks show that the G5 is insanely fast, not insanely behind. Apple is taking every handicap and still coming up dead even. All they ask is that the field itself isn't at a ridiculous slant against them, hence the use of GCC to make the comparisons meaningful in any way.
Doesn't anyone get this?
I've rapidly been discovering that in Panther, I need tabs less and less. Expose really is a great way to deal with multiple windows and multiple apps. More and more, I find myself using Expose and a lot of windows instead of tabs, because tabs provide no visual recognition besides a title, which can very frequentlh be identical over multiple pages.
So maybe that trollish AC that replied below this about tabs being a stopgap for a bad window manager is partially correct, if somewhat socially inept. Between app hiding, app switching, and Expose functions for all apps, and-in my opinion, far more useful-just one app, tabs are actually more of an annoyance.
Err? I don't (nor have I ever) had this problem? Every cocoa text input widget supports spellchecking as you type. It should stay that way once you use the context menu to set it. Is this status of that option resetting itself common?
Yeah, title says it all. I just wanted to plug http://www.fingerworks.com/ for their incredibly good Touchstream Keyboards, that support very natural horisontal and vertical scrolling without taking your fingers off the home row!
Were Apple to release the full Safari source, it wouldn't mean much to most people. Apple Developers would like it. No one else would. It's not like you can use the code with any other OS, and I doubt that GNUStep would handle it.
So really, it's pretty pointless to do so. Apple can appease developers just as well with a good plugin system.
They released their webcore library, man. That's pretty much everything safari is, save for a lot of boring user interface code. Since webcore is just a ObjC wrapper to KHTML, this is no big deal.
However, it's interesting to note that Apple did relase somehthing to the community, and I have yet to see anyone pick up on it. Apple'a "snapback" mode... This is a really useful, I daresay innovative, feature for a web browser. I use it all the time on slashdot. Especially when you have gestural input, either via a keyboard like mine (see my sig) or the cocoa gestures framework, it really makes site naviagation a breeze.
Also, Apple's method of handling bookmarks is significantly different from most. If only they'd incorperate the Omniweb (check for updates) features Safari would be one of the best browsers out there.
- You are an anti-apple troll.
- You have no concept what Apple actually asks for.
- You think that there is more to a darwin developer account than agreeing to the APSL.
While the first may be true, the second and third are not. It is becoming more and more aparent that "By using this you agree.." licenses are not tenable, which is why many people are moving away from them. Apple effectively makes a click-thru license scheme and you get angry, but when Gnu contemplates it, you don't.Silly slashdot-ite, double standards are for kids.
A good example of this is the lack of need for semicolons at the end of each line. Ruby has semicolons for statement separators, but you only need to use them when there are multiple statements on one line. For example:
Another example is that you don't have to use straight brackets to delimit arrays. You only must use them to clarify confusing situations.It's important to differentiate this attribute from the flexibility of the syntax. Ruby allows you to use, or not use, certain pieces of its syntax to help you adjust to it. For instance, when calling sending a message to an object, you need not use parenthesis to delimit the message parameters. In general there is a synonym for most every syntactic feature. One is the common usage (likeOne might be tempted to say that is what's wrong with Perl, and to a degree that's true. Ruby however, keeps its core syntax quite small. The synonyms exist for a clear and obvious purpose. Perl seems to lack that purpose, instead citing TIMTOWTDI.
Don't forget some of the other unique uses of blocks, that make them very, very powerful.
They can be used in unique ways that are pretty darn useful. For instance, you can use them to create configuration blocks for objects, without cluttering the constructor.
A constructor aware of this can use this block to configure the object in ways that normally would require dozens of different constructors, with a relatively unambiguous syntax. Even better, defining those set functions for the configuration block also defines them as instance variables. 2 foe the price of one!With a little thought and use of Ruby's excellent security model, it's possible to even just dump a file into that block, and use the file as the configuration block!