Article: Escape From the Planet of x86
By: José Javier Zarate (jzarate.delete@this.unav.es), June 22, 2003 7:55 pm
Room: Moderated Discussions
Yes, but in case of SPEC you cannot recode so the improvements only can be obtained through compilation.
Vincent Diepeveen (diep@xs4all.nl) on 6/22/03 wrote:
---------------------------
>In short we can definitely say that there is performance differences, but usually
>good programmers can optimize very well and get around it.
>
>But to give some examples:
>
>example a) you run 4 processes at a single cpu and they are mutually locking.
>
>In windows you implement it for example with the well known WaitForSingleObject()/WaitForMultipleObject().
>
>In Linux you lock as it has no WaitForSingleObject().
>
>In IRIX you also lock using spin_lock().
>
>Then you measure performance and linux is tens of times slower than both the other OSes.
>
>It appears then that both IRIX and windows are first trying to lock the object
>a few times in a row without putting a process into the runqueue. So if such an
>object is released within say 600 ns then the processes can run on.
>
>However under linux there is no such function for multiprocessing, so each process
>gets in the runqueue which means a 10ms latency each time, which is pretty much slower than < 600 ns :)
>
>Trivially some good programming can speedup the software at all the OSes a lot.
>
>Paul DeMone (pdemone@igs.net) on 6/22/03 wrote:
>---------------------------
>>Anonymous (nn@nn.invalid) on 6/22/03 wrote:
>>---------------------------
>>>Paul DeMone (pdemone@igs.net) on 6/20/03 wrote:
>>>---------------------------
>>>>The SPEC CPU suite programs are specifically selected and sometimes even
>>>>modified to minimize the influence of differences in OS and language libraries
>>>>across platforms.
>>>
>>>Then why is e.g. Intel's compiler for Linux showing noticeably lower performance
>>>than Intel's compiler for Windows? Last evidenced in Ace's Hardware's posting about Opteron SPEC performance:
>>>
>>>http://www.aceshardware.com/read_news.jsp?id=65000417
>>>
>>>I find it hard to believe that executable format and execution model wouldn't affect performance somewhat. :)
>>
>>I don't believe I claimed otherwise. I simply said that effort was made in the construction of each
>>SPEC CPU suite to minimize the effect of OS/library related cross platform differences. But there
>>are OS functions that cannot be avoided, like virtual memory management. Perhaps the VM code
>>in Windows is more efficient on the target machine than Linux's.
>>
>
Vincent Diepeveen (diep@xs4all.nl) on 6/22/03 wrote:
---------------------------
>In short we can definitely say that there is performance differences, but usually
>good programmers can optimize very well and get around it.
>
>But to give some examples:
>
>example a) you run 4 processes at a single cpu and they are mutually locking.
>
>In windows you implement it for example with the well known WaitForSingleObject()/WaitForMultipleObject().
>
>In Linux you lock as it has no WaitForSingleObject().
>
>In IRIX you also lock using spin_lock().
>
>Then you measure performance and linux is tens of times slower than both the other OSes.
>
>It appears then that both IRIX and windows are first trying to lock the object
>a few times in a row without putting a process into the runqueue. So if such an
>object is released within say 600 ns then the processes can run on.
>
>However under linux there is no such function for multiprocessing, so each process
>gets in the runqueue which means a 10ms latency each time, which is pretty much slower than < 600 ns :)
>
>Trivially some good programming can speedup the software at all the OSes a lot.
>
>Paul DeMone (pdemone@igs.net) on 6/22/03 wrote:
>---------------------------
>>Anonymous (nn@nn.invalid) on 6/22/03 wrote:
>>---------------------------
>>>Paul DeMone (pdemone@igs.net) on 6/20/03 wrote:
>>>---------------------------
>>>>The SPEC CPU suite programs are specifically selected and sometimes even
>>>>modified to minimize the influence of differences in OS and language libraries
>>>>across platforms.
>>>
>>>Then why is e.g. Intel's compiler for Linux showing noticeably lower performance
>>>than Intel's compiler for Windows? Last evidenced in Ace's Hardware's posting about Opteron SPEC performance:
>>>
>>>http://www.aceshardware.com/read_news.jsp?id=65000417
>>>
>>>I find it hard to believe that executable format and execution model wouldn't affect performance somewhat. :)
>>
>>I don't believe I claimed otherwise. I simply said that effort was made in the construction of each
>>SPEC CPU suite to minimize the effect of OS/library related cross platform differences. But there
>>are OS functions that cannot be avoided, like virtual memory management. Perhaps the VM code
>>in Windows is more efficient on the target machine than Linux's.
>>
>
Topic | Posted By | Date |
---|---|---|
New Silicon Insider Article | David Kanter | 2003/06/17 03:39 PM |
Srockholm Syndrome | anonymous | 2003/06/17 03:50 PM |
Srockholm Syndrome | Nate Begeman | 2003/06/17 04:32 PM |
Srockholm Syndrome | anonymous | 2003/06/18 02:23 PM |
Srockholm Syndrome | Scott Robinson | 2003/06/20 08:25 AM |
New Silicon Insider Article | Bill Todd | 2003/06/17 09:51 PM |
New Silicon Insider Article | Alberto | 2003/06/18 07:29 AM |
New Silicon Insider Article | José Javier Zarate | 2003/06/18 10:16 AM |
New Silicon Insider Article | Bill Todd | 2003/06/18 03:10 PM |
New Silicon Insider Article | Nate Begeman | 2003/06/18 03:25 PM |
New Silicon Insider Article | Tvar' | 2003/06/18 03:41 PM |
New Silicon Insider Article | Alberto | 2003/06/18 03:58 PM |
New Silicon Insider Article | Tvar' | 2003/06/18 04:04 PM |
New Silicon Insider Article | Alberto | 2003/06/18 04:24 PM |
New Silicon Insider Article | Tvar' | 2003/06/18 04:32 PM |
New Silicon Insider Article | Paul DeMone | 2003/06/18 04:13 PM |
New Silicon Insider Article | Tvar' | 2003/06/18 04:23 PM |
New Silicon Insider Article | mas | 2003/06/18 04:11 PM |
New Silicon Insider Article | Alberto | 2003/06/18 03:45 PM |
New Silicon Insider Article | Bill Todd | 2003/06/18 11:46 PM |
New Silicon Insider Article | David Wang | 2003/06/19 12:13 AM |
New Silicon Insider Article | Bill Todd | 2003/06/19 01:14 AM |
New Silicon Insider Article | David Wang | 2003/06/19 10:52 AM |
New Silicon Insider Article | Paul DeMone | 2003/06/18 04:04 PM |
New Silicon Insider Article | Bill Todd | 2003/06/18 11:28 PM |
New Silicon Insider Article | Paul DeMone | 2003/06/19 12:43 AM |
New Silicon Insider Article | Rob Young | 2003/06/19 10:23 AM |
New Silicon Insider Article | Bill Todd | 2003/06/19 04:53 PM |
New Silicon Insider Article | David Wang | 2003/06/18 11:29 PM |
New Silicon Insider Article | Bill Todd | 2003/06/19 12:03 AM |
New Silicon Insider Article | José Javier Zarate | 2003/06/19 05:33 AM |
New Silicon Insider Article | mas | 2003/06/19 06:37 AM |
New Silicon Insider Article | Bill Todd | 2003/06/19 04:40 PM |
New Silicon Insider Article | David Wang | 2003/06/19 05:25 PM |
New Silicon Insider Article | Bill Todd | 2003/06/19 06:00 PM |
New Silicon Insider Article | Alberto | 2003/06/19 06:29 PM |
New Silicon Insider Article | Speedy | 2003/06/19 06:48 PM |
New Silicon Insider Article | Alberto | 2003/06/20 04:57 AM |
New Silicon Insider Article | David Wang | 2003/06/19 06:52 PM |
New Silicon Insider Article | Bill Todd | 2003/06/19 09:00 PM |
New Silicon Insider Article | Anonymous | 2003/06/20 02:20 AM |
New Silicon Insider Article | Paul DeMone | 2003/06/20 09:11 AM |
New Silicon Insider Article | Anonymous | 2003/06/22 04:48 PM |
New Silicon Insider Article | Paul DeMone | 2003/06/22 05:49 PM |
New Silicon Insider Article | Vincent Diepeveen | 2003/06/22 06:25 PM |
New Silicon Insider Article | José Javier Zarate | 2003/06/22 07:55 PM |
New Silicon Insider Article | Anonymous | 2003/06/23 09:59 AM |
New Silicon Insider Article | Paul DeMone | 2003/06/19 07:53 PM |
New Silicon Insider Article | Bill Todd | 2003/06/19 08:53 PM |
New Silicon Insider Article | David Wang | 2003/06/19 09:08 PM |
New Silicon Insider Article | Bill Todd | 2003/06/20 02:28 AM |
New Silicon Insider Article | David Wang | 2003/06/20 11:35 AM |
New Silicon Insider Article | Paul DeMone | 2003/06/20 12:29 PM |
New Silicon Insider Article | Bill Todd | 2003/06/20 07:10 PM |
New Silicon Insider Article | Marc M. | 2003/06/21 06:06 AM |
New Silicon Insider Article | Bill Todd | 2003/06/21 12:07 PM |
New Silicon Insider Article | Bill Todd | 2003/06/20 07:01 PM |
New Silicon Insider Article | David Wang | 2003/06/20 07:52 PM |
New Silicon Insider Article | Bill Todd | 2003/06/20 08:53 PM |
New Silicon Insider Article | David Wang | 2003/06/20 09:14 PM |
New Silicon Insider Article | Vincent Diepeveen | 2003/06/20 09:52 PM |
New Silicon Insider Article | Marc M. | 2003/06/21 08:16 AM |
New Silicon Insider Article | Vincent Diepeveen | 2003/06/22 05:24 PM |
New Silicon Insider Article | Singh, S.R. | 2003/06/21 04:39 AM |
New Silicon Insider Article | David Wang | 2003/06/21 09:10 AM |
IPF Compilers | Nate Begeman | 2003/06/21 10:10 AM |
IPF Compilers | Paul DeMone | 2003/06/21 10:45 AM |
Use ILP to extract more ILP | Paul DeMone | 2003/06/20 11:48 PM |
New Silicon Insider Article | Paul DeMone | 2003/06/20 09:06 AM |
New Silicon Insider Article | Singh, S.R. | 2003/06/20 10:41 AM |
New Silicon Insider Article | David Kanter | 2003/06/21 04:34 PM |
New Silicon Insider Article | Paul DeMone | 2003/06/22 03:22 PM |
New Silicon Insider Article | Bill Todd | 2003/06/20 06:52 PM |
New Silicon Insider Article | Marc M. | 2003/06/21 08:54 AM |
New Silicon Insider Article | Daniel Gustafsson | 2003/06/19 12:12 PM |
New Silicon Insider Article | Paul DeMone | 2003/06/20 03:20 PM |
New Silicon Insider Article | Bryan Gregory | 2003/06/20 02:14 PM |
New Silicon Insider Article | mas | 2003/06/20 02:43 PM |
New Silicon Insider Article | Paul DeMone | 2003/06/25 11:29 AM |
New Silicon Insider Article | José Javier Zarate | 2003/06/25 11:43 AM |
New Silicon Insider Article | Paul DeMone | 2003/06/25 11:52 AM |
lol, amazing coincidence :-) (NT) | mas | 2003/06/25 04:15 PM |
New Silicon Insider Article | Yoav | 2015/04/01 04:43 AM |