Determining performance bottlenecks without measurement is a mugs game. Even experts get surprised. Expertise is useful in forming hypotheses, but measurement is required to sort out the truth. Having said that, I will wade in without measurements.
| From: Julian Hall <[EMAIL PROTECTED]> | | JT Moree wrote: | > *) Legacy hardware like pcmcia and parallel ports. (pcmcia is basically ISA) What you say about PCMCIA is true. But PCcard should be pretty reasonable and most cards that matter are PCcard these days. For our notebooks, the only PCcard I use is an 802.11g card (because it is well supported by Linux unlike our built-in 802.11g). | > *) less market share so less R&D budget on tweaking for performance. Most tweaking is for WinXP, I would guess. | > *) optimized for battery life rather than performance. Yes. But where does this show up on our notebooks? Probably the disk drive. Probably some power management settings (under our control). | a) CPU is usually a cut-down version of a desktop variety - smaller cache for | example, so it's not going to get the throughput of its' big brother in the | desktop. I wish. My notebook has a straight power-hungry desktop chip. The CPU (AMD 64 32000+) was pretty powerful when my notebook was built (faster than my desktop produced at the same time). It is obsolescent now, in desktop terms: Socket 754. Still, not a bottleneck in my machine. This is true for that generation of our notebook. I guess later ones may have Turion (aimed at notebooks) or Semperon (cut down performance to sell at a lower price point) chips -- these may be slower. Perhaps all AMD notebooks have Socket 754 vs the Socket 939 found in more recent non-Semperon desktops. 754 has single-channel memory access so it should be somewhat slower than 939 which has dual-channel. My guess is that the difference is modest on most workloads -- if the data fits in the cache, there will be almost no difference. The chipset matters too. I think that the nForce in my notebook is performant EXCEPT for the video portion. | b) slower HDs, typically 4200rpm instead of the standard 7200 in desktops Yes. And there are other performance characteristics that matter. Also look at seek speed. Also the disk-to-buffer transfer rate matters (much more than the buffer-to-host transfer rate). | c) SATA has not found its' way to laptops yet (AFAIK) I don't think SATA should matter. At best, it should speed up the buffer-to-host transfer rate, but we already discussed how this was not a bottleneck. SATA II (not the correct name, but what people call it) introduces Native Command Queueing which in some cases will make a performance difference. It allows the CPU to issue a bunch of commands to the disk and have the drive choose the optimal order in which to execute them. Whether you would notice any difference on a laptop workload is not clear to me. (See my comment about PIO at the end of this message.) | d) Graphics memory is quite often (not always) shared, so that reduces the | resources still further. This might be very important. I certainly don't know without measurement. But it has two effects: - graphics operations are quite a bit slower in theory - even passive screen refresh steals memory bandwidth from the processor On the other hand, I've had lower cost desktops with shared memory graphics and haven't noticed a big hit for my (non-graphics-intensive) uses. | From: Gregory Gulik <[EMAIL PROTECTED]> | | I have a Sony Vaio laptop which I bought in January with a SATA hard | drive. Let me tell you, it makes a HUGE difference. Although the clock | speed of the Vaio is only slightly faster than my R3000Z the performance | is WAY better overall. It's especially noticeable when opening large | applications and/or files and any time the laptop needs to swap. As I said, I don't expect that the difference is in the use of the SATA aspect of the drive. It may well be other aspects of the drive that matter. I assume that the PATA drive is running in some Ultra DMA mode. Using PIO has serious performance impacts. This could happen if, for example, the kernel blacklists the controller. This might be worth checking. _______________________________________________ LinuxR3000 mailing list [email protected] http://lists.pcxperience.com/cgi-bin/mailman/listinfo/linuxr3000 Wiki at http://prinsig.se/weekee/
