flat assembler
Message board for the users of flat assembler.

Index > Heap > Building a mini-CPU (just wanted to let you know of Logisim)

Goto page Previous  1, 2, 3, 4
Author
Thread Post new topic Reply to topic
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4633
Location: Argentina
LocoDelAssembly
revolution,
Quote:

The benchmark is just my compiler compiling itself...


It is perfectly possible that performance. The question is if that 4000MIPS is the supposed performance doing exactly that benchmark on his CPU.

rocketsoft, what do you use to meassure the number of instructions executed? It does cover instructions inside system DLLs? kernel-mode too?
Post 01 Feb 2010, 00:39
View user's profile Send private message Reply with quote
rocketsoft



Joined: 26 Jan 2010
Posts: 189
rocketsoft
I put this code in front of each instruction:
pushfd
inc ins_counter
popfd
it counted about 31 million instructions
thats an average of 300 to assemble a single line of code
since it assembles 2.6 million lines of code each second
2.6*300=780MIPS
Not a single DLL call is executed... the counter is reset on the start of
PASS 2... after all the loading is done and it does 5 passes in total
compiling 26500*4=106000 lines
31 million/106000=300 instructions/line
Post 01 Feb 2010, 06:00
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17278
Location: In your JS exploiting you and your system
revolution
rocketsoft: I would imagine that your compile time is memory bound and has very little to with the capability of the CPU and more to do with the capability of your memory subsystem. Do you have a CPU-only benchmark to report?
Post 01 Feb 2010, 06:28
View user's profile Send private message Visit poster's website Reply with quote
rocketsoft



Joined: 26 Jan 2010
Posts: 189
rocketsoft
It does a single pass on the source file for each pass (which is 1MB)
thats 4MB read in 50 ms... 80MB/s which is way below the bandwidth of my memory subsystem (1 Gbyte/s for byte reads)
No, i dont know yet where the cpu spends so much time but i guess its mis-predicted branches that kill the performance mostly
Also the Q6600 has only 32KB instruction cache and my assembler is 18000 lines... thats about 48KB maybe there are many 1st level cache missses
Post 01 Feb 2010, 11:21
View user's profile Send private message Visit poster's website Reply with quote
Raedwulf



Joined: 13 Jul 2005
Posts: 375
Location: United Kingdom
Raedwulf
Borsuc wrote:
I don't think that's how it works though... why do you think all the processors have so many different price ranges -- I can assure you that the research & development is by far not the reason for the difference in price of processors in the same generation. Usually they share 90% of the development.

Let me put this differently. If you could make a 10% better processor than the competition at the same price, why the hell BOTHER to make it ANY better than THAT? You'll already get massive sales, after all it's better bang-for-the-buck.

You don't have to be hugely ahead your competition, just slightly.

Or think about software, where pricing is dependent solely almost exclusively on development. Why are there multiple "versions" of the same software (usually a "light" version and a "full" version)... why not just price the full at low price so that you're better than the competition who has the "lite" version at that price? Because you would be wasting profits. Just be 10% above, it's enough. No need to be more than that.

Or "upgrades" to newer versions when they could have very well integrated it in previous versions -- but then you wouldn't have been paying again! Most of the time when you upgrade, more than half of the features are crap and you don't even need them.

It's far more profitable to start with Windows NT and end up with Windows XP after a bunch of versions in-between than starting with XP and pricing it a bit more (more initial development, since it's obviously more complex than NT).


I'm surprised no one has mentioned "yield" yet.
Most the time faster processors can be produced, but the yield produced by the manufacturing process falls short of being profitable at a mass-production level.

_________________
Raedwulf
Post 01 Feb 2010, 11:47
View user's profile Send private message MSN Messenger Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17278
Location: In your JS exploiting you and your system
revolution
Raedwulf wrote:
I'm surprised no one has mentioned "yield" yet.
Most the time faster processors can be produced, but the yield produced by the manufacturing process falls short of being profitable at a mass-production level.
That is called "binning" not yield. After testing, faster (or whatever measure you are selecting for) chips are placed into the 'A' bins, next slower into the 'B' bin etc. 'A' bin always sells for more than 'B' etc. That is why we have different speeds available when we buy.
Post 01 Feb 2010, 11:59
View user's profile Send private message Visit poster's website Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4633
Location: Argentina
LocoDelAssembly
rocketsoft, I think you should measure this way instead:

* Run with instruction counting enabled
* Grab instruction count
* Call GetTickCount (after source files have been read)
* Run with instruction counting disabled (i.e., the binary contains no PUSHFD/INC [nc ins_counter]/POPFD)
* Call GetTickCount when compilation finishes.

Then the performance calculation would be: ins_counter * 1000 / (Second_GetTickCount - First_GetTickCount) / 1000000. (MIPS)

It is still a bad way to measure processor performance, but this way will give a more accurate result at least. If you don't want to have two runs (I encourage to do so, it is better), you should replace "INC [ins_counter]" with "ADD [ins_counter], 3" at least so you also count the extra effort the CPU is making to giving you an instruction count.
Post 01 Feb 2010, 16:26
View user's profile Send private message Reply with quote
rocketsoft



Joined: 26 Jan 2010
Posts: 189
rocketsoft
Offcourse i used 2 runs, just like u described
My new AMD 2100Mhz runs at 464 MIPS and has double the amount of first level instruction cache so all the speed must be lost on branch mis-predictions on both cpu's
Post 01 Feb 2010, 21:01
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17278
Location: In your JS exploiting you and your system
revolution
rocketsoft wrote:
My adder is faster than the carry select adder by about a factor 2 (adding 2 32bit random numers)
and even more for when few carry flips are present (like in the address addition)
The DELTA-ADDER RULES
Are you aware that the carry select adder is not a state-of-the-art adder? Did you do some more research into how modern adders are made after I taught you that the carry-look-head adder was ancient technology? Having an adder faster than a carry select adder is of no great importance though since it is not even a current technology adder.

Although your claims are getting slightly more realistic. Was 30GHZ ---> Now 5Ghz. Better. But still not proven! What made you realise that 30GHz was way off?
Post 03 Feb 2010, 11:05
View user's profile Send private message Visit poster's website Reply with quote
rocketsoft



Joined: 26 Jan 2010
Posts: 189
rocketsoft
I didn't realize amplifiers were used allready
Post 03 Feb 2010, 20:19
View user's profile Send private message Visit poster's website Reply with quote
DustWolf



Joined: 26 Jan 2006
Posts: 373
Location: Ljubljana, Slovenia
DustWolf
revolution wrote:
Was 30GHZ ---> Now 5Ghz. Better. But still not proven! What made you realise that 30GHz was way off?


Proof:
http://www.rtvslo.si/_up/photos/2007/07/07/u7202/7682_30ghz_show.png

Laughing

LP,
Jure
Post 03 Feb 2010, 22:58
View user's profile Send private message AIM Address Yahoo Messenger MSN Messenger Reply with quote
rocketsoft



Joined: 26 Jan 2010
Posts: 189
rocketsoft
A CPU can only be proven when its complely build and simulated
Post 04 Feb 2010, 18:28
View user's profile Send private message Visit poster's website Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page Previous  1, 2, 3, 4

< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You can attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar.

Powered by rwasa.