Yes, it should be particularly bad (relative to SB) at any number of active threads up to 50% of the cores in the AMD part, especially in integer work. And when the green fans see the gaming results, we'll see the five stages of grief.
Printable View
does anyone know how well BD will clock on normal desktop voltages?
Actually, I can't get into specifics, but I would be willing to bet that my processor actually performs better at half load than anyone here would ever expect.
It will be very interesting to see a 16-thread SB with 8 active threads vs. a 16-thread interlagos with 8 active threads.
Let me get this straight: you haven't seen gaming results for SB,let alone for BD desktop part(or any aspect of BD performance for that matter);you claim that in integer work, with 50% utilization ,BD will be "particularly bad" without providing any source or at least a reason for this line of thinking. All this makes me think that you just failed big time.
First of all,we haven't seen gaming results for SB.It may be great at gaming for all we know.It may be the same as i7 we have today or slightly better.We have few results where Turbo is not working well which show performance uplift up to 10% compared to Lynnfield and a geek bench result from a mobile SB with obviously working Turbo mode which shows ~20% uplift(which is very good).No gaming results yet.
Second of all,we haven't seen any performance results of any Bulldozer variation.Bulldozer will have noticeably improved integer units relative to Stars cores,which will be 4 issue and each core will be capable of 2 loads and 1 store(matching SB core).It will have more advanced Turbo mode too,meaning very aggressive up clocking when CPU is underutilized (the scenario you previously described as "particularly bad"). It will have much more potent fpu unit than Stars cores that can be split in two and will support AVX. It will have more L3 cache and it will have a new shared L2 level cache and probably a trace cache. There is also a hint of a so called "accelerate mode" in which BD's front end can dispatch 2x more instructions to the module's 2 cores under certain circumstances(dresdenboy's blog).There will probably be a lot more prefetching and speculative execution going on in the design too.Now we don't know how much of an improvement all this will bring to gaming(which is mainly a GPU thing) but I think it will bring very noticeable gains in traditional and parallel workloads.
Now it may be the case that when underutilized one BD MPU will trail one SB MPU but to claim this to be the case now ,you would have to have both chips in your hands today and running actual tests on them.Which I'm sure you are not.
I thought it was fairly obvious. Up to 50% activity, you have a full SB core with no HT load against 1/2 the module. Add in that Intel turbo >= AMD turbo (probably >> IMO), and there you go. For FP, at least in 256-wide work the module had to share to begin with, so the relative performance increase of half a module is greater when you stop loading the other half.
There was a thread back in the day on amdzone, where people started asking about single-threaded performance. JF's answer was first that it doesn't matter to server customers, and then, when pressed, well, it will be better than current k10.5 single threaded performance. Reading between the lines, it won't be great. Clearly not in SB's league. But what many people miss is that single-threaded performance directly relates to 50% loaded performance (more so integer), too, due to BD's module design, and SB's HT design.
So there, you have 2 indicators. :D
Like I said, a point of relative weakness. It's relative strength will be stuff that can truly continuously use all the cores.
Are you kidding? Maybe better than *I* would expect, but certainly worse than the biggest fans here are expecting. ;)
Oh, come now. The marketing gentleman doth protest too much.Quote:
Fooling someone will allow me to sell a processor. Telling the truth is what helps you sell millions of processors.
There is way too much on the line for me to be "fooling" people.
Sure, sure, if you told outright lies, that would poison the market, though you might be able to fool millions before too much feedback was out there. ;)
But lets not pretend that your goal is to present the unvarnished, objective truth of the tradeoffs between your product and the competition. Your employer would (rightfully) not be be pleased.
So it's a gray area called "marketing". That's fine. You're an advocate for your products. You seek to emphasize their strengths, and minimize their shortcomings.
So you skip everything else I have written (because you know I have a point) and make a claim ,again,without knowing few important things like : a) intel's Turbo being much more aggressive than AMD's version ? b)a performance of "half the module" (you do realize that "half the module" is actulay a full fledged 4 issue improved integer core with an access to 256 FMAC unit,shared L2 cache+shared L3 cache and a new and improved Turbo Core ability?).
The perf. "penalty" of fully loading up a module is ~10% so single active core will be actually performing better even without the Turbo,let alone with it.
:banana::banana::banana::banana:ing typical
cant open 1 amd thread without same trolls talking same nonsense
I totaly agree, K10 was a bit overhype ... And i understand the way to send conservative numbers.
That's awesome :DQuote:
Also, don't forget that we have a boost technology. The 50% number is based on a fully utilized processor. If you were only running a single thread you would be looking at a very different uplift.
I hope AMD is gonna deliver some new FX chips. So long we havn't seen them.
When BD's advocate downplays the importance of its single-threaded performance, I take the hint.
So either you disagree with this point, or you don't see that relative single-threaded performance is a nearly perfect indicator of relative 50%-of-fully-threaded performance. It is only past 50% that the big design differences (modules vs HT) start to kick in. And until 50% we don't really need to worry that power or memory bandwidth is going to be all that constraining, and besides, they're on fairly even ground with those factors.
I'll assume you do understand the latter, so I guess you are arguing that BD is going to be very close to SB in single-threaded performance.
I don't buy it.
there is Xtrem funny people here ^^
we need to have a paypal setup gambling section of the forum. let the fanboys take some real risk with what they say. (this applies to all variations of fanboys)
A good product sells itself, a bad one doesn't. Marketing is there to help the good products to sell even more and to help the bad ones to sell something. Marketing teams almost always tell the truth. The problem is not what they tell you, it's what they don't tell you. You, with emphasys in you, are fooling your potential customers just as much as any other marketing guy.
I'll say this one time only: let's have a clear and sincere conversation. Sincere doesn't mean sharing results. Don't try to fool me because it's not going to work. Don't take this as an offense, again I'm sure you know what I'm refering to, so please.
I'll take that bet. I can guarantee you right now that your processor won't be able to match my expectations.
And yes, it'll be very interesting. I'm looking forward to it.
He just said "my processor actually performs better at half load than anyone here would ever expect". Bad planned comment coming precisely from a marketing guy, isn't it? It's just asking for this kind of response ;)
By the way, SB won't match my expectations either. Guaranteed ;)
Well for one I won't claim this or that like you do.You know next to nothing about how each perform(bits and pieces in SB case) and you firmly claim one of them (BD) will be "particularly bad" in certain situations. I for one believe it won't be "particularly bad" in any type of workload,but whether it will be able to match SB depends on various things we have no clue about at this point in time(clock speeds,Turbo,memory performance,no clue on BD performance,little clues on SB performance etc.).
I wish i`ll try AMD platform someday :)
Love the Intel trolls stirring up trouble as always
Intel trolls. AMD trolls.
Seriously, if Intel and AMD respectively produced product as often as you guys talk, we'd have 16nm technology right now.
I feel right now a line from the movie "midnight run" by veteran actor Dennis Farina is called for.
*ring ring*
<Dirk Meyer> y'ello?
<Dennis Farina> Is this moron number 1? Put moron number 2 on the phone.
<Dirk Meyer> yeah, hes right here.
<JF-AMD> Yeah?
<Dennis Farina> I thought Bulldozer was going to be out this year.
<JF-AMD> That's the information we got.
<Dennis Farina> "thats the information we got." Listen to me very carefully. I want that uarch released and I want it released fast. You and that other dummy better start getting more involved with your work or I am going to strangle you with your bicycle helmet. *SLAMS PHONE RECEIVER*
...........
<dirk meyer> john, hes not mad at me, is he?
Yes but in a nonspecific way.
Source - AMDQuote:
it will be backwards compatible so you won’t need to change anything to start using the processor"
http://blogs.amd.com/work/2010/08/02...ulldozer-blog/
looks like AM3 compatibility confirmed
Fake?
Yes.
^^^HOLY CRAP THAT IS AN EPIC POST! Who made all those slides? It is pure AMD :banana::banana::banana::banana:. If only it were true.
EDIT: Taking a closer look at those numbers: If Zambezi has twice the cores of a Phenom II with around 1.8x the performance of one, those number could very well be realistic.
:rofl: at the inflated GPU score for having more cores on Interlago:rolleyes:
yes those are fake, it was from the botched april fools joke from amdzone, they almost got jf-amd in trouble with that one.
This slide anand showed some time ago lists Zambezi as AM3 but I am not sure if this is the most powerful version of BD havent followed it closely enough :/
http://images.anandtech.com/reviews/...toproadmap.jpg
think, next gen Bulldozer will totally new socket (this one but AM3+/AM3)
To all those that said I was over-reacting and that this would die down in a few days, you were all wrong.
I probably recieve an handful of emails a month still about this and I am pretty sure it will continue after the bulldozer launch. Stuff just lives forever on the internets.
J-17d :horse:
JF-AMD you have written in the blog that Bulldozer will be compatible with the older components "mobo, ram, etc" so there is no need to upgrade them did you mean only for server class or consumers version also?
It's been said numerous times and stated in official slides that Zambezi will be AM3 compatible.
Then I was correct http://membres.lycos.fr/piratland/or.../smiley182.gif
Since you won't confirm or deny socket/platform compatibility with upcoming desktop based Bulldozer products, then its best to assume a position of wait and see.
No point in buying AMD-based desktop motherboards that will be rendered totally outclassed by a new uarch in 9-10 months.
John, we're not asking for performance numbers, we want to know one thing : desktop bulldozer processors : will or will it not be compatible with a socket AM3 motherboard released in the year 2010?
Why, I realize customer relations and marketing are the least of AMD's concerns, but perhaps you could go the extra mile on this one time? Otherwise, you're just warming a seat.
battery, wathc lower and u have answer :-) (AM3 revision 2 = AM3+, AM3+ is compctible with older AM3 socket, only will need updating BIOS)
http://www.4gamer.net/games/110/G011...093/TN/005.jpg
There are three things that i'd like to say:
1) At this point in time, any money spent on buying desktop hardware from both Intel and AMD is a questionable spend, what with the platforms changing. You could buy Magny Cours (8-core chip) based system for about the same price as an i7 system, which will be somewhat futureproof, as it supports upcoming BD processors.
2) If Intel/ AMD would actually continue with a given platform, they'd freely admit it. For one, it gets them a good chance of retaining a majority of the existing customers. If you haven't heard about it, it is most likely due to the fact that it may be up for a revision. BD is a new architecture and most likely will have a new socket(on desktop line as socket G34 continues in Server arena)... I think a look at Socket G34 will give us some idea about the newer platform, as it supports upcoming BD processors.
3)Please, "would you mind not shooting at the thermo-nuclear warhead." This is what Travolta says in Broken Arrow. Loved that film :D. Anyways, please don't say anything remotely derogatory to anyone, least of all, someone who you want some priceless information from. JF is more than just a trusted source... and i'm sure there are many (apart from me) who do not find your post in good tatse. Trust me, if he could, he would share information.
You should take a look at his post histories, STaRGaZeR. What you said was simply baseless.
freeloader, the very same reason why everyone is screaming at ati to speak up and read the forums(on their driver bugs. Honestly, I have no problem, but my card is not an Evergreen card). It's good to see what your customers want, don't you think?
I guess I'll add JF to my ignore list. There's no point in having anyone in a conversation when it's one sided. Just for your information, JF hasn't added anything on these boards that wasn't already public knowledge. AMD can go you know where. They've lost me as a customer.
rage
[Edit: that was a little harsh...]
Lol geez, can't get what you want so you go sit in the corner and pout?
You or anyone else are not entitled to any information that is under NDA. Why on earth would AMD give a handful of anonymous forum participants crucial information that could impact their business? I'd like to see numbers as much as the next person, but I'm certainly not going to beg for them and then throw a fit if I don't get what I want.
I'm as much interested in the details of the architecture of the many products AMD have coming to market shortly as I am the numbers though.
If you want to alienate your customer base, then by all means tell them nothing and you've done a fine job of it. I'm simply saying if he can't inject any more information than what's publicly available, then why does AMD even have an AMD Bulldozer blog? For what? What's the point of it if you're not going to share any new information? I'm not waiting anymore for anything from AMD. If they can't get their act together and inform customers of progress and a concrete release date, then they don't deserve my business. I don't care what you or anyone else on this board thinks. I'm one person with an opinion that you don't share. No crying or pouting involved. AMD has spoiled my personal taste for their products.
so, what do u can say Intel about Sandy Bridge architecture now? :-D Do u think more specific ?,-)
freeloader why are you getting so mad just wait and see what happens. Sure knowing the performance of something before it comes out is nice but its not like you can buy it yet anyway... hes under nda idk why you are fuming on something so trivial.
I know he's under NDA. I just want a release date. Surely by now AMD must know what their schedule is! I'm not mad at JF as a person, I've never met the man; but I am upset with the company he works for. I've said in a few other posts, just throw us a bone, even a small one.
my meaning for relase date is 2Q 2011. (maybe at Computex)
Well if its a release date you're after, you might as well give up right now. There is no chance of that happening, period. And since this is about server products, you're barking up the wrong tree anyway. It wouldn't do you any good to know Bulldozer release dates for Orochi products anyway.
I'm sure if you harassed, I forget who?, I'm sure you'd get the same response. Other than the ever popular, "as soon as we get the screwdrivers and pliers out to 'fine tune' this sucker. Its no good the way it is", that seems to be the standard response from the blue team :D
freeloader, does Intel have a representative that leaks any information?
We are all dying to see performance #s and whatnot, but we have to be patient.
Surely it isn't that difficult to understand the increased complexity of having a second processor on die, constantly regulating which features of the larger processor are active, allocating power and frequency among these features, etc? And that this complexity results in a greater percentage of performance being determined by the "program" this second processor follows?
They have already released information on bulldozer, not all there is, but as much as they feel they can share at the moment. JF-AMD is here to clear things up, if you haven't noticed people seem to be incapable of reading the information and reading it right, so he is in fact needed.
It could hurt business to create a hype or releasing performance numbers. So for now they are only releasing basic architecture information.
I bet JF still gets questions about the 9th core in Bulldozer in his mails.He is needed on this forum,just like Francois is.
Nope not hard to understand at all. On the other hand, its just as likely that the performance isn't what they expected and are now turning the screws to see if they can muster up some performance gains, now that compiler tricks and benchmarketing are being scrutinized by the FTC, and about every other watchdog on the face of the planet. :D. Welcome to the world of competition intel! I know its been a couple decades for ya lol
Nope. FTC hasn't changed a thing, Intel will continue to play with the tricks on their compiler. The rules have been changed a bit, they just play with the new rules and the same garbage continues. :)
But once again open source software saves us(non-windows users at least) all. ;)
you really are making a mountain out of a molehill with intel's compiler. you havent even used binaries compiled with it either.
intel doesnt cheat to beat amd. they just do it. you can look at anything from industry standard benchmarks to WCG/BOINC projects.
cheat certainly isn't a term I'd use for Intel's compiler; lazy and anti-optimizing however seems to be a far better description.
It generates x87 instructions in long mode for crying out loud. Only 2 types of people make that sort of mistake; idiots and used car salesmen.
i'm with you on that. x87 is truly an abomination of an instruction set, especially when there is an alternative that is supported on the same processor.
using icc for a benchmark i would consider cheating. other than that it's fair game.
If you refer to gaining more than 40% in performance when you rename merely a cpu vendor id... well, then yes, people are indeed making mountain out of a molehill...
http://www.osnews.com/story/22683/In...from_Compiler_
actually if you look closer to Intel's implementation, you quickly realize that they assume any non-Intel processor must be a 80486SL, even when generating 64bit code. [Using only 8 of the 16 in Long mode]
Not to mention, skipping several common optimizations [that all other compilers do for all processor anyways]
Intel is under no obligation whatsoever to support AMD, much less produce optimal code for it. That takes effort and intimate knowledge about the caveats and errata on AMD cpus. AMD isn't willing to share that, nor support financially the development.
If you don't like Intel's compiler ( which has something like 4% market share ) , you're free to use from a plethora of others : MS, Pathscale, GCC, Sun Studio,etc.
The whole compiler thing is BS stemming from the socio-political views of those in power, liberal neo-socialists ) both US/EU, who have grand ideas of benevolence from the strong to the weak and if they don't do it willfully they will be forced. Horse manure.
Umm no, producing optimal code rarely requires knowledge of the errata of CPUs. [If you have errata in relation to such common cases, why even bother selling the chip?]
High level optimizations make several orders of magnitude performance difference regardless of the underlying architecture.
Now yes it is easy to say Vector optimizations are implementation specific; however Vendor ID doesn't matter remotely as much as instructions supported. Hence just throw a CPUID opcode and check the feature flags and optimize all hardware implementations that utilize those given instructions. [Swings in instruction latency aren't as important in OoO hardware, so why optimize for it???]
As for why the Intel compiler is only 4% of the of the market; that is because it has a tendency to suffer from Splot [edge cases that cause compilers to hang indefinitely or crash] even on some trivial code.
I agree one hundred percent with the fact that Intel is under no obligation to support AMD or any other chip manufacturer for that matter. Given that i was planning to start something myself, i understand completely that it would suck balls for Intel to have to support AMD...
Now, please give a few minutes to read something rather important. Optimization is not the same as executing/ running the code at all. Optimization is when you tailor a certain code to work more efficiently on a given piece of hardware/ equipment. FTC has noted certain descrepancies in the compilers from Intel in that they do not run the (instruction sets) code at all on anything else than "Genuine Intel". Now this is what put Intel in soup. What Intel was doing was not using instruction sets such as SSE2, SSE 3 (and now AVX in their latest beta compilers) and blah blah supported by VIA and AMD processors... the compilers simply ran the code as if there was no support at all.
To put it simply, the current scenario is:
If Genuine Intel"{
AVX{}
}
else{}...
What is present in Intel's settlement with AMD is, "Intel would have to remove any piece of code which artificially limits performance of AMD processors"... So now the piece of code in question should ideally look like...
If AVX{
If Intel{}
else{}
}
This is not optimizing for AMD is this? This is for simply detecting support of an instruction set and execute the same, with optimized path for "Genuine Intel" processors. However, they are rather sneaky with the same dodgy behaviour persisting, which is evident what with their new beta compilers which dropped in soon after they reached the settlement with AMD.
I believe from your demeanour that you believe people at Intel to be more evolved (and hence intelligent?) than any other on this planet... Given that they're all so superlative, do you think they were a bunch of idiots to agree to such a thing?
Now FTC in their settlement with Intel have asked Intel to notify that their compilers do not run certain codes/ instruction sets (in other words are broken :P) on any other procesor than Intel's own. Which is fair... FTC didn't ask them to optimize code... only advised that they better run it, or, notify people who use it that it is broken :ROTF:
If you follow soccer/ football, FTC has caught Intel committing a foul, as Intel went diving and asking for a penalty. This time, they've been warned, shown a yellow card, if you like. The next time, it will be a red card. This is only fair...
Oh, yeah... just so you know... i'm typing all this using a "Genuine Intel" system :rofl:
LOL intel's compiler tricks proves that intel can only win if they cheat .... go go go amd let the bulldozer wipe the floor
if intel promotes a compiler that works on other cpu then yes they are forced to make it behave the same on other platform .... you dont know nothing concerning the legality of this so stop talking out of your ass
As you know very well, compilers work by the switches you enable. Intel's compiler work perfectly well for AMD witht he right switches given that AMD themselves uploaded benchmark scores using Intel's compilers. Interesting behaviour towards a "cheating" compiler.
Intel's compiler does not bother to check for support. It uses the familly code bits, e.g it optimizes for Core, Northwood, PPro,Prescott,etc. The code it creates takes into account all the peculiarities for the given uarch.
I fail to see how this nonsense can be extracted from my "demeanour" and what's the point you're trying to make.Quote:
I believe from your demeanour that you believe people at Intel to be more evolved (and hence intelligent?) than any other on this planet... Given that they're all so superlative, do you think they were a bunch of idiots to agree to such a thing?
If you believe politics do not interfere with regulators, you need to get out of the house more. I suppose you don't see any connection between AMD/GF building a FAB in NY and the Cuomo case ?
Who is dumb enough to buy Intel's compilers when targeting the broadest base possible ? You use MS or GCC.Quote:
Now FTC in their settlement with Intel have asked Intel to notify that their compilers do not run certain codes/ instruction sets (in other words are broken :P) on any other procesor than Intel's own. Which is fair... FTC didn't ask them to optimize code... only advised that they better run it, or, notify people who use it that it is broken :ROTF:
Works... and works perfectly well are two different things...
Read:
http://www.osnews.com/story/22683/In...from_Compiler_
and,
http://arstechnica.com/hardware/revi...o-review.ars/6
The same code on the same processor with a differnt vendor id, ran 10% less efficiently :D
What any compiler ideally should do especially when it comes to instruction sets is check for support... otherwise, what is the point of having a standard, if no one is to follow it. What you're talking about is code optimization...
I'm sorry about the earlier remark , this one specifically... but you do see pun was intended... nothing personal. Then again, i meant to imply that if Intel knew they did no wrong, why'd they agree to such terms with AMD?
Apparently a lot of people who make benchmarking tools, whom we rely upon :P
I'd like to direct you to another discussion which was highly entertaining both from a comic and a content perspective. Too bad I don't have links to all the excellent discussions held at Aces and Realworldtech about this. You had people with real knowledge discussing the issues at a totally different level than enthusiasts. ( ok, not all the posts were at that level :ROTF: )
http://aceshardware.freeforums.org/c...iler-t428.html
There are several gems in that thread :
and levicki nails it :Quote:
One day, Cadence decided that those Synopsys heathens and their treacherous users shouldn't be able to flip between a Synopsys tool for netlist compilation, and a Cadence tool for place & route.
"Why are people using dc_shell for compiling their netlists?," cried Fister. "We have RTL Compiler! We should optimize our P&R tool for our RTL compiler!" Of course, RTL Compiler was already optimized as much as Cadence software engineers could ever optimize anything. A sly executive inquired, "can't we just make Encounter slow down for non-RTL Compiler inputs?"
The new product was released. Suddenly, P&R jobs for netlists produced by Design Compiler were running 10% slower, and producing layouts which were 5% larger, and 10% slower. Internal benchmarks began to report that RTL Compiler was superior to Design Compiler, and Cadence began to sell more licenses than ever before. Fister smirked with glee, "the money doesn't even matter; our biggest competitor is being completely undermined."
The users, curious engineers, were suspicious. The masses of Deepchip.com pooled their collective resources together to investigate what was going on. It was soon discovered that Cadence's P&R tool was performing selective optimizations depending on the source of the netlist.
"How dare Cadence do this!," cried an engineer.
A calm reply from a Cadence spokesperson was heard: "it is quite simple after all. If Encounter doesn't meet your requirements feel free to use something else."
It is far more entertaining when people bring actual facts and do not follow the herd instinct. Facts have a nasty way of enabling the mute button in the most vocal but shallow participants.Quote:
Excuse me, how has this discussion gone from Agner's speculation about flaw in Intel's compiler (which is bogus because CPUID is also tested in much the same way in legacy BIOS code) into this pointless discussion whether should ICC have separate AMD code path or not?!?
I say it shouldn't support AMD at all. Let AMD write their own compiler.
I deal with code optimization since Pentium MMX and if I recall correctly until very recently AMD didn't invest into popularization of code optimization a single cent. They couldn't teach anyone even if they wanted to, because their developer website is a mess -- it took me one hour to find a document which describes proper AMD CPU detection.
They always had their brute force approach as in "why waste time optimizing code when you can buy a faster CPU".
That was when they had faster CPUs. Now that they don't have faster CPUs they have started preaching about code optimization, hypocrits.
.................
Are "works fine" and "works optimally" synonyms for you?
AMD CPUs need separate code path.
Just of the top of my head:
1. AMD themselves said in their optimization manual for AMD64 that their CPUs prefer interleaved reads and writes while Intel prefers batched reads and writes. There are probably a lot more differences especially in instruction scheduling.
2. There are some old AMD CPUs with family and model < 6 which report SSE and SSE2 capability incorrectly.
3. AMD supports SSE3 but not MONITOR/MWAIT, if you allow it to execute the same SSE3 code path it will crash.
You can always patch the check and risk it. If you don't like it, don't use it. Period.
Many people are. Many people who are writing time-critical software use Intel's compilers, mainly the C++ compiler for Windows-
So many, many people use it regardless of the unbiased nature(Possibly not knowing about it even).
Intel's compilers are superior at speed compared to MS and MinGW(GCC compiler ported to Windows, not up to date) on Windows. In other platforms(Mainly linux) gcc(C compiler) is faster than Intel C compiler and g++(c++ compiler) is about just as fast as Intel's C++ compiler.
1. CPU architectures behave differently. Doesn't matter if you compare AMD archtitecture to Intel architecture, or future Intel to older Intel etc. They have differences which require different kinds of optimizations.
2. Never heard of this, and it seems Google hasn't heard of it either. I'd bet a bunch they were ES parts. :rolleyes:
3. MWAIT and MONITOR are Hyper Threading specific instructions, they are of no use for AMD.
So yeah. Great. :yepp:
So why again do we have to discuss ICC as totaly unrelated matter to the topic?