Page 2 of 3
C#: claim and reality
Posted: March 12th, 2008, 3:19 pm
by Cuchulainn
QuoteOriginally posted by: dirtydroogQuoteOriginally posted by: CuchulainnThis chunk could be optimised a bit more (low-level optimisation):1. Modulo % trick (if you decide to use it), better to use a shiftShifting to get modulo? He can just check the first bit to see if the number is even or odd (t & 0x01)Yes, even better.
C#: claim and reality
Posted: March 12th, 2008, 3:43 pm
by lballabio
QuoteOriginally posted by: dirtydroogQuoteOriginally posted by: CuchulainnThis chunk could be optimised a bit more (low-level optimisation):1. Modulo % trick (if you decide to use it), better to use a shiftShifting to get modulo? He can just check the first bit to see if the number is even or odd (t & 0x01)Are you sure you want to start slicing bits before looking at a profiler's output?Luigi
C#: claim and reality
Posted: June 19th, 2008, 8:08 am
by Cuchulainn
C# 3.0 supports lambda calculus (unnamed functions). Now you can have functional programming in imperative languages. This saves coding a lot of function objects.
C#: claim and reality
Posted: June 19th, 2008, 3:29 pm
by HockeyPlayer
As already mentioned; the code can likely be parallelized well.This is going to be easier in C# than C++ and is likely to lead to significant improvements, that will continue to accrue over time (as the target machine gets more cores).
C#: claim and reality
Posted: June 19th, 2008, 6:43 pm
by Cuchulainn
QuoteOriginally posted by: HockeyPlayerAs already mentioned; the code can likely be parallelized well.This is going to be easier in C# than C++ and is likely to lead to significant improvements, that will continue to accrue over time (as the target machine gets more cores).C# is easier than C++, but slightly slower.Just having 4 cores !=> 4 times faster. But you know that already, I am assuming. Keyword here is s/w design. Raw programming talent is not enough.
C#: claim and reality
Posted: July 12th, 2008, 1:22 pm
by xeno
QuoteOriginally posted by: CuchulainnQuoteOriginally posted by: HockeyPlayerAs already mentioned; the code can likely be parallelized well.This is going to be easier in C# than C++ and is likely to lead to significant improvements, that will continue to accrue over time (as the target machine gets more cores).C# is easier than C++, but slightly slower.Just having 4 cores !=> 4 times faster. But you know that already, I am assuming. Keyword here is s/w design. Raw programming talent is not enough.Have you tried ParallelFX before? I thought it worked quite well for me in afew 'embarrassingly parallel' situations using Parallel.For(...)
C#: claim and reality
Posted: June 13th, 2009, 9:19 am
by Cuchulainn
I have a generic array class which must support both value and reference types. A ctor is defined as below. Question: solution works, but is there a better way?
C#: claim and reality
Posted: June 17th, 2009, 7:53 am
by fredba
Why are you rewriting from scratch a generic array and don't use the ref keyword ? any particular reason ?
C#: claim and reality
Posted: June 17th, 2009, 9:59 am
by Cuchulainn
QuoteOriginally posted by: fredbaWhy are you rewriting from scratch a generic array and don't use the ref keyword ? any particular reason ?1. Array is just one basic class in my hierarchy. Because C# does not have a BLAS library, it has primitive array structures. And ArrayList<T> is the wrong interface for maths. I also have matrices and more as well as the usual axpy operations.2. How would you use 'ref' to improve my code? That's very interesting.
C#: claim and reality
Posted: June 17th, 2009, 2:33 pm
by mhollander
if (initvalue is ICloneable) m_arr = (T) (initvalue as ICloneable).Clone(); else m_arr = initvalue;reflection is probably slow -- i would avoid doing it twice (ie is ICloneable and then cast to ICloneable) and i would also avoid doing it inside the loop.you can certainly do ICloneable xxx = initValue as ICloneable; if (xxx == null) // handle not cloneable case here else // handle cloneable case here.HOWEVER, there is another issue with your code that I'm not sure you've thought of. It might act a bit strange. Say that T is not cloneable but T has a subclass which is cloneable. Then you will get reference copying or cloning depending on the instance not the class. Is that what you intend?
C#: claim and reality
Posted: June 17th, 2009, 4:13 pm
by Cuchulainn
QuoteOriginally posted by: mhollanderif (initvalue is ICloneable) m_arr = (T) (initvalue as ICloneable).Clone(); else m_arr = initvalue;reflection is probably slow -- i would avoid doing it twice (ie is ICloneable and then cast to ICloneable) and i would also avoid doing it inside the loop.you can certainly do ICloneable xxx = initValue as ICloneable; if (xxx == null) // handle not cloneable case here else // handle cloneable case here.HOWEVER, there is another issue with your code that I'm not sure you've thought of. It might act a bit strange. Say that T is not cloneable but T has a subclass which is cloneable. Then you will get reference copying or cloning depending on the instance not the class. Is that what you intend?The code is not optimal, indeed. The Array class can hold anything in principle, but in practice its client classes nearly always use numeric types (and then 'double' is 95% of the cases that you need, although its nice to have 'float' and complex, for example).The cloneable test in the loop is bad In practice, most data is value type (e.g. using structs would solve it) but on the other hand I would like Array<T> to be bullet proof. The interesting class for numerics is Vector<T> so that maybe I make Array private only. I don't think I will need subclasses of T.Will look at TPL to see how it handles vectors of numeric data.
C#: claim and reality
Posted: June 18th, 2009, 8:35 am
by fredba
C#: claim and reality
Posted: June 18th, 2009, 1:43 pm
by Cuchulainn
QuoteOriginally posted by: fredbaEver tried this ?
http://ilnumericsnet.codeplex.com/Relea ... ?Executive overviewI tried installing the Core reference documentation but I failed.No source code, just dlls, yes?
C#: claim and reality
Posted: June 18th, 2009, 5:02 pm
by Cuchulainn
QuoteOriginally posted by: fredbaWhy are you rewriting from scratch a generic array and don't use the ref keyword ? any particular reason ?Other reasons are:1. Portability; C++ classes and apps that use Array<T> can be ported to C# because it has the same interface. It is the 'language hardware layer'2. Performance; remove the internals of Array<T> and choose another implementation (e.g. shared pools, locking...)
C#: claim and reality
Posted: June 19th, 2009, 6:57 am
by fredba
That's why I send you ilsnum. It is designed for what you want to do.For the doc :
http://ilnumerics.net/main.php?site=512