What happened to computer architecture (and comp.arch?)
|
Prev: VMWare tools killed my Mac OS X ?
Next: Software vs hardware floating-point [was Re: What happened ...]
From: Jeremy Linton on 2 Oct 2009 16:56 nmm1(a)cam.ac.uk wrote: > In article <ha5bdk$e07$1(a)aioe.org>, > Jeremy Linton <reply-to-list(a)nospam.org> wrote: >> Isn't that the fundamental issue here? Given a multiprocess VM with >> deterministic behavior against a virtual clock. Within the granularity >> of that virtual clock, the algorithm would work. > > You're still thinking serially :-( I think that was my point, and the reason I was using the term virtual clock. The idea was that it was really global, and everyone referencing it was lock stepped to it. The virtual clock wouldn't have any relationship to a real one.
From: "Andy "Krazy" Glew" on 2 Oct 2009 23:30 Andy "Krazy" Glew wrote: > Robert Myers wrote: > So long as, when you do not need the security, you pay as close to > nothing as possible - then I am happy. If you have dedicated hardware, > you can't remove it, but you can clock gate it. By the way: if you have a hunk of reconfigurable logic, e.g. near the ALUs, then when you are not using it it is *STILL* slowing you down - because it is consuming power through static leakage, even though it may be clock gated or sleep transistored. The only way is is not slwoing you down is if it can be power gated. I.e. if it can be on a separate power plane. At the moment, power planing is done in units of 1 big CPU, or several small CPUs. I.e. a small chunk of reconfigurable logic wll slow you down.
From: "Andy "Krazy" Glew" on 2 Oct 2009 23:33 Mayan Moudgill wrote: > Andy "Krazy" Glew wrote: > >> Myself, I refer people to the HardBound and SoftBound papers, that >> quotes a much lower than 2x performance cost. More like 1.15x. I >> think that is a reasonable tradeoff. >> > > Data point: PL.8 had dynamic checking of all array bounds. I have two > numbers stuck in my head, I don't know which one is correct: 1-2% and > less than 8%. This was on mid-90s hardware, but I expect the results > will hold. Either way, its less that the 15% you're quoting. Cool. I do not know why HardBound and SoftBound report numbers in the 15% range. It could be different benchmarks. It could be that they are doing it for C and C++ (even though Nick says it is incorrect to do so). One big annoyance of C and C++ is that they do not distinguish pointer to scalar of type T from a pointer to array element of type T. I believe this introduces many unnecessary checks within functions called with a pointer argument, rather than outside.
From: Morten Reistad on 4 Oct 2009 05:29 In article <7iknkoF31ud7sU1(a)mid.individual.net>, Andrew Reilly <andrew-newspost(a)areilly.bpc-users.org> wrote: >On Thu, 01 Oct 2009 13:12:46 -0700, Robert Myers wrote: > >> Interest in hot new implementations of virtual machines never seems to >> have been higher--but apparently they may all be irrelevant in a future >> of hundreds of cores. > >How is that conclusion apparent? There aren't that many computers around >with hundreds of cores, and those that are aren't being programmed in VM- >based languages, for the most part, so it wouldn't be surprising if the >level of tuning that's gone into (for example) OSes and database systems >hasn't been done yet, or to that scale. I don't see how that can imply >that it isn't possible. Speaking of which, are there any firm figures of letting Linux, BSDs, Inix, Solaris etc through the hoops on an upper three digit processor machine with intependent load processes where the OS has to do the MP handlig; e.g. socket, pipe, semaphores in monolithic processes? I am looking for figures on OS performance itself, not user space. The reason I am asking is that I have been involved in a lot of testing of application performance lately, and it seems to me we are measuring the performance of BSD and Linux, not the application itself. >There are (some) java benchmarks, and to the extent that they're relevant >and commercially important (I don't know) I would expect that tuning >would follow, or perhaps even be underway. > >Most of the *languages* (or the committees that steer them and the >communities that use them) that I know about are only *just* starting to >think about how best to express and make use of genuine concurrency. Up >until now concurrency has been the domain of individual applications and >non-core libraries (and OSes) (with a few notable but not terribly >popular exceptions, like Occam and erlang). There are *still* blogs and >articles being written to the effect that threads make programs too hard >to maintain, and that programmers should therefore avoid them. It reuires programmers who know what they are doing. But we wouldn't have Mysql, asterisk, apache, SER or NFS without these tools. -- mrr
From: nmm1 on 4 Oct 2009 06:21
In article <5g6mp6-0p1.ln1(a)laptop.reistad.name>, Morten Reistad <first(a)last.name> wrote: >In article <7iknkoF31ud7sU1(a)mid.individual.net>, > >Speaking of which, are there any firm figures of letting Linux, BSDs, Inix, >Solaris etc through the hoops on an upper three digit processor machine >with intependent load processes where the OS has to do the MP handlig; >e.g. socket, pipe, semaphores in monolithic processes? To the best of my knowledge, no. I am one of the few people with any experience of even 64+ core systems, and the maximum I have personal experience with is 264, but that was Hitachi OSF/1 on a SR2201 (which was distributed memory, and VERY unlike those systems you mention). Beyond that, it's 72 (Solaris on a SunFire) and 64 (IRIX on an Origin). There are very, very few large SMPs anywhere. >I am looking for figures on OS performance itself, not user space. > >The reason I am asking is that I have been involved in a lot of testing >of application performance lately, and it seems to me we are measuring >the performance of BSD and Linux, not the application itself. That fails to surprise me. It took me 3 weeks of 80-hour weeks to get the SGI Origin usable, because of an issue that was in the area you are talking about. Having resolved that, it was fine. With that experience, the SunFire was a LOT easier - when we hit a performance issue of the form you describe, I knew exactly what to do to resolve it. Sun were less convinced, but it was one of the things on their 'to try' list. Regards, Nick Maclaren. |