On Mar 12, 2009, at 10:54 AM, Bill Bumgarner wrote:
On Mar 12, 2009, at 10:29 AM, John Engelhart wrote:
Actually, this isn't a "micro-benchmark".
If you aren't displaying the results, responding to user events,
keeping an application state up to date and otherwise doing all of
the things that need be done in a real world application, it is --
effectively -- a micro-benchmark.
LOL! There are applications that need to do intensive data
processing. These applications are NOT micro-benchmarks. I bet
Google would be somewhat surprised to find that all they are doing all
day is running microbenchmarks.
In the context of an application, such processing is likely to be on
a secondary thread and there is likely to be synchronization of data
between threads.
The overhead of the write barrier (which is spin lock contention
under the covers, most likely) will be somewhat offset by the vast
decrease in the cost of moving objects between threads, for example.
The synchronization overhead for moving progress updates across
threads every 10th of a second is negligible unless you're doing
something very very wrong.
Having the processing 2.8x slower will not be helped by putting the
processing on a background thread: you will still have to wait 2.8x
longer for your results. Your app may be responsive during that time,
but that is of dubious value if you are waiting for results.
Think about processing HTTP server logs, and then
performing more regex operations the further massage the end results
(ie, the host only portion of the referrer).
Sure -- and if I were writing a Cocoa application to do exactly
that, it would be doing all kinds of UI updates during the process
to keep the user up to date on progress, give them a feel for
whether the analysis is moving along in the correct direction,
etc,etc,etc.... and all of that graphics related chatter is very
likely going to far outweigh the CPU cycles consumed by the actual
data processing bit.
Not if you're doing it right.
If I were writing a command line tool to process log files in
batches -- which I have done many times on the scale of 10s of GB of
logs produced per day -- I wouldn't use Cocoa or Objective-C at all.
This makes me very sad. I *would* use Objective-C for data-intensive
processing, wether in command-line or GUI apps or servers, and have
done so in the past with great success, but it looks like you're quite
happy to relegate Objective-C to the role of a toy/glue language for
hooking up GUIs, incapable of handling the demands actual data
processing. What makes this even more ironic is that Objective-C was
specifically created to provide high performance, and is absolutely
capable of doing so.
Don't get me wrong -- I'm not saying that you haven't found a
particular test where, at the extreme,
It is only extreme if you consider any type of data-intensive
processing 'extreme'.
Regards,
Marcel
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
