Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.programming > #6538 > unrolled thread

Re: Here is all my text about my USL programs...

Back to article view | Back to comp.programming

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Here is all my text about my USL programs... fir <profesor.fir@gmail.com> - 2016-04-22 22:42 -0700
    Re: Here is all my text about my USL programs... BartC <bc@freeuk.com> - 2016-04-23 10:48 +0100
      Re: Here is all my text about my USL programs... fir <profesor.fir@gmail.com> - 2016-04-23 07:10 -0700
        Re: Here is all my text about my USL programs... Kaz Kylheku <545-066-4921@kylheku.com> - 2016-04-23 14:16 +0000
        Re: Here is all my text about my USL programs... fir <profesor.fir@gmail.com> - 2016-04-23 07:19 -0700
          Re: Here is all my text about my USL programs... Chad <cdalten@gmail.com> - 2016-04-26 21:49 -0700
            Re: Here is all my text about my USL programs... Richard Heathfield <rjh@cpax.org.uk> - 2016-04-27 07:16 +0100

#6538 — Re: Here is all my text about my USL programs...

W dniu piątek, 22 kwietnia 2016 21:27:20 UTC+2 użytkownik Ramine napisał:
> Hello,
> 
> 
> Here is all my text about my USL programs...
> 
> I have to set it more right and more precise..
> 
> So here is my other proof again...
> 
> If the serial part of the Amdahl's law is bigger, you have
> more chance to hit the contention, so there is more chance
> that USL will give a good approximation of the predicted
> scalability up to 10X the maximum number of cores and threads
> of the performance data measurements.., but let say the serial part
> of the Amdahl's law is bigger and is  1/4 the parallel part of the 
> Amdahl's law, and let say the parallel part is variable and it makes the 
> USL methodology escape the contention at fewer core and fewer threads, 
> the USL methodology will have much more chance at fewer cores
> and fewer threads to give a good approximation up to 10X the maximum 
> number of cores and threads of the performance data measurements.., you 
> can feel and confirm it  by statistically using more examples of the 
> follwing above cases and calculating it..
> 
> But if the serial part is smaller , so there is more chance that
> USL methodology will escape contention at fewer core and fewer
> threads. so there is more chance that USL will give a good approximation 
> of the predicted scalability up to 10X the maximum number of cores and 
> threads of the performance data measurements..
> 
> So overall. the USL methodology will be able to forecast scalability
> with a better approximation up to 10X the maximum number of cores and 
> threads of the performance data measurements..
> 
> If you have followed my previous proof of my previous post..
> i have said that USL methodology can predict scalability up
> to 10X the maximum number of cores and threads of the performance
> data measurements..
> 
> So now look at this link about the USL methodology about
> mixed workload on Ecommerce websites from Dr. Gunther the author
> of USL methodology:
> 
> http://perfdynamics.blogspot.ca/2009/04/assessing-usl-scalability-with-mixed.html
> 
> I think from my proof, i say that Dr. Gunther is making a mistake,
> because in this eCommerce example of the link above, since
> we can predict scalability of the database server system up
> to 10X the maximum number of cores and threads of the
> performance data measurements, so the Dr. Gunther solution
> is not a general solution , so my solution for this, is that
> you have to use the right number of cores and number of threads
> in the database system server side that ensure us to have
> a more linear scalability when there internet users are using the 
> database system..and since the internet network have a more linear 
> scalability, so the USL methodology in my solution will be able to 
> predict scalability of the eCommerce website, so this is my solution.
> 
> 
> About my previous post about mixed workload and eCommerce websites..
> 
> You have seen my previous general solution about this case..
> 
> I will make it more precise: if you want to apply the
> USL methodology with my USL programs to mixed workload
> of eCommerce websites, i think here is necessary
> conditions:
> 
> 1- the mean time of the inter-arrivals of the internet users is
> assumed to be a good approximation.
> 
> 2- the webserver database systems must be set with the
>     right number of cores and the right number of threads
>    that ensure a more linear scalability.
> 
> 3- the internet network is assumed to have a more linear
>     scalability even if its derivative of its linear scalability is 
> negative.
> 
> So those necessary conditions permit the nonlinear regression
> of my USL programs to predict scalability of eCommerce websites.
> 
> So that makes my USL programs an amazing great tools to foerecast
> scalability, and it makes the USL methodology an amazing great tool.
> 
> A you have noticed i have given a proof that my USL
> programs can forecast scalability up to 10X the maximum number
> of cores and threads of the performance data measurements,
> this is useful, other than that, this 10X is the right number
> that optimizes the criterion of the cost, so when you want
> to buy bigger NUMA systems, make sure that you buy them
> with the right configuration that permit to add more processors
> and more memory, this way you will be able to test again empirically
> the Computer NUMA system that you have bought  with my USL programs,
> to better forecast again farther the scalability and optimize more
> the criterion of the cost, so as you have noticed my USL programs
> are great tools and important tools !
> 
> Here is my contributions of my USL programs..
> 
> I have first implemented a solver for my USL program that
> is polynomial regression, this solver must make
> the a0 coefficient of the mathematical series to 0, but this solver
> is not so efficient as my other solver that i have implemented
> that is nonlinear regression using the simplex method of
> of Nelder and Mead as a function minimization, this nonlinear
> solver that i have implemented works perfectly and is more
> efficient than the solver that uses polynomial regression,
> also my contribution is my USL programs that is called usl_graph
> that provides you with a more interractive graphical chart that
> permit you to optimize more the criterion of the cost, i think
> that the other R package is less powerful on this option.
> 
> Also in my USL programs i have calculated and feed my nonlinear solver 
> with partial derivatives of the USL equation:
> 
> C(N)  = N/(1 + α (N − 1) + β N (N − 1))
> 
> I have calculated the partial derivative with respect to
> α of the above USL equation, and i have calculated the partial 
> derivative with respect to β of the above USL equation, and the
> two partial derivatives must be given to my nonlinear solver
> that uses the simplex method of of Nelder and Mead as a function 
> minimization.
> 
> Please try my USL programs because they are working great and
> they predict scalability !
> 
> Now about my USL programs solvers...
> 
> I have used a second implementation of the BFGS  Quasi-Newton 
> second-derivative line search family method as minimization function
> for my nonlinear regression solver of USL programs, it is
> one of the most powerful methods to solve unconstrained optimization 
> problem , but it didn't solve all the problems that the simplex method 
> of Nelder an Mead all solved, so i think i will stay with my nonlinear 
> regression solver that uses the simplex method of Nelder and Mead that 
> have solved all the problems that i have given to it, i think it is a 
> good solver for my purpose of my USL programs.
> 
> How to validate my USL programs to be sure that they work correctly ?
> 
> I have first tested my USL programs with polynomial regression
> against the R package of USL with the default solver with the raytracer 
> performance data of the R package and they are giving the same results 
> that is the peak number of processors at 449 and the same predicted 
> scalability, but my nonlinear solver that uses the simplex method as
> a function minimization  is giving a very good approximation
> of the predicted scalability, i have also tested with other performance 
> data from my parallel LZMA algorithm and parallel LZ4 algorithm
> of my parallel compression library and the R package is giving
> the same results as my USL program solvers.
> 
> So you can be confident with my USL programs because they are working
> great and are great tools for predicting scalability.
> 
> I have included the 32 bit and 64 bit windows executables of my
> programs inside the zip file to easy the job for you.
> 
> 
> I have included the 32 bit and 64 bit windows executables of my
> programs inside the zip file to easy the job for you.
> 
> You can download my USL programs version 3.0 with the source code from:
> 
> https://sites.google.com/site/aminer68/universal-scalability-law-for-delphi-and-freepascal
> 
> 
> 
> Thank you,
> Amine Moulay Ramdane.

get off brickass

[toc] | [next] | [standalone]

#6539

On 23/04/2016 06:42, fir wrote:
> W dniu piątek, 22 kwietnia 2016 21:27:20 UTC+2 użytkownik Ramine napisał:

>> Amine Moulay Ramdane.
>
> get off brickass

A few years ago this newsgroup was swamped with posts from Ramine, until 
I blocked them on my newsreader. Now it's starting to be swamped again, 
with your replies to his posts! (BTW it's kind of you to quote the 
articles in their entirety just so I don't miss anything.)

I know the group isn't exactly busy, but still...

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#6540

W dniu sobota, 23 kwietnia 2016 11:49:03 UTC+2 użytkownik Bart napisał:
> On 23/04/2016 06:42, fir wrote:
> > W dniu piątek, 22 kwietnia 2016 21:27:20 UTC+2 użytkownik Ramine napisał:
> 
> >> Amine Moulay Ramdane.
> >
> > get off brickass
> 
> A few years ago this newsgroup was swamped with posts from Ramine, until 
> I blocked them on my newsreader. Now it's starting to be swamped again, 
> with your replies to his posts! (BTW it's kind of you to quote the 
> articles in their entirety just so I don't miss anything.)
> 
> I know the group isn't exactly busy, but still...
> 
Dont think it is much problem to you as this group is complete off, (except the ram-donkey abomination) so you could easily not read it at all, I dontreally think i make things worse (its really hard to do it worse here)

I will try yet some time (im doin it to make sure our brickas donkeyt spammer understands the message - he seems to be 
complete idiot such complete that he seems to avoid the knowledge that he is a spaming brickass abuser and will smille at you with a smile of an idiot again -- but a bit of persvasion may make him harder to idiot-smile and spam again... we will see - maybe even if this idiot will act as before, doesnot mean he do not understood somethink in his empty head..

[toc] | [prev] | [next] | [standalone]

#6541

On 2016-04-23, fir <profesor.fir@gmail.com> wrote:
> I dontreally think i make things worse (its really hard to do it
> worse here)

Google Translation from Dumb Polack:

"I'm making an effort to make things worse around here, but finding it
very hard, due to the stiff competition."

[toc] | [prev] | [next] | [standalone]

#6542

(take note that i am not denying this peasant a right to post his boring crap - Im agains the fact this peasant trashes whole group instead of reserving some or better one thread and post his deadly boring crap under 
that one - not trashing the whole group

This fact makes said brickass especially 
crappy, fact that he would not lost nothing of his crappy mission if he would do it in civilised way but no he will ignore it and crap the whole group - as he is a crappy idiot as he is 

[toc] | [prev] | [next] | [standalone]

#6552

I feel the love in this group.

[toc] | [prev] | [next] | [standalone]

#6553

On 27/04/16 05:49, Chad wrote:
> I feel the love in this group.

<grin> Quite so. If you want a better signal-to-noise ratio, try posting 
some signal. :-)

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [standalone]

Back to top | Article view | comp.programming

csiph-web