Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #130054 > unrolled thread
| Started by | Lynn McGuire <lynnmcguire5@gmail.com> |
|---|---|
| First post | 2018-05-02 16:21 -0500 |
| Last post | 2018-05-04 14:37 +0200 |
| Articles | 13 on this page of 73 — 19 participants |
Back to article view | Back to comp.lang.c
"C Is Not a Low-level Language" Lynn McGuire <lynnmcguire5@gmail.com> - 2018-05-02 16:21 -0500
"C Is Not a Low-level Language" Chad <cdalten@gmail.com> - 2018-05-02 16:35 -0700
Re: "C Is Not a Low-level Language" bartc <bc@freeuk.com> - 2018-05-03 02:07 +0100
Re: "C Is Not a Low-level Language" 1alvinalbrecht1@gmail.com - 2018-05-02 21:48 -0700
Re: "C Is Not a Low-level Language" Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-05-03 02:14 -0700
Re: "C Is Not a Low-level Language" David Brown <david.brown@hesbynett.no> - 2018-05-04 10:45 +0200
Re: "C Is Not a Low-level Language" Steven Petruzzellis <frelwizzen@gmail.com> - 2018-05-04 02:15 -0700
Re: "C Is Not a Low-level Language" David Brown <david.brown@hesbynett.no> - 2018-05-04 10:14 +0200
Re: "C Is Not a Low-level Language" supercat@casperkitty.com - 2018-05-04 08:12 -0700
Re: "C Is Not a Low-level Language" David Brown <david.brown@hesbynett.no> - 2018-05-06 21:18 +0200
Re: "C Is Not a Low-level Language" supercat@casperkitty.com - 2018-05-06 15:44 -0700
Re: "C Is Not a Low-level Language" Richard Damon <Richard@Damon-Family.org> - 2018-05-06 19:45 -0400
Re: "C Is Not a Low-level Language" supercat@casperkitty.com - 2018-05-07 09:47 -0700
Re: "C Is Not a Low-level Language" Steve Carroll <frelwizzen@gmail.com> - 2018-05-07 13:15 -0700
Re: "C Is Not a Low-level Language" Richard Damon <Richard@Damon-Family.org> - 2018-05-07 22:03 -0400
Re: "C Is Not a Low-level Language" supercat@casperkitty.com - 2018-05-08 06:46 -0700
Re: "C Is Not a Low-level Language" Richard Damon <Richard@Damon-Family.org> - 2018-05-08 20:59 -0400
Re: "C Is Not a Low-level Language" supercat@casperkitty.com - 2018-05-09 10:03 -0700
Re: "C Is Not a Low-level Language" Steve Carroll <frelwizzen@gmail.com> - 2018-05-09 10:57 -0700
Re: "C Is Not a Low-level Language" supercat@casperkitty.com - 2018-05-08 07:58 -0700
Re: "C Is Not a Low-level Language" Tim Rentsch <txr@alumni.caltech.edu> - 2018-05-18 20:18 -0700
Re: "C Is Not a Low-level Language" supercat@casperkitty.com - 2018-05-19 15:49 -0700
Re: "C Is Not a Low-level Language" Steve Carroll <frelwizzen@gmail.com> - 2018-05-07 05:58 -0700
Re: "C Is Not a Low-level Language" bartc <bc@freeuk.com> - 2018-05-03 10:58 +0100
Some course material (was Re: "C Is Not a Low-level Language") Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-05-03 14:41 +0000
Re: Some course material (was Re: "C Is Not a Low-level Language") bartc <bc@freeuk.com> - 2018-05-03 16:02 +0100
Re: Some course material (was Re: "C Is Not a Low-level Language") Steven Petruzzellis <frelwizzen@gmail.com> - 2018-05-03 10:25 -0700
Re: "C Is Not a Low-level Language" Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-05-03 09:17 -0700
Re: "C Is Not a Low-level Language" bartc <bc@freeuk.com> - 2018-05-03 17:39 +0100
Re: "C Is Not a Low-level Language" Wouter Verhelst <w@uter.be> - 2018-05-04 11:40 +0200
Re: "C Is Not a Low-level Language" bartc <bc@freeuk.com> - 2018-05-04 10:59 +0100
Re: "C Is Not a Low-level Language" Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-05-04 03:18 -0700
Re: "C Is Not a Low-level Language" scott@slp53.sl.home (Scott Lurndal) - 2018-05-04 14:59 +0000
Re: "C Is Not a Low-level Language" supercat@casperkitty.com - 2018-05-04 08:57 -0700
Re: "C Is Not a Low-level Language" David Brown <david.brown@hesbynett.no> - 2018-05-06 23:24 +0200
Re: "C Is Not a Low-level Language" Robert Wessel <robertwessel2@yahoo.com> - 2018-05-07 12:27 -0500
Re: "C Is Not a Low-level Language" Robert Wessel <robertwessel2@yahoo.com> - 2018-05-04 11:15 -0500
Re: "C Is Not a Low-level Language" Wouter Verhelst <w@uter.be> - 2018-05-04 18:13 +0200
Re: "C Is Not a Low-level Language" Robert Wessel <robertwessel2@yahoo.com> - 2018-05-04 11:45 -0500
Re: "C Is Not a Low-level Language" scott@slp53.sl.home (Scott Lurndal) - 2018-05-04 17:31 +0000
Re: "C Is Not a Low-level Language" already5chosen@yahoo.com - 2018-05-05 11:10 -0700
Re: "C Is Not a Low-level Language" Wouter Verhelst <w@uter.be> - 2018-05-05 11:48 +0200
Re: "C Is Not a Low-level Language" Steve Carroll <frelwizzen@gmail.com> - 2018-05-07 17:57 -0700
Re: "C Is Not a Low-level Language" Steve Carroll <frelwizzen@gmail.com> - 2018-05-08 00:11 -0700
Re: "C Is Not a Low-level Language" David Brown <david.brown@hesbynett.no> - 2018-05-06 23:28 +0200
Re: "C Is Not a Low-level Language" already5chosen@yahoo.com - 2018-05-06 15:48 -0700
Re: "C Is Not a Low-level Language" Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-05-08 20:01 +0000
Re: "C Is Not a Low-level Language" already5chosen@yahoo.com - 2018-05-08 13:20 -0700
Re: "C Is Not a Low-level Language" scott@slp53.sl.home (Scott Lurndal) - 2018-05-08 20:34 +0000
Re: "C Is Not a Low-level Language" Steve Carroll <frelwizzen@gmail.com> - 2018-05-09 06:15 -0700
Re: "C Is Not a Low-level Language" Wouter Verhelst <w@uter.be> - 2018-05-08 02:12 +0200
Re: "C Is Not a Low-level Language" Dan Purgert <dan@djph.net> - 2018-05-04 10:42 +0000
Re: "C Is Not a Low-level Language" David Brown <david.brown@hesbynett.no> - 2018-05-04 13:44 +0200
Re: "C Is Not a Low-level Language" Wouter Verhelst <w@uter.be> - 2018-05-04 18:11 +0200
Re: "C Is Not a Low-level Language" bartc <bc@freeuk.com> - 2018-05-04 17:47 +0100
Re: "C Is Not a Low-level Language" Keith Thompson <kst-u@mib.org> - 2018-05-04 10:57 -0700
Re: "C Is Not a Low-level Language" Wouter Verhelst <w@uter.be> - 2018-05-05 14:57 +0200
Re: "C Is Not a Low-level Language" Ian Collins <ian-news@hotmail.com> - 2018-05-04 15:05 +1200
Re: "C Is Not a Low-level Language" bartc <bc@freeuk.com> - 2018-05-04 10:01 +0100
Re: "C Is Not a Low-level Language" David Brown <david.brown@hesbynett.no> - 2018-05-04 13:51 +0200
Re: "C Is Not a Low-level Language" bartc <bc@freeuk.com> - 2018-05-04 13:14 +0100
Re: "C Is Not a Low-level Language" David Brown <david.brown@hesbynett.no> - 2018-05-04 15:19 +0200
Re: "C Is Not a Low-level Language" bartc <bc@freeuk.com> - 2018-05-04 14:38 +0100
Re: "C Is Not a Low-level Language" Dan Purgert <dan@djph.net> - 2018-05-04 13:56 +0000
Re: "C Is Not a Low-level Language" David Brown <david.brown@hesbynett.no> - 2018-05-04 16:24 +0200
Re: "C Is Not a Low-level Language" already5chosen@yahoo.com - 2018-05-04 07:36 -0700
Re: "C Is Not a Low-level Language" already5chosen@yahoo.com - 2018-05-04 06:01 -0700
Re: "C Is Not a Low-level Language" scott@slp53.sl.home (Scott Lurndal) - 2018-05-04 14:57 +0000
Re: "C Is Not a Low-level Language" Ian Collins <ian-news@hotmail.com> - 2018-05-05 06:49 +1200
Re: "C Is Not a Low-level Language" already5chosen@yahoo.com - 2018-05-05 10:55 -0700
Re: "C Is Not a Low-level Language" David Brown <david.brown@hesbynett.no> - 2018-05-04 10:10 +0200
Re: "C Is Not a Low-level Language" already5chosen@yahoo.com - 2018-05-04 04:51 -0700
Re: "C Is Not a Low-level Language" David Brown <david.brown@hesbynett.no> - 2018-05-04 14:37 +0200
Page 4 of 4 — ← Prev page 1 2 3 [4]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-05-04 13:14 +0100 |
| Message-ID | <K8YGC.117546$uL.12634@fx15.am4> |
| In reply to | #130145 |
On 04/05/2018 12:51, David Brown wrote: > On 04/05/18 11:01, bartc wrote: >> On 04/05/2018 04:05, Ian Collins wrote: >>> The course is HPC, no one does HPC on Windows! >> >> >> But it could be done? I mean if Windows runs on the same processor as >> the Linux machine, what is different? >> > > Desktop Windows does not run on the same hardware as Linux for HPC. Big > Windows servers might run on hardware with multiple sockets, but you are > surely not expecting students to have these massively expensive Windows > licenses? This is about doing coursework. So a student's Linux netbook is OK, but a Windows netbook running the same hardware isn't? Or is the coursework expected to be done on a super-computer? > Linux has the support for clustering, for fast networking, > for distributed file systems, for remote memory access, for process > migrations, for non-uniform memory architectures, for hierarchies of > processor cores, connections, and virtual cores, and everything else > needed for high-performance computing on massively parallel systems. > Windows does not - not even the biggest and most expensive server > versions (which have a good deal more than the desktop versions). > Linux > supports multiple cpu architectures (MIPS and PPC are also popular in > HPC, and other cores are sometimes used) - Windows does not. Wow, you know how to put the boot in, don't you? I've no idea what any of those buzz-words mean, but you clearly know what you're talking about as you say it so confidently, so it must all be true. What exactly is the intention here, to make me crawl away with my tail between my legs clutching my sad little Windows machine with its paltry two cores, feeling incredibly small? But apparently, this is what you do. All my meagre experience tells me about Linux is that takes 1-2 minutes to boot it from flash-drive, on a 0.7GHz 500MB 32-bit ARM (as used on early Raspberry Pi), compared with the 1.5 seconds it took to load up our CP/M clone from floppy on a 0.004GHz 0.062MB 8-bit Z80. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-05-04 15:19 +0200 |
| Message-ID | <pchmlh$ti0$1@dont-email.me> |
| In reply to | #130148 |
On 04/05/18 14:14, bartc wrote: > On 04/05/2018 12:51, David Brown wrote: >> On 04/05/18 11:01, bartc wrote: >>> On 04/05/2018 04:05, Ian Collins wrote: >>>> The course is HPC, no one does HPC on Windows! >>> >>> >>> But it could be done? I mean if Windows runs on the same processor as >>> the Linux machine, what is different? >>> >> >> Desktop Windows does not run on the same hardware as Linux for HPC. Big >> Windows servers might run on hardware with multiple sockets, but you are >> surely not expecting students to have these massively expensive Windows >> licenses? > > This is about doing coursework. > > So a student's Linux netbook is OK, but a Windows netbook running the > same hardware isn't? > > Or is the coursework expected to be done on a super-computer? I have no idea how much coursework is expected to be tested on HPC machines rather than just the student's computer. I'd expect at least some of it will - and those HPC machines will be running Linux. > >> Linux has the support for clustering, for fast networking, >> for distributed file systems, for remote memory access, for process >> migrations, for non-uniform memory architectures, for hierarchies of >> processor cores, connections, and virtual cores, and everything else >> needed for high-performance computing on massively parallel systems. >> Windows does not - not even the biggest and most expensive server >> versions (which have a good deal more than the desktop versions). >> Linux >> supports multiple cpu architectures (MIPS and PPC are also popular in >> HPC, and other cores are sometimes used) - Windows does not. > > Wow, you know how to put the boot in, don't you? > > I've no idea what any of those buzz-words mean, but you clearly know > what you're talking about as you say it so confidently, so it must all > be true. I know a bit about HPC - but only in theory, not practice. Still, I know enough to give some of the reasons why in the current TOP500 list, /all/ of the systems run Linux, and Windows has never been above 1% share. (Cost is another reason, of course.) That does not mean that Windows is /never/ used in HPC - merely that it has an absolutely tiny market share. > > What exactly is the intention here, to make me crawl away with my tail > between my legs clutching my sad little Windows machine with its paltry > two cores, feeling incredibly small? No, I am merely trying to help you understand why a teacher on an HPC course would insist on coursework suitable for Linux, and consider Windows irrelevant. Since Windows is so totally irrelevant in this market, students would be expected to use Linux methods, APIs, libraries, etc., for handling networking, inter-process communication, memory management, process and thread handling, and so on. It would be pointless to try to look at Windows equivalents or even cross-platform abstractions. There are plenty of other areas where Windows dominates (and some where Macs dominate, and some for other uses). Someone teaching a course on games programming might reasonably insist that coursework be made for Windows and not Linux, for example. I am perfectly happy to use Windows when Windows is the most appropriate system for the task in hand - I use Windows /and/ Linux, with two machines in my office. But HPC is perhaps the most extreme example of where Linux is far more appropriate than Windows. > > But apparently, this is what you do. > > All my meagre experience tells me about Linux is that takes 1-2 minutes > to boot it from flash-drive, on a 0.7GHz 500MB 32-bit ARM (as used on > early Raspberry Pi), compared with the 1.5 seconds it took to load up > our CP/M clone from floppy on a 0.004GHz 0.062MB 8-bit Z80. > That is as helpful as noting the tricycle I had when I was 5 weighs a lot less than the car I have now. I have seen Linux systems that boot in a couple of seconds (to the point where they start looking for DHCP leases). And I've seen Windows systems that take 15 minutes to boot. So what? I could equally well give examples of fast Windows booting and slow Linux booting.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-05-04 14:38 +0100 |
| Message-ID | <ZmZGC.90269$EL2.33897@fx37.am4> |
| In reply to | #130158 |
On 04/05/2018 14:19, David Brown wrote: > On 04/05/18 14:14, bartc wrote: >> I've no idea what any of those buzz-words mean, but you clearly know >> what you're talking about as you say it so confidently, so it must all >> be true. > > I know a bit about HPC - but only in theory, not practice. Still, I > know enough to give some of the reasons why in the current TOP500 list, > /all/ of the systems run Linux, and Windows has never been above 1% > share. (Cost is another reason, of course.) Another reason might be students being blackmailed into using Linux, and only Linux workstations being provided in universities. Then they wouldn't know anything else. >> All my meagre experience tells me about Linux is that takes 1-2 minutes >> to boot it from flash-drive, on a 0.7GHz 500MB 32-bit ARM (as used on >> early Raspberry Pi), compared with the 1.5 seconds it took to load up >> our CP/M clone from floppy on a 0.004GHz 0.062MB 8-bit Z80. >> > > That is as helpful as noting the tricycle I had when I was 5 weighs a > lot less than the car I have now. > > I have seen Linux systems that boot in a couple of seconds (to the point > where they start looking for DHCP leases). And I've seen Windows > systems that take 15 minutes to boot. So what? I could equally well > give examples of fast Windows booting and slow Linux booting. The menial tasks that people with consumer machines might want to do now are probably not much different from 35 years ago: write a letter, print it, do their accounts. But if you took all the stuff that modern OSes, including Windows, has to do to get started, and tried to run it on an early 80s machine, then if someone were to turn the machine on in the morning, it would still be churning away starting up by the time it came to go home. (And actually, it might still be at it a month later.) Modern OSes are /very/ heavyweight and that version of Linux on the Pi was no exception. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Dan Purgert <dan@djph.net> |
|---|---|
| Date | 2018-05-04 13:56 +0000 |
| Message-ID | <slrnpeopkt.jmn.dan@xps-linux.djph.net> |
| In reply to | #130166 |
bartc wrote: > [...] > Another reason might be students being blackmailed into using Linux, and > only Linux workstations being provided in universities. Then they > wouldn't know anything else. Yes, because by the time a person turns 18, they will have *never* seen a Windows or Apple machine before either. > [...] > The menial tasks that people with consumer machines might want to do now > are probably not much different from 35 years ago: write a letter, print > it, do their accounts. Nah, these days it's "sell all their information to Facebook." -- |_|O|_| Registered Linux user #585947 |_|_|O| Github: https://github.com/dpurgert |O|O|O| PGP: 05CA 9A50 3F2E 1335 4DC5 4AEE 8E11 DDF3 1279 A281
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-05-04 16:24 +0200 |
| Message-ID | <pchqec$mo5$1@dont-email.me> |
| In reply to | #130166 |
On 04/05/18 15:38, bartc wrote: > On 04/05/2018 14:19, David Brown wrote: >> On 04/05/18 14:14, bartc wrote: > >>> I've no idea what any of those buzz-words mean, but you clearly know >>> what you're talking about as you say it so confidently, so it must all >>> be true. >> >> I know a bit about HPC - but only in theory, not practice. Still, I >> know enough to give some of the reasons why in the current TOP500 list, >> /all/ of the systems run Linux, and Windows has never been above 1% >> share. (Cost is another reason, of course.) > > Another reason might be students being blackmailed into using Linux, and > only Linux workstations being provided in universities. Then they > wouldn't know anything else. It might have been a reason - but I really don't think so. This kind of thing certainly does happen in the software world - but it is primarily an effect of large vendors of expensive software giving extremely large discounts on student or academic versions of their software in order to get students hooked. You see it in CAD and electronic design software, in the DTP world (Adobe puts a lot of effort into this, and it is one reason for their market position), and of course MS is not shy about trying to get students hooked on their software. It is harder to argue that it is "blackmail" when the software is free. MS put a fair bit of effort into trying to make a HPC version of Windows a few years back. It never caught on. > >>> All my meagre experience tells me about Linux is that takes 1-2 minutes >>> to boot it from flash-drive, on a 0.7GHz 500MB 32-bit ARM (as used on >>> early Raspberry Pi), compared with the 1.5 seconds it took to load up >>> our CP/M clone from floppy on a 0.004GHz 0.062MB 8-bit Z80. >>> >> >> That is as helpful as noting the tricycle I had when I was 5 weighs a >> lot less than the car I have now. >> >> I have seen Linux systems that boot in a couple of seconds (to the point >> where they start looking for DHCP leases). And I've seen Windows >> systems that take 15 minutes to boot. So what? I could equally well >> give examples of fast Windows booting and slow Linux booting. > > The menial tasks that people with consumer machines might want to do now > are probably not much different from 35 years ago: write a letter, print > it, do their accounts. > > But if you took all the stuff that modern OSes, including Windows, has > to do to get started, and tried to run it on an early 80s machine, then > if someone were to turn the machine on in the morning, it would still be > churning away starting up by the time it came to go home. > > (And actually, it might still be at it a month later.) I've seen reports of people using an 8-bit AVR running an emulator of an ARM to boot Linux - taking several hours to do so, but not a month. Until about 8-10 years ago, one of our servers was running Linux on a 66 MHz Pentium with 64 MB ram. It was not a fast server by any means, but was fine for a file server for rarely used "archive" files. It is still quite possible to do a lot of work with little hardware. > > Modern OSes are /very/ heavyweight and that version of Linux on the Pi > was no exception. > The original Pi has always been too slow to be very usable as a desktop or interactive machine (with desktop software current with the device). The Pi 3 is far more practical for that kind of thing. But the original Pi is absolutely fine for control applications, server work, etc., as long as you don't want a gui on it. But Wirth's law seems unbreakable - software gets slower faster than hardware gets faster.
[toc] | [prev] | [next] | [standalone]
| From | already5chosen@yahoo.com |
|---|---|
| Date | 2018-05-04 07:36 -0700 |
| Message-ID | <2c76bd73-0186-4e7d-a4c7-de5a32c0047e@googlegroups.com> |
| In reply to | #130158 |
On Friday, May 4, 2018 at 4:19:55 PM UTC+3, David Brown wrote: > On 04/05/18 14:14, bartc wrote: > > > > But apparently, this is what you do. > > > > All my meagre experience tells me about Linux is that takes 1-2 minutes > > to boot it from flash-drive, on a 0.7GHz 500MB 32-bit ARM (as used on > > early Raspberry Pi), compared with the 1.5 seconds it took to load up > > our CP/M clone from floppy on a 0.004GHz 0.062MB 8-bit Z80. > > > > That is as helpful as noting the tricycle I had when I was 5 weighs a > lot less than the car I have now. > Comparison of the times from approaching the vehicle to the first motion of the wheels would be better analogy. Tricycle still wins over family car, but by far smaller ratio. Instant vs 5 seconds looks like a fare cost for additional capabilities of modern OSes vs CPM. Instant vs 2 minutes - much less so. And 2 minutes is close to my own experience of booting Linux on dual-core ARM Cortex A9 in Xilinx Zync evaluation suite. I don't know why it's was so slower, got it preinstalled, I don't know if it has to be so slow. But I know that it is slow. I also know that rebooting my Android tablet (also based on Linux kernel, as far as I heard) is similarly slow. > I have seen Linux systems that boot in a couple of seconds (to the point > where they start looking for DHCP leases). And I've seen Windows > systems that take 15 minutes to boot. So what? I could equally well > give examples of fast Windows booting and slow Linux booting. Both bloated pigs.
[toc] | [prev] | [next] | [standalone]
| From | already5chosen@yahoo.com |
|---|---|
| Date | 2018-05-04 06:01 -0700 |
| Message-ID | <118b8e65-9eac-4a2b-bb51-643c3c84de7b@googlegroups.com> |
| In reply to | #130145 |
On Friday, May 4, 2018 at 2:51:41 PM UTC+3, David Brown wrote: > On 04/05/18 11:01, bartc wrote: > > On 04/05/2018 04:05, Ian Collins wrote: > >> The course is HPC, no one does HPC on Windows! > > > > > > But it could be done? I mean if Windows runs on the same processor as > > the Linux machine, what is different? > > > > Desktop Windows does not run on the same hardware as Linux for HPC. Big > Windows servers might run on hardware with multiple sockets, but you are > surely not expecting students to have these massively expensive Windows > licenses? Linux has the support for clustering, for fast networking, > for distributed file systems, for remote memory access, for process > migrations, for non-uniform memory architectures, for hierarchies of > processor cores, connections, and virtual cores, and everything else > needed for high-performance computing on massively parallel systems. > Windows does not - not even the biggest and most expensive server > versions (which have a good deal more than the desktop versions). Most of the points above a factually incorrect. Just one example: http://www.mellanox.com/related-docs/prod_adapter_cards/PB_ConnectX-6_VPI_Card.pdf Pay attention to the Operating Systems section. The truth is that Windows is non-popular in HPC, but no OS except Linux is really popular, Even Fujitsu HPC-oriented supercomputers based on their SPARC chips are shipped with Linux rather than Solaris. Microsoft wanted to get into HPC and even created a special, lower priced, editions of WS for that purpose - Windows compute clusters server 2003, then Windows HPC Server 2008. Both had very limited success. WS2012 has no special edition for HPC. Wikipedia says that "HPC Pack 2012" can be installed on top of either Standard Edition or Enterprise Edition. I would guess that the combo wouldn't be as cheap as it was with HPC editions of previous generations. I would also guess that sufficiently determined person could slap together relatively cheap Windows HPC cluster solution consisting of Windows Server 2012 Essentials edition plus bits end pieces of Microsoft freeware plus 3rd parties freeware plus freeware from hardware vendors, like above mentioned Mellanox, Intel and, may be, NVidia. The question is, why bother? > Linux > supports multiple cpu architectures (MIPS and PPC are also popular in > HPC, and other cores are sometimes used) - Windows does not. Ironically, the two architectures that you mentioned we supported by Windows in the distant past. Not today. > > > My own machine is normally 99% idle, but I can easily run two programs > > on the two cores so that 100% of CPU is used up. In what way is Windows > > interfering with the work done there? > > Two processes on two cores is not HPC. > AMD ThreadRipper (16 cores, 32 threads) is not really expensive. Still, probably a bit too expensive for an average student, unless he has other (than participation in HPC curse) reasons to want it.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2018-05-04 14:57 +0000 |
| Message-ID | <gx_GC.112354$br4.28021@fx34.iad> |
| In reply to | #130122 |
bartc <bc@freeuk.com> writes: >On 04/05/2018 04:05, Ian Collins wrote: >> On 05/03/2018 09:58 PM, bartc wrote: >>> >>> Not connected with the subject but I found this quote interesting from >>> this HPC coursework site of the author's: >>> >>> http://www.cs.swan.ac.uk/~csdavec/HPC/ >>> >>> ------------------------------- >>> "Note For Windows Users >>> >>> If you are trying to do the coursework on Windows, you are making life >>> very difficult for yourself. All code submissions are expected to work >>> on the Linux lab machines. At the very least, you should test your code >>> there. >>> >>> If you insist on working on Windows, then I suggest that you either >>> install Cygwin, which gives a vaguely UNIX-like environment for Windows. >>> Alternatively, use PuTTY to connect remotely to the Linux lab machines. >>> >>> Any coursework that contains Windowsisms and does not work on the Linux >>> lab machines will be considered non-working, even if it works on >>> Windows." >>> ------------------------------- >>> >>> This is a bit rich considering that elsewhere he mentions this problem >>> with the Linux shell: >> >> The course is HPC, no one does HPC on Windows! > > >But it could be done? I mean if Windows runs on the same processor as >the Linux machine, what is different? The operating system, obviously. Which provides the API's used by the various HPC applications, most of which are written around originally unix libraries like MPI, PVM and openMP.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2018-05-05 06:49 +1200 |
| Message-ID | <fl3o8uFslrfU1@mid.individual.net> |
| In reply to | #130122 |
On 05/04/2018 09:01 PM, bartc wrote: > On 04/05/2018 04:05, Ian Collins wrote: >> On 05/03/2018 09:58 PM, bartc wrote: >>> >>> Not connected with the subject but I found this quote interesting from >>> this HPC coursework site of the author's: >>> >>> http://www.cs.swan.ac.uk/~csdavec/HPC/ >>> >>> ------------------------------- >>> "Note For Windows Users >>> >>> If you are trying to do the coursework on Windows, you are making life >>> very difficult for yourself. All code submissions are expected to work >>> on the Linux lab machines. At the very least, you should test your code >>> there. >>> >>> If you insist on working on Windows, then I suggest that you either >>> install Cygwin, which gives a vaguely UNIX-like environment for Windows. >>> Alternatively, use PuTTY to connect remotely to the Linux lab machines. >>> >>> Any coursework that contains Windowsisms and does not work on the Linux >>> lab machines will be considered non-working, even if it works on >>> Windows." >>> ------------------------------- >>> >>> This is a bit rich considering that elsewhere he mentions this problem >>> with the Linux shell: >> >> The course is HPC, no one does HPC on Windows! > > > But it could be done? I mean if Windows runs on the same processor as > the Linux machine, what is different? It depends what they are doing. The main reason (other than cost) you don't see Windows in the HPC space is its kernel doesn't scale and being closed source, you can't modify it to make it do so. -- Ian.
[toc] | [prev] | [next] | [standalone]
| From | already5chosen@yahoo.com |
|---|---|
| Date | 2018-05-05 10:55 -0700 |
| Message-ID | <0c148ab7-2331-48b1-9a1c-5c38e8424eac@googlegroups.com> |
| In reply to | #130207 |
On Friday, May 4, 2018 at 9:49:12 PM UTC+3, Ian Collins wrote: > > It depends what they are doing. The main reason (other than cost) you > don't see Windows in the HPC space is its kernel doesn't scale and being > closed source, you can't modify it to make it do so. > > -- > Ian. Huge amount of cores in the single system is rather atypical in HPC world, for two reasons: 1. It is not cost effective 2. Main memory bandwidth to FLOPS ratio is lower than what is considered optimal for HPC workloads. For last 15-20 years the most popular size of HPC node is dual-socket. For now, most typically with 8-14 cores per socket, so 16-28 cores per system. Windows kernel scales to such moderate number of cores just fine. If all 3rd-party drives scale as well is another question, but drivers for HPC-oriented hardware likely do. Of course, there are outliers in HPC world, most notable of which is SGI Altix UV machines (now owned by HP and renamed to HPE Integrity MC990 X) with up to 768 cores. Here Linux is the only option. But they are outliers, with market share probably well below 1%.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-05-04 10:10 +0200 |
| Message-ID | <pch4hk$9ip$1@dont-email.me> |
| In reply to | #130061 |
On 03/05/18 03:07, bartc wrote: > On 02/05/2018 22:21, Lynn McGuire wrote: >> "C Is Not a Low-level Language" >> https://queue.acm.org/detail.cfm?id=3212479 >> >> "Your computer is not a fast PDP-11." >> >> Sigh, another proponent of "C sucks". > > I didn't get that impression. The author apparently is involved with > compilers and teaches HPC using C. > > One quote that struck me was this: > > "In summary, it is possible to make C code run quickly but only by > spending thousands of person-years building a sufficiently smart > compiler—and even then, only if you violate some of the language rules." > > (I think he might be exaggerating.) Yes, it is exaggeration. But it is certainly the case that in the C world, it is considered reasonable for compiler developers to spend a lot of effort so that compiler /users/ don't have to. Thus C compilers need to put a great deal of effort into auto-vectorising code precisely so that C /programmers/ can get the speed advantages of modern processors without having to hand-write vector code all the time. (Can you imagine the "joys" of hand writing your code to work with SIMD instructions 4 units wide on some machines, 8 units wide on other machines, but no SIMD on a different one? For some code, yes, it is worth the effort - but for most you are better off letting the compiler do the donkey work.) This is because - as the author says in the title but confuses in the article - C is /not/ a low level language. It is lower level than many languages, but it is not anything close to an assembly level. You /can/ use C to write close-to-the-metal code, often with implementation-specific features - but you can also use it to write portable and abstract code. Both uses are common practice. Certainly C is not the best language for all uses. As the author points out, Fortran is still popular for some kinds of high performance work - often thanks to that language's assumption that pointer parameters to a function do not alias each other. Oddly, while complaining that fast C requires complex and advanced compilers, the author fails to note that pretty much every top-class Fortran compiler is also a top-class C compiler (gcc, llvm, Intel, Pathscale, Sun, etc.), and Fortran code relies on the optimisations just as much as C. Some of his points about cpus being designed to be fast for C are true - but most aspects here also make the cpus fast for other compiled languages. (And the "register rename engine" which he rightly calls a cost in power and die area is mainly a requirement of binary backwards compatibility in the x86 world - high register count RISC processors don't have them, and they are not required in any way for C.) But it is certainly the case that C is not a language well-suited to some of the kinds of architecture that are possible, and that can be very efficient for some tasks. C, and "C-friendly" cpus, are good for general purpose computing but no one would imagine that they are the best choices for all tasks. > > It goes on: > > "Compiler writers let C programmers pretend that they are writing code > that is "close to the metal" but must then generate machine code that > has very different behaviour if they want C programmers to keep > believing that they are using a fast language." > > which I think is pretty much what I was saying (to David Brown IIRC) the > other day. > I am not sure I remember you saying that. C lets me write code that is close to the metal when I want to write such code, and it lets me write more abstract code at other times (while still generating fast object code). For my embedded work, that's what I want. For PC work, I mostly prefer a higher level language with less concern for speed. And if I wanted to work with massively parallel code, I might pick a different language again, as I would if I were interested in provably correct code (Erlang was mentioned by the author, and would make more sense for such uses).
[toc] | [prev] | [next] | [standalone]
| From | already5chosen@yahoo.com |
|---|---|
| Date | 2018-05-04 04:51 -0700 |
| Message-ID | <4ed7c06d-9608-4b04-a601-9d1bfae1c7b0@googlegroups.com> |
| In reply to | #130119 |
On Friday, May 4, 2018 at 11:10:50 AM UTC+3, David Brown wrote: > > Some of his points about cpus being designed to be fast for C are true - > but most aspects here also make the cpus fast for other compiled > languages. (And the "register rename engine" which he rightly calls a > cost in power and die area is mainly a requirement of binary backwards > compatibility in the x86 world - high register count RISC processors > don't have them, and they are not required in any way for C.) > Why do you feel oblidged to comment on things that you have no slightest idea about? MIPS R1000 and derivatives have no "register rename engine"? HP PA-8000 and derivatives have no "register rename engine"? DEC Alpha 21264 and 21364 have no "register rename engine"? IBM Power from 3 to 9, excluding 6 have no "register rename engine"? Fujitsu SPARC64 from V to XII have no "register rename engine"? Apple A cores starting from Typhoon have no "register rename engine"? ARM Cortex A57/A72 series and A73/A75 series have no "register rename engine"? The answer is "No, all of above have it". And unless you don't know (which sounds unlikely) all above mentioned architectures feature at least 32 programmer-visible general-purpose registers.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-05-04 14:37 +0200 |
| Message-ID | <pchk5d$d5t$1@dont-email.me> |
| In reply to | #130144 |
On 04/05/18 13:51, already5chosen@yahoo.com wrote: > On Friday, May 4, 2018 at 11:10:50 AM UTC+3, David Brown wrote: >> >> Some of his points about cpus being designed to be fast for C are true - >> but most aspects here also make the cpus fast for other compiled >> languages. (And the "register rename engine" which he rightly calls a >> cost in power and die area is mainly a requirement of binary backwards >> compatibility in the x86 world - high register count RISC processors >> don't have them, and they are not required in any way for C.) >> > > Why do you feel oblidged to comment on things that you have no > slightest idea about? > > MIPS R1000 and derivatives have no "register rename engine"? > HP PA-8000 and derivatives have no "register rename engine"? > DEC Alpha 21264 and 21364 have no "register rename engine"? > IBM Power from 3 to 9, excluding 6 have no "register rename engine"? > Fujitsu SPARC64 from V to XII have no "register rename engine"? > Apple A cores starting from Typhoon have no "register rename engine"? > ARM Cortex A57/A72 series and A73/A75 series have no "register rename engine"? > > The answer is "No, all of above have it". > And unless you don't know (which sounds unlikely) all above > mentioned > architectures feature at least 32 programmer-visible general-purpose > registers. > I stand corrected here - the architectures whose details I am most familiar with are either older or simpler (the embedded ARM and PPC cores I have used most do not have register renaming). Let me just note that register renaming is not necessary for C. And the benefits (and costs) of it are unrelated to the language. It is a matter of taking a sequential instruction stream and trying to achieve instruction level parallelism and out-of-order execution (as distinct from getting parallelism from having multiple virtual cores or threads). It is particularly important when you are trying to get higher speeds while keeping binary compatibility with existing code that is written without considering scheduling or parallel execution of instructions. Secondly, register renaming is most necessary, and most costly, when handling an architecture with few registers, where much of the data passes through a bottleneck register or accumulator, or where you have a substantial proportion of operations of the form "A = A op B". On processors with lots of registers you can already run "A = B op C" and "D = E op F" in parallel without register renaming - and compilers understand that and pick registers appropriately. (But yes, once you are trying to do more out-of-order or superscaler execution then even 32 registers gets limited.)
[toc] | [prev] | [standalone]
Page 4 of 4 — ← Prev page 1 2 3 [4]
Back to top | Article view | comp.lang.c
csiph-web