Silicon Investor (SI) -- The First Internet Community

STOCKTALK

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor. We ask that you disable ad blocking while on Silicon Investor in the best interests of our community. If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.

Technology Stocks : Intel Corporation (INTC) -- Ignore unavailable to you. Want to Upgrade?

To: Barry Grossman who wrote (43796)	1/4/1998 3:15:00 AM
From: Joe NYC	Read Replies (1) \| Respond to of 186894

Barry, Software writers who participate here are few and far in between. Your viewpoint is valuable. What about a 100 or so posts from me? <g> I am a programmer. There are a lot of programs that are not being written because a lack of hardware power. As the hardware horsepower grows, more software systems become feasible. The trick is to know ahead of time if the application you are about to write will be constrained by currently available hardware, and if it is at all feasible. There is a lot you can do as a programmer to speed up code. But in general, it only make sense to spend time on sections of the code that are noticable to the user. Joe

To: Barry Grossman who wrote (43796)	1/4/1998 9:40:00 AM
From: Stephen Neece	Respond to of 186894

Barry, As you could imagine, there are many applications that have been written which require a good bit of offline(batch) processing. A lot of these types of things could be done on the fly if the processors could handle it. Sattelite image processing currently takes hours of compute time to do automatic map symbolization to arrive at what you finally see on the wall. We also do radar sector coverage analysis. The user plops down a radar and presses go and waits for the analysis to complete. We would like this to happen on the fly as the user drags the symbol. The benefits are incredible since the users will be able to just move the symbol until he sees the best coverage. Currently, We have to limit the beam separation and the number of floors to make the software responsive to the user. Moving through a 2d Transverse Mercator or Lambert Conic Conformal viewport on the screen is a compute intensive process. The equations themselves are demanding. Most everyone now uses a Sinusoidal Projection due to the limited math required. However, though it is an equal area projection, it is not the best in all cases. We also support 3d views in which ADRG (Arc Digitized Raster Graphics) is Draped over (DTED) Digital Terrain Elevation Data and Color Coded Elevation Data is calculated and Displayed. Symbolic Vector overlays and Dynamic Track are then drawn in the scene. The user is allowed to hook a track and fly along with it. While you can get drawing the data with graphic accelerators, Recalculating the scenes on the fly takes an inordinate amount of CPU horsepower. Note, I am talking about true draping, not texture mapping. As far as data collection, we have two feeds at 1/10 second interva and at 4 second interval. The data is all interelated such that missing a packet is not allowed. Each feed may contain several hundred tracks. We have to maintain a track file for all this data, correlate them with one another and Render them to each of the currently displayed viewports. All of this is going on while the user is running other simulations that are doing Threat analysis. Now imagine this application running on the same machine with at least two other applications which are just as demanding on the processor. Now Picture us needing this capability on a lap top within the next two years and you see how bad we are screwed :) Thats about as specific as I am willing to get in this forum. This typing stuff gets old. Got to go for now.. Hope this helps, Neece