Re: [NSTask] -launch return
Re: [NSTask] -launch return
- Subject: Re: [NSTask] -launch return
- From: M Pulis <email@hidden>
- Date: Fri, 12 Jun 2009 00:31:44 -0700
On Jun 11, 2009, at 12:29 AM, ERG Consultant wrote:
Do you know anything at all about how os'es work?
THANK YOU FOR ASKING! See below for details.
Yes. For example, Rosetta is not an OS. It is scheduled by the OS.
I was also in attendance at WWDC when they introduced Rosetta. Given
my background (below), I (and many others) had questions. They had
answers.
Rosetta is an emulator. It uses up a lot of memory when running
even if no ppc apps are running. It has nothing to do with machine
startup delay and everything to do with the fact that it remains
running once started.
until the PPC app exits, leaving only memory occupied... no "running"
Consuming resources (memory) when my app may never be run ( it's a
game) is a really really bad idea.
My suggestion was clearly presented to you as a HACK, as a HACK.
You (still) have the issue with a one-time delay of 2-3 seconds at
any time.
You already took our suggestion of a DTS incident, "for crying out
loud" as nobody could satisfy you here.
Yes, I know it occupies memory. Serious users and gamers know that
adding memory improves performance.
It also consumes cpu cycles just by virtue of running.
Yes. It consumes cycles _while_ running a PPC task, yes. Running ==
cycles consumed, yes.
If no PPC task is running, Rosetta is not scheduled and not eating
cpu cycles. What is it doing (other than having an intolerable RAM
buffer robbing you of exactly "a lot" of bytes, that could be swapped
out) after the only PPC task exits and the next is launched? Keeping
the filaments warm? Revving the engine? What percent of CPU is
occupied by Rosetta if no PPC task is running?
How, if Rosetta indeed runs on the PPC app's thread (Apple's claim),
does it continue to "run" once the thread exits? Big magic? For what
purpose?
No user wants their computer slowed down every time they boot.
Good to see you have talked to ALL users.
I never said wants... given the choice of when to spend the required
time, to give the user the quick first - click startup, to, as others
have said, prime the pump. Did you know that MacOS actually makes
network connections during startup... whether or not you need
networking? What a waste!
Our user class rarely reboots, often times leaving their macs running
for days. yet opening and closing apps all the time. Our app is a
medical management app and the primary app our users run (some since
1988). Once daily boot time is not an issue for stable software.
I am sure that you are aware that boot time is also variable (warm vs
cold boot vs power fail or crash reboot or update reboot plus sharing
services), and not a constant, while app startup time can be made
reasonably uniform.
Go read Tannenbaum's book for crying out loud.
Gee, Thanks for the trip down memory lane! :-)
I'm sure _you_ know exactly how Rosetta is implemented by having
already read the significant addendum, of course, silly me for even
suggesting an actual Apple document of relevance to the implementation.
For others not so enlightened, I offer:
http://developer.apple.com/documentation/MacOSX/Conceptual/
universal_binary/universal_binary.pdf (revised 2009)
Likely a better reference to the actual Rosetta technology
implementation.
And of course, DTS will give show you the CORRECT way. I'm sure you
already have a really cool solution from them that we could not think
of.
Gary
Background:
After completing my degree program in 1973 I joined Honeywell in
1975. From 1977-1982 I worked on the hardware engineering team at
Honeywell Process Control (refineries, paper mills, power plants)
creating a 48-bit CPU (the "4500", about the size of a 10" deep 19"
rack of 4-6 layer printed circuit boards that we assembled) emulating
their top of the line 24 bit TTL-Discreet mainframe (the "4400", the
size of a stand up freezer, that we also assembled). We outperformed
the original 4400 by designing a micro-kernel based board set using
Large Scale IC's and a complete firmware emulator of the 4400
instruction set and programming model.
Cheap solid state memory and winchester-drive disks were overtaking
magnetic core memory. A great deal of attention was paid to
conserving clock cycles first, RAM second. Spend a little RAM to save
some clocks. The microkernal wasted zero cycles in the emulator
firmware if no 4400 tasks were in the pipe, yet was very fast (about
4x on average) when emulating.
As my job was to insure that these boards could be tested by
developing the test methodology, I was quite involved with
engineering, manufacturing and software groups. I designed
specialized stand-alone test gear that used 8-it uP's and wrote
assembly code that simulated (not emulated) the board logic of 4
different high-density boards in the CPU and a board controlling the
operators 24" touch screen console. It was accurate to the extent
that engineering could qualify design changes in ROM's and FPLA's by
comparing their board(s) to my simulator. No longer did they need to
stock "known good boards" for comparator machine testing in
manufacturing.
Their OS was RTMOS - Real Time Multi Operating System (affectionately
known as RatMouse). Every CPU cycle was accounted for as we analyzed
how RTMOS worked under load. Ahhh, the late nights starring at logic
analyzer tracings followed by meetings analyzing the traces and
slaying code.
g
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden