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 : All About Sun Microsystems -- Ignore unavailable to you. Want to Upgrade?

To: JavaGuy who wrote (16680)	5/28/1999 4:15:00 PM
From: Byron Xiao	Read Replies (2) \| Respond to of 64865

JavaGuy: I am one of those EE-converted software engineers. Although I am going to have my MS Computer Science degree soon, I still enjoyed EE a lot. You work on the lower level and you have a better understanding of how things work. I found guys like the Gang-of-Four talking about design patterns in object oriented design paradigm are so much above the hardware level that they often lose some perspective on how well their designs would work on the hardware. Ugly codes sometimes mean fast code, if you look at the clumsy 7 layer OSI models, how inefficient it is to copy data down the protocol stacks!! one of the most expensive operations is memory allocation in a system, when you have 7 layer and you try to transfer a 10KB of Web page, it's hugely inefficient. If all you have to do is define your output port address as 0x00abcdef, and write an assembly code put(data, 0x00abcdef), that's all you need. That's the code EE would write, it's bad, bad, ugly, ugly code, but it works a hell lot faster than layering. Instead, in layering you would have to map a file descriptor to this address using the socket call, specify the protocol family and communication semantics in the socket call, underneath, you have TCP allocating buffer for data, IP reserve more buffer space for packet assembly, and your device driver working the link layer magic in the protocol stack. Then, when you do your write operation, TCP has to worry about reliable connection oriented data transfer, IP has to worry about packet fragmentation, packet re-assembly, your device driver has to worry about CRC checksum, packet collision on the local ethernet or the modem. Worse, your damn browser has to support so many features that it makes the page rendering/display an even slower task. 90% of the performance problems are caused by software. Time it yourself, a 10KB WEB page over a 28.8K modem should be displayed in 3 seconds, but it's taking 30 seconds. why? because of the software. But we can't do the EE approach, because it's impossible to maintain, extend codes that way. However, if your apps don't consider what context it's running on, then, your apps can't be a good app. If you write your app the same way when it's running on a 10Mb Ethernet as you would when you app is running on 28.8Kb modem on the internet, then you should seriously question yourself, how good you are as a SE.