IMHO the upper bound of performance of algorithms for parallel processing depends greatly on the problem you are trying to solve. Some can be O(n) - C and others actually scale negatively
Sent from Surface Pro
From: Sinha Prokash
Sent: Sunday, April 19, 2015 11:55 AM
To: Windows System Software Devs Interest List
In around year 2000, the industry saw a physical barrier, and came up with multi-core hyper threaded HW. So the obvious question was how to get parallel / concurrent computing much easier ?
We know from theoretical point of view is the maximum we get is for an O(n) processing is O(log(n) ). Now not bad even it is not asymptotically stable. It is still at a very lower pace than O(n). – Okay we can live with that:-)
Language side joined the party too ! OpenCL for one and Grand central Dispatch is another one, among others.
C++ is already in the plug able kernel module infrastructures already …
When it comes down to Kernel here is what I like most -
“If you put a spoonful of sewage in a barrel of wine, you get a barrel full of sewage.”
On few occasion I’ve seen people changed the core kernel, and subtle bug appeared after a year or so. These are kernel locking, panic and other like those. Personally I think a leaner language C helped understand, albeit long hacking/debugging of the problems. So that’s called learned the hard way what to appreciate and what not too given a certain context.
For large scale systems programming ( not in kernel ), people have been using C++ mainly because of its similarity with C but lot of pitfalls can be avoided easily as well as for better interface design.
Pro
Date: Sun, 19 Apr 2015 07:55:15 -0400
From: xxxxx@hotmail.com
To: xxxxx@lists.osr.com
Subject: RE:[ntdev] kcalloc equivalent> You know, I was going to make fun of the idea that binary literals as a language addition was
> such a big idea. But, the more I thought about it, the more I really can’t wait to use it.Well, if you think even more about it you will realize how cumbersome and error-prone this idea is for driver writers and OS designers, i.e for those .who normally have to deal with 32-bit and/or 64-bit registers. For the fun of doing it, try writing a bit of Verilog code, so you will see that the approach that may brilliant for handling 4-bit values becomes somewhat cumbersome with 16-bit ones and totally messy with 32-bit, let alone 64-bit ones. I guess they took this idea from the world of HDLs, especially taking into account that C++ -like languages may be used for hardware simulations (i.e so-called System C)
>I just recently learned about range-for…
Again, the same story - this feature is of particular use for hardware designers who may want to
have their internal registers of"non-standard" size( like 5-bit, for example), as well as to access individual bits in the middle of the range. However, if you use it in context of software
development - well, it seems to be something Ada-inspired…Concerning Sven’s examples of timing prefixes, although this feature may be, indeed, somewhat/sometimes useful for the software designers, it still seems to be of particular use for hardware ones, because timing is of vital importance for hardware simulations…
In other words, all these extensions seem to target hardware designers, rather than kernel developers…
Anton Bassov
NTDEV is sponsored by OSR
Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
OSR is HIRING!! See http://www.osr.com/careers
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminarsTo unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
NTDEV is sponsored by OSR
Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
OSR is HIRING!! See http://www.osr.com/careers
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
instead.